L’SSDT hooking sta diventando obsoleto?
Oggi come oggi abbiamo a che fare con migliaia di nuovi malware ogni giorno e l’utilizzo di tecnologie rootkit è diventato comune tra i malware writer. Spesso, i rootkit utilizzati nelle infezioni da malware sono comuni l’un l’altro, sfruttano tecniche che siano relativamente facili da sviluppare ma allo stesso tempo il più efficaci possibili.
Qualche volta abbiamo per le mani interessanti proof of concept, spesso sviluppati per dimostrare le vulnerabilità degli scanner antirootkit o, semplicemente, per evidenziare qualche nuova idea per nascondere file all’interno dei pc. Tuttavia, più avanzate sono le tecnologie, più difficilmente saranno utilizzabili su larga scala per difficoltà di programmazione.
Dati alla mano, dopo i rootkit user mode, la tecnica più utilizzata è l’hooking dell’SSDT (System Service Descriptor Table), cioè il reindirizzamento dei puntatori dalle funzioni esportate dal kernel a funzioni scritte appositamente per alterare i risultati. Tecnica relativamente facile da scrivere, potente, ma soprattutto esistono su Internet moltissimi sorgenti che ne illustrano la programmazione.
Ciò non toglie che esistano molte altre tecniche per nascondere un rootkit all’interno del sistema, ma spesso queste tecniche vengono rilasciate esclusivamente sotto forma di proof-of-concept, perché necessiterebbero di una complessità di programmazione non alla portata di tutti.
Per questo quando il rootkit Rustock venne rilasciato, la maggior parte delle società antivirus non furono pronte alla battaglia. Rustock utilizzò tecniche totalmente differenti dai rootkit in-the-wild che avevano fatto la loro comparsa fino a quel momento. L’hooking degli handler dell’INT 2E e SYSENTER, sebbene fosse una tecnica documentata, non era mai stata vista realmente in azione e molti scanner antirootkit non avevano preso in considerazione questa possibilità.
Escludendo Rustock, che utilizza più tecniche contemporaneamente per nascondersi ed è considerato ancora il rootkit più complesso in-the-wild, ed escludendo i proof-of concept che sono sviluppati esclusivamente per dimostrare al mondo nuove tecniche, la maggior parte dei rootkit kernel mode ITW utilizza la tecnica dell’SSDT hooking (Haxdoor, Peacomm, Oddysse, la componente rootkit di Beagle…).
Questo fino a questi ultimi mesi, fino a quando non abbiamo visto due rootkit ITW utilizzare tecniche conosciute ma mai applicate da malware in-the-wild e, ancora, alcuni scanner antirootkit si sono persi.
Almanahe e Srizbi utilizzano due tecniche interessanti, differenti tra di loro ma allo stesso tempo simili.
Srizbi, una volta installato, utilizza la tecnica dell’inline hooking in alcune funzioni esportate dal kernel. Cosa significa? Semplicemente che i puntatori SSDT non sono stati toccati in nessuna maniera, perché l’hook si trova all’interno della funzione. Se questa è una tecnica largamente utilizzata dai rootkit user mode, non è poi così diffusa nell’ambito dei rootkit kernel mode. Di conseguenza alcuni rootkit scanner che controllano esclusivamente se l’SSDT punta a indirizzi di memoria interni al range di memoria del kernel sono bypassati. Un approccio sbagliato, perché un’analisi del codice avrebbe aiutato ad individuare il rootkit (al momento non voglio focalizzare sulla parte dell’hooking del driver NTFS).
Almanahe, installato nel sistema, si comporta invece in maniera più carina. Controlla dello spazio libero, inutilizzato all’interno del kernel e, una volta trovato, utilizza inline hooking lì - classico PUSH/RET. Poi modifica i puntatori nell’SSDT, reindirizzandoli verso la nuova sezione appena creata.
Ora si possono venire a creare tre situazioni con gli scanner antirootkit:
Scanner che controllano esclusivamente se l’SSDT punta a indirizzi esterni al range del kernel (tecnica maggiormente utilizzata: in entrambi i casi queste tipologie di antirootkit sono bypassati poiché gli indirizzi cadono all’interno del range di memoria del kernel; Scanner che, oltre al controllo sopra evidenziato, comparano se le funzioni dall’SSDT puntano alla corretta funzione esportata dal kernel: nel caso di Srizbi queste tipologie di antirootkit sono bypassate perché gli hook sono inseriti all’interno dei primi bytes della funzione. Nel caso di Almanahe, si viene a creare una simpatica situazione: le funzioni controllate dal rootkit dall’SSDT non puntano dove dovrebbero puntare, cioè alla funzione reale esportata dal kernel. Di conseguenza gli scanner antirootkit tentano di controllare a quale modulo appartiene l’indirizzo a cui punta l’SSDT il quale, sorpresa, appartiene a ntoskrnl. Chi è che modifica le funzioni? Secondo alcuni antirootkit è lo stesso kernel di Windows. All’occhio di una persona non propriamente esperta sembrerebbe che lo scanner in questione abbia inciampato in un falso positivo, è impossibile che lo stesso kernel modifica le proprie funzioni. In effetti non è il kernel il colpevole di tutto, è l’SSDT che punta ad una zona interna al kernel dove poi il rootkit ha aggiunto i propri inline hook verso il proprio driver; Scanner che, oltre a fare quello sopra elencato, hanno funzioni di code analysis per scoprire possibili modifiche interne alle funzioni: in questo caso, dipende ovviamente da che livello di analisi lo scanner sta effettuando, è possibile individuare entrambi i rootkit correttamente. Se Srizbi è individuabile con una tecnologia di code analysis relativamente semplice, Almanahe non è così semplice da individuare. La logica sarebbe: se dall’SSDT si punta all’interno del kernel ma non dove si dovrebbe puntare correttamente, perché il kernel di Windows dovrebbe modificare le proprie funzioni? Di conseguenza, se dall’SSDT non si esce dalla zona del kernel, ma all’interno del kernel non si punta a dove sarebbe corretto puntare, sta succedendo qualcosa di strano e mostrare semplicemente che ntoskrnl sta modificando le proprie funzioni potrebbe risultare dannoso, non che impreciso e sintomo di un’analisi non troppo approfondita da parte del software antirootkit.
Sicuramente, anche se alcuni software antirootkit mostrano erroneamente ntoskrnl che hooka le funzioni, riescono tuttavia a ripristinare l’SSDT sistemando le corrette chiamate e, comunque sia, molti scanner antirootkit forniscono più di un tool per individuare possibili infezioni in modo tale che non debbano affidarsi ad una sola tecnologia.
L’unica preoccupazione è che già due rootkit in-the-wild stanno utilizzando approcci per nascondersi differenti da quelli che si sono visti fino ad ora dalla maggior parte dei rootkit kernel mode in-the-wild. Quasi un segnale che i malware writer sono pronti a cambiare tecniche su larga scala per evadere dai software antirootkit, e non solo con proof-of-concept quasi mai realmente utilizzati per attacchi. La tecnica dell’hooking dell’SSDT sta diventando obsoleta: Rustock, Almanahe e Srizbi ne sono un chiaro esempio. Noi siamo pronti a combattere?
Concludo con un semplice video che vorrebbe nuovamente replicare a tutte le persone che chiedono se Windows Vista sia vulnerabile ai rootkit. Ne avevo già parlato QUI e QUI, riprendo a distanza di tempo l’argomento.
Sicuramente con l’UAC attivato è difficile caricare un driver senza l’interazione dell’utente (non voglio focalizzare su trucchi di ingegneria sociale e PoC per “bypassare” l’UAC), ma è veramente sicuro dai rootkit?
Lo scopo dei rootkit è quello di nascondersi dagli occhi degli utenti, possono farlo con tecniche semplice fino a compromettere il kernel del sistema operativo: alla fine, il risultato è lo stesso.
Per cui, anche se un rootkit user mode è più difficile da individuare, a meno che non abbiate dubbi di essere infetti con un rootkit - e la maggior parte degli home user, piccole e medie aziende neanche sanno cosa sia un rootkit - non vi troverete mai a scaricare un antirootkit standalone per ricercare se siete infetti da rootkit, pensate che un antivirus sia sufficiente (in alcuni casi neanche l’antivirus serve secondo alcuni pareri).
Può, dunque, un rootkit user mode infettare Vista? Vediamo come un rootkit ben conosciuto - Vanquish è un rootkit user mode che utilizza inline hooking - si comporta su Vista.
daniele_dll
Luglio 9th, 2007 at 17:18
come sempre mitico
steve75
Luglio 10th, 2007 at 22:58
grande Marco …(applauso)
nV 25
Luglio 11th, 2007 at 19:49
eraser è davvero uno che sa…
CLAP CLAP + inchino….
gigi
Luglio 12th, 2007 at 15:08
qualunque sistema operativo può avere rootkit.
Marco
Luglio 12th, 2007 at 16:50
Io ne sono più convinto di te
Sono altri che non ci credono 
ste4lth
Luglio 12th, 2007 at 18:39
Questo tipo di inline hooking e’ vecchio e facilmente individuabile.
Molto tempo fa (primi mesi del 2006) alcuni ricercatori si erano sfidati nella sfida di realizzare il “1-byte hook” senza alcuna jump e bugcheck di Rootkit.com ci e’ riuscito abilmente (costringendo Rutkowska ad aggiornare il suo tool SVV).
http://rootkit.com/blog.php?newsid=451&user=bugcheck
http://invisiblethings.org/papers/rutkowska_bheurope2006.ppt
E naturalmente qualsiasi persona abbia visto in azione
il rootkit di Apropos un paio di anni fa potra’ raccontare della
tecnica di hook polimorfico ibrido SDT/IDT veramente avanzata.
In sostanza, questi due rootkit non fanno nulla di nuovo…
Marco
Luglio 12th, 2007 at 20:57
Sul fatto che sia individuabile sono d’accordo con te, ma se fai un controllo con scanner antirootkit molti sbagliano l’individuazione (parlo di quelli che controllano l’SSDT).
Come dicevo nell’articolo - e come risottolinei tu - tecnicamente parlando non fanno nulla di nuovo anzi, sono tecniche conosciute gia da tempo. Apropos era molto carino da questo punto di vista: causava un’eccezione gestita poi dall’IDT. Ovviamente l’IDT era già stato modificato per puntare al proprio driver.
C’è un però: le tecniche sviluppate come proof of concepts non vanno di pari passo con quelle utilizzate in the wild.
Basta vedere un rootkit come Unreal, che non utilizzava nessuna tecnica particolarmente nuova - tutto era conosciuto, ma non era mai stato applicato nella forma quale poi fu quella di Unreal.
Un rootkit come Unreal, ma anche a suo tempo Rustock, mostrarono quanto fossero indietro gli scanner antirootkit esistenti all’epoca.
Almanahe e Srizbi non utilizzano niente di nuovo, ma quello che utilizzano l’hanno portato in-the-wild, segnando di conseguenza il pensionamento degli scanner nell’articolo illustrati.
Ciao!
gnocca senza testa
Luglio 14th, 2007 at 11:45
E’ possibile vedere Marco Giuliani in costume da bagno? Grazie
Lucass
Luglio 14th, 2007 at 15:21
Come no, 2 settimane fa, era in giro la foto di marco completamente nudo, da quello che so, qualcuno ha pagato è la foto è stata ritirata!!!!!
Ciao
Marco
Luglio 14th, 2007 at 15:23
Non è mica un bello spettacolo
nV 25
Luglio 14th, 2007 at 23:01
eraser, non è mica che ti interessa il mio “vecchio” Pc per continuare i tuoi studi &/o le tue ricerche?
Ti assicuro che riusciresti a comprartelo anche con il salario che ti passa la PrevX!!!
)
Per tornare a noi, nudo no, per cortesia!
Molto meglio puntare su nV 25 per ’sto genere di cose..!
:))))))
m4v3rick
Luglio 15th, 2007 at 02:57
cavolo ma siete pazzi? adesso tutti i viruswriter del mondo sapranno come ricattare marco. Questi sono peggio di corona. Niente tool di rimozione malware altrimenti foto
di marco nudo per la gioa delle fanciulle che popolano il cyberspazio.
:-)
juninho85
Luglio 15th, 2007 at 11:43
vogliamo marco giuliano col due pezzi tigrato!:D
juninho85
Luglio 15th, 2007 at 11:44
vogliamo marco giuliani col due pezzi tigrato!:D
MaschioneDelSud
Luglio 21st, 2007 at 11:58
anche io voglio la foto.