FBI vs. hacker: arrestato un altro Lulz – Raynaldo Rivera #Lulz #fbi #sabu #Sony #psn #hacker #sqlinjection

Sabu: chi era costui? Fossi Manzoni potrei anche diventare famoso per una frase di questo tipo. Se non ricordate vi rinfresco la memoria: Sabu era un membro dei LulzSec poi entrato a far parte di Anonymous dopo la vicenda che coinvolse il Play Station Network (PSN) ed il furto di qualche milioncino di password ed account. Il fatto principale di Sabu è che è un traditore degli hacker con cui ha operato, diventando collaboratore dell’FBI.

SQL-Injection

SQL-Injection

Leggo sul Corriere che è stato arrestato Raynaldo Rivera, un altro esponente del gruppo dei Lulz che, attraverso un attacco di tipo SQL-injection, ha prelevato dal sistema online di Play Station i dati degli utenti. Il caso, ai tempi, fece scalpore perché mostrò l’estrema inefficacia con cui venivano custoditi i dati da un’azienda del calibro di Sony.

Al di là della notizia di cronaca, di cui alcuni sranno felici, altri meno, provo a spiegarvi quest’altra tipologia di attacco che differisce dal tipico attacco Anonymous che, di norma, è di tipo DoS o DDoS (seguite il link per vedere cos’è un attacco DoS).

Cos’è SQL?

Per definire questo attacco dobbiamo prima definire cos’è un database e cos’è SQL.

Un database è una sorta di enorme contenitore ottimizzato per contenere i dati e, se fatto bene, per far sì che questi siano in qualche modo collegati con diverse modalità di relazioni. Ipotizziamo un paio di dati per fare un esempio semplice: una persona e la casa di cui è proprietario.

Persona e Casa sono due entità distinte che, prese così, non hanno nulla a che fare l’una con l’altra. Se, però, io dico che esiste una relazione e dico che, laddove esiste questa relazione, sto indicando in maniera univoca il proprietario di una casa, ho creato tra le due entità un legame. Questo concetto porta, in fase di progettazione, a schemi chiamati Entità-Relazione e servono a progettare database di più o meno tutte le dimensioni e le complessità.

I database, come la maggior parte degli oggetti informatici, hanno un proprio linguaggio di programmazione. Nel caso specifico, visto che si tratta di dati, il linguaggio dovrà garantire alcune operazioni chiave che si dividono in due categorie: DDL (Data Definition Language) e DML (Data Manuipulation Language)

Prendiamo come esempio una libreria per fare un parallelo. Il DDL serve a creare le strutture dati, (schemi, tabelle, relazioni) ovvero costruisce la nostra libreria, regola il numero di scaffali, le dimensioni, le distanze ecc.; il DML gestisce i dati, peratnto gestisce i libri all’interno della nostra libreria di esempio. Con la prima creiamo, quindi, l’intelaiatura, con la seconda abbiamo operazioni di aggiunta dati, aggiornamento, estrazione ed eliminazione.

Questo linguaggio si chiama SQL.

Cos’è SQL-Injection?

Iniezione SQL. Per l’esattezza inserimento di codice malevolo nelle stringhe SQL.

Passiamo alla parte nerd cercando di non entrare troppo nella parte tecnica. Partiamo da qualcosa che, se state navigando su questo blog, potete vedere da voi. In alto, nel browser, c’è una cosa chiamata “Barra degli indirizzi” o simile. In pratica è il punto in cui potete scrivere l’indirizzo di un sito internet. Là sopra, di tanto in tanto, vedete delle scritte strane che non sono di immediata comprensione. Se, per esempio, guardiamo Google, a seguito della ricerca “perova di ricerca” vedremo scritto in alto una cosa tipo: http://www.google.it/#q=prova+di+ricerca&hl=it&safe=off&biw=1366&bih=637&fp=1&bav=on.2,or.r_gc.r_pw.r_qf.&cad=b.

Senza stare ad analizzare tutto, possiamo evidenziare la presenza delle nostre parole di ricerca subito dopo un “q=”. In linea teorica quella q potrebbe stare per un “query” o qualcosa di simile, ma è un’ipotesi che sto facendo in questo istante.

In gergo si dice che l’informazione è stata inviata in GET, ovvero tutta la parte successiva agli indirizzi “semplici” di norma contraddistinta da un simbolo (generalmente il ?, anche se google ha introdotto nel proprio motore il #, ma il principio è il medesimo).

Un attacco di tipo SQL-Injection può partire da quel livello. Sostituisco nella querystring le parole che mi interessano ed il gioco è fatto. Il fatto è sapere quali sono le parole che mi interessano e poi vedere se chi ha programmato il codice ha adottato le misure adeguate per prevenire l’attacco.

Ci sono dei caratteri speciali e delle istruzioni che “rompono” il codice sorgente dell’applicazione online, oppure che consentono di introdursi nelle istruzioni SQL. Faccio un esempio per il codice ASP ipotizzando una pagina che ricerca i nomi nel database a cui viene passato questo tipo di informazione test.asp?nomeDaCercare=Fabrizio e che ritorna l’elenco di tutti gli utenti il cui nome è Fabrizio. Se io cambio manualmente l’indirizzo in test.asp?nomeDaCercare=Alessio ritornerà tutti gli utenti con nome Alessio.

Per “rompere” il codice è sufficiente usare i caratteri di commento che nell’ASP, per esempio, è l’apice singolo, quindi potrei provare a scrivere test.asp?nomeDaCercare=Fa’brizio  e vedere se la pagina va in errore. Se va in errore c’è la possibilità che il programma che c’è sotto non esegua il controllo e probabilmente potrebbe riportarmi la query che va in errore.

A quel punto posso iniziare a provare a fare SQL-Injection usando i caratteri di termine istruzione e/o di commento dell’SQL che sono, rispettivamente, il punto e virgola ed il doppio meno (; e – -) e le istruzioni SQL DML. Nell’esempio di prima si può provare una cosa di questo tipo: test.asp?nomeDaCercare=Fabrizio’ OR 1=1; – -.

Visto che 1=1 è una condizione sempre vera, se il codice del programma non effettua i controlli, con quella istruzione riusciremo ad estrarre tutti i nominativi del database senza colpo ferire (l’apice serve a chiusura della stringa, il punto e virgola a terminare l’istruzione ed il doppio meno a commentare l’apice di chiusura che, qusi certamente, sarà presente nel codice dell’applicazione). A quel punto (se un’operazione del genere va in porto), abbiamo in mano, in pratica, il database ed il sito. Oltre ad usare istruzioni di quel tipo, infatti, possiamo iniziare ad introdurre istruzioni DDL che ci consentano di “leggere” i nomi delle tabelle del database e, di conseguenza, effettuare tutte le query necessarie a scoprirne la struttura (quindi quali campi sono all’interno delle varie tabelle, il loro tipo e così via), con l’unica accortezza di scrivere le opportune istruzioni e i giusti punti e virgola.

Nel caso il database dell’applicazione fosse un SQL-Server scriveremmo qualcosa tipo: test.asp?nomeDaCercare=Fabrizio’ OR 1=1; SELECT * FROM sys.tables; – – ed otterremmo lo schema completo dei nomi delle tabelle e, con altre istruzioni, saremmo in grado di ottenere i nomi dei campi. Da lì è fatta. Ovviamente, non è proprio così scontato in quanto ci sono potenziali problemi sul tipo di variabile, su eventuali cicli, su letture dei nomi delle colonne, su eventuali overflow ecc., ma il principio di base è quello.

Ipotizziamo esista una tabella Anagrafiche e che i campi siano Nome, Cognome, Mail, Password. Scrivendo test.asp?nomeDaCercare=Fabrizio’ OR 1=1; SELECT * FROM Anagrafiche; – – Alle stesse condizioni sopra descritte (tipo avriabili ecc.) verranno estratti tutti i dati, pertanto tutti i nomi, associati ai cognomi, alle mail e alle relative password. In pratica posso ottenere l’intero database.

Annunci

Un pensiero su &Idquo;FBI vs. hacker: arrestato un altro Lulz – Raynaldo Rivera #Lulz #fbi #sabu #Sony #psn #hacker #sqlinjection

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...