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.

    (Prevx Blog)