Uno degli hacker sospettati di essere dietro all’attacco a TalkTalk—che ha comportato il furto delle informazioni personali di almeno 150.000 persone—ha sfruttato una vulnerabilità scoperta due anni prima che lui nascesse.
Il metodo di attacco consiste nell’inserimento di codice non previsto all’interno di una query SQL (da qui il nome SQL injection) per far eseguire a un determinato sito dei comandi normalmente non eseguibili da un utente privo di autorizzazioni specifiche. È stato usato per rubare informazioni personali degli impiegati della World Heath Organization, prelevare dati dal Wall Street Journal e colpire i siti delle agenzie federali americane.
Videos by VICE
“È il modo più semplice per attaccare,” ha detto a Motherboard l’hacker che si fa chiamare con lo pseudonimo w0rm, responsabile dell’attacco al Wall Street Journal. Sono bastate “poche ore.”
Ma proprio per la sua semplicità e nonostante la sua efficenza nello scandagliare i fondali digitali di corporazioni e governi, SQLi è relativamente facile da contrastare.
Allora perché, nel 2015, SQLi è ancora lo strumento fondamentale di alcuni degli attacchi più importanti del momento?
SQLi è stato documentato per la prima volta da Jeff Forristal, sulla rivista per hacker Phrack. All’epoca, Forristal si faceva chiamare rain.forest.puppy, mentre ora è CTO del reparto di sicurezza su dispositivi mobili alla Blubox.
“Secondo Microsoft non c’è niente di cui preoccuparsi.”
SQL, o Structured Query Language, è un linguaggio di programmazione usato per gestire i database. In pratica, si usa quando un sito ha bisogno di recuperare un pezzo di informazione dal suo database, che sia per elaborarlo o per presentarlo a un utente.
Ma Forristal aveva scoperto che digitando una serie di comandi riusciva a costringere il server a rivelare le informazioni protette. “Le persone possono seguire i comandi SQL,” ha scritto.
Sul numero di Phrack di dicembre 1998, Forristal ha scritto a proposito di una serie di problemi relativi a una versione di server SQL di Microsoft. Quando un ricercatore amico di Forristal ha avvertito Microsoft dei problemi, “la risposta è stata ridicola,” ha scritto. “A detta loro, quanto state per leggere non è un problema, quindi non cercate un modo per risolverlo.”
Oggi, dopo oltre 15 anni dalla sua rivelazione pubblica, SQLi resta in testa alla classifica delle vulnerabilità nel report OWASP, che è aggiornato ogni tre anni dalla Open Web Application Security Project (OWASP) Foundation, una no-profit che monitora le minacce affrontate dai siti.
“Un’iniezione SQL è sempre il rischio numero uno. È il riflesso del numero di incidenti che avvengono ogni giorno,” ha detto a Motherboard Troy Hunt, fondatore del sito haveibeenpwned.com in un’intervista telefonica.
“Quando andate su una pagina web e fate una richiesta, parte dei dati nella richiesta è ricondotta a un server,” ha detto Hunt. “Per esempio: leggete un articolo, e questo articolo ha nella barra URL “id=1″, che sta per articolo numero 1, e poi ne avete un altro con ID 2.”
Ma, “con un attacco SQLi, l’hacker modifica quell’ID dell’indirizzo in un valore che costringe il database a fare qualcosa che non dovrebbe,” ha detto Hunt. Tipo fornire dati privati.
Un attacco singolo potrebbe restituire solo un pezzo o una sezione di informazioni, ecco perché chi compie l’attacco tende a “ripeterlo più volte, tutte quelle necessarie, così da prelevare ogni frammento di dati dal database,” ha detto Hunt.
Naturalmente, la cosa porta via un sacco di tempo. Allora un hacker potrebbe usare degli strumenti che svolgano il processo in modo automatico. Tra cui ricordiamo Havij, che “è popolare tra gli script kiddie perché è per Windows e ha un'[interfaccia grafica],” ha detto a Motherboard Mustafa Al-Bassam, un ricercatore in sicurezza ed ex hacker per LulzSec su una chat online.
Un altro software usato comunemente è sqlmap. “Striscia tra le pagine di un sito un po’ come farebbe lo spider di un motore di ricerca, cerca form di input sul sito e invia i form con gli input che potrebbero causare un errore di sintassi MySQL,” ha aggiunto Al-Bassam.
Quando chi compie l’attacco sta cercando un obiettivo da colpire in particolare, può automatizzare anche questa richiesta.
Usano Google per cercare gli URL che è risaputo essere associati a script attaccabili via SQLi,” ha detto Al-Bassam. “In genere mettono uno script a sfogliare tutti gli URL e a testarli automaticamente per vedere se sono vulnerabili.”
“Potresti insegnare come si fa a un bambino di quattro anni,” ha aggiunto Al-Bassam, rendendo bene l’idea di quanto sia facile l’intero processo. A tal proposito, Hunt ha caricato un video in cui insegna al figlio di tre anni come sferrare un attacco SQLi tramite Havij.
“Metti l’URL ed ecco tutti i dati,” ha detto Hunt a Motherboard. Ci sono valanghe di tutorial su YouTube su come compiere un attacco SQLi.
Il punto è che ci sono soluzioni pronte per essere impiegate dagli sviluppatori dei siti per fermare gli attacchi SQLi e il furto—evitabile, a questo punto—dei dati di clienti e corporazioni. E queste soluzioni sono in giro da anni.
Una di queste è l’adozione di “prepared statement”: ovvero quando i comandi SQL che controllano il database non possono essere dettati direttamente dall’input di un utente.
Se le soluzioni sono così semplici, perché ci sono ancora degli attacchi SQLi?
“Il vantaggio di queste “formule precostituite” è che stabiliscono la semantica di una query di modo che i dati in entrata non sorprendano lo sviluppatore, includendo la sintassi che cambia una query destinata a scaricare una singola riga di codice in una query che estrae dati da tabelle arbitrarie,” ha detto Mike Shema, senior manager, software development engineer di Yahoo! a Motherboard.
Un altro modo è “usare le library SQL Injection che si occupano di ripulire gli input per loro,” ha suggerito Al-Bassam. Questo, in breve, passa al setaccio ogni dato inserito dall’utente per rimuovere parti potenzialmente dannose.
Quindi, se SQLi è così facile da usare che anche un bambino potrebbe farlo, e le soluzioni sono così semplici, perché avvengono ancora degli attacchi?
“Ogni vero programmatore dovrebbe conoscere SQLi, ma in questo momento c’è carenza di manodopera quindi le compagnie assumono chiunque, anche gente che non ha alcuna esperienza nel campo della sicurezza,” ha aggiunto Al-Bassam. Oltre a questo, “spesso i loro manager insistono su software funzionali piuttosto che sicuri.”
Shema di Yahoo! conferma, e aggiunge che “a volte le piccole app con caratteristiche base devono essere scritte velocemente,” intendendo che gli sviluppatori, spesso, trascurano la possibilità di ridurre gli attacchi nella fretta di dover implementare.
Hunt è molto meno clemente e non è d’accordo con il fatto che la colpa sia dei piani alti. Piuttosto, ha lamentato la grande quantità di tutorial disponibili per i web developer che, piuttosto che dare buoni consigli, spiegano dettagliatamente come rendere i sistemi vulnerabili a SQLi. “Ho visto diversi tutorial quest’anno con clamorosi rischi di attacchi SQL” ha detto.
Così come i ragazzini che continuano a condividere i loro tutorial su YouTube, anche gli sviluppatori condividono continuamente informazioni sul web. “Questa nuova possibilità di trasmettere le nostre conoscenze a chiunque non ha soltanto aspetti positivi” ha aggiunto Hunt.
In definitiva, la responsabilità per la sicurezza dei siti e dei dati che contengono ricade sugli sviluppatori stessi. Il che significa che SQLi e le falle che procura resteranno, almeno per un po’.