Sequelite acuta
È notizia di questi giorni che i "cinesi" ne hanno combinata un'altra delle loro: hanno infettato qualcosa come 510 mila server tramite SQL injection sparando javascript pericoloso a destra e a manca. L'attacco ha colpito soprattutto server Microsoft (con ASP e ASP.Net) e per questo motivo qualcuno si è sentito autorizzato a mettere in relazione l'attacco con un'altra vulnerabilità segnalata la scorsa settimana (una Elevation of Priviledges): legame che non esiste assolutamente, come si può leggere sul blog del Microsoft Security Response Center. Confermata anche da un'indagine di BetaNews:
But a BetaNews check this morning of infected sites whose injected code is visible via Google query (where, ironically, the hidden script code becomes un-hidden) revealed at least one site -- that of publisher Harcourt Brace, a frequent Oracle partner -- where the injected code was also present.
Di SQL Injection comincio a vederne in giro davvero tante (qualcuna assume anche caratteristiche grottesche), basta fare un giro su milw0rm.com per rendersene conto di persona: Joomla, ODFaq, FluentCMS, RunCMS, PHP Forge e non ultimo Wordpress (che sull'argomento è piuttosto recidivo). Prevenire l'attacco è molto più semplice che scrivere codice che faccia la pulizia a mano. Basta sostituire ad esempio questo:
$wpdb->query("SELECT row FROM table WHERE column = '$parameter'")
con questo:
$wpdb->query("SELECT row FROM table WHERE column = '%s'", $parameter)
Insomma come le Sexually transmitted disease la sequelite è facilissima da evitare, ma nonostante ciò la sua diffusione è un fenomeno di dimensioni planetarie. Il consiglio per difendersi da questo tipo di incoscienza puerile è sempre lo stesso: usare plugin specifici per FireFox o IE7 in protected mode.
-quack
UPDATE: questo post spiega perché ad essere colpito è stato lo stack MS.
Pubblicato lunedì 28 aprile 2008 alle 8:46 PM
- Archiviato in:
Security.
Condividi su:
Facebook,
Wikio,
Segnalo.
lunedì 28 aprile 2008 alle 11:07 PM -
Da quel poco che ho capito, gli attaccanti hanno sfruttato un comando di MS-SQL che permette di sovrascrivere un database senza conoscerne le dimensioni: un comando simile a UpperBound / LowerBound per gli array in VB?
I "plugin specifici" di Firefox sono NoScript e AdBlock+, per filtrare tutto cio' che non e' attinente alla pagina, vero?
Edward
Permalink
lunedì 28 aprile 2008 alle 11:17 PM -
No, hanno fatto una eseguire una query che enumera tutte le colonne di testo di tutte le tabelle e per ciascuna di queste viene eseguito uno script UPDATE che 'appende' il javascript malefico. Se il sito usa una di quelle colonne per popolare la pagina il gioco è fatto.
In uno dei link si parlava della capacità di NoScript di bloccare JavaScript proveniente da un dominio diverso. Questo dovrebbe bastare.
Permalink
martedì 29 aprile 2008 alle 10:44 AM -
Ciao,
ma se è stato un attacco *SQL* perchè sono stati presi di mira solo web server IIS? Me lo spieghi tu? Non sono andato a leggere il tuo link.
Permalink
martedì 29 aprile 2008 alle 5:21 PM -
Shance, e' stato usato un tipo di SQL injection che funziona solo su SQLServer di Microsoft che tipicamente viene usato in combinazione con IIS e non con altri web server.
Se andavi a leggere il link trovavi la risposta... viva la pigrizia!
Permalink
venerdì 2 maggio 2008 alle 4:11 PM -
Uffa, io volevo la spiegazione da Paperino.
Continuo a capire poco... sembra che ci si continui ad arrampicare sui vetri. Tecnicamente era attaccabili anche Oracle o MySQL?
Ci sono modi per lanciare una SQL Injection senza una connessione aperta da una pagina (.asp o .php) senza la porta sql aperta? No vero?
Permalink
venerdì 2 maggio 2008 alle 8:03 PM -
@Shance:
una SQL injection non è un problema del DB. Il DB fa semplicemente il suo lavoro: eseguire codice SQL. Una SQL injection pertanto è un problema della applicazione (ASP, PHP, quello che vuoi) che "perde il controllo" di quello che passa al server SQL.
Tornando alla tua domanda: tecnicamente erano attaccabili anche Oracle o MySQL? Sì e no.
Sì perché non c'era niente "di speciale" nella parte "finale" del codice SQL da eseguire (l'INSERT). No perché le librerie di accesso di MySQL per PHP/ecc. non permettono l'esecuzione di più di un comando alla volta: e l'attacco, per funzionare in maniera così "generica" e quindi infettare un numero così alto di server, aveva bisogno di eseguire due comandi di seguito. Volendo è possibile tentare un attacco del genere sfruttando i bachi di altre piattaforme ma non sarebbe stato scalabile come quello del post in quanto ogni piattaforma diversa avrebbe richiesto un exploit diverso. Questa in fondo era la "virtù" di questo attacco: un exploit generico che si autoadattava alla piattaforma sottostante.
Permalink
giovedì 3 luglio 2008 alle 3:49 PM -
Date un'occhietto qua, può servire: www.sandeisacher.net/.../sql-injection-u
Ciau!
Permalink