La maggior parte dei software di sicurezza sotto windows svolgono il loro compito basandosi oltre che sulle firme, sulle caratteristiche di vulnerabilità note nel corso del tempo sui sistemi microsoft, altri ancora lavorano sull'user mode, e cosi via. Questa metodologia aggiuntiva di approccio utilizza la tecnica del kernel hooking.

Molti produttori (di cui trovate una lista sotto) hanno deciso di modificare la parte del kernel del sistema che implementa il meccanismo di chiamata, tramite la tecnica detta SSDT hooking, ossia la modifica dei contenuti di System Service Descriptor Table

La tecnica in esame, consiste nel consentire ad un utente remoto di bypassare questa metodologia di approccio di protezione, e iniettare codice nocivo nel sistema. Una sorta di privilege escalation, attuata tramite la vulnerabilità insita nella stessa tecnologia di protezione. L'attacco è efficace sia contro le varie modalità utente, che contro le kernel hooks.

Il proof of concept sviluppato dalla MatoUsec Corporation, prende in esame le SSDT, in quanto sono le kernel hooks più utilizzate al momento dalle case di sicurezza.
Possiamo dunque definire l'attacco un bypassing del modulo denominato System Service Descriptor Table (SSDT) collegato al kernel di Windows, sfruttato i tutti i software Antivirus. Una sorta di race condition con un tasso abbastanza elevato di successo che permette ad un malware di bypassare tutti gli antivirus che utilizzano la tecnica dell'SSDT hooking per interfacciarsi col kernel, ossia il 90% degli antivirus in commercio.

I software affetti da tale vulnerabilità al momento sono i seguenti :



=== Vulnerabilità ===

Le applicazioni comunicano con il kernel del so attraverso le funzioni esportate dalle varie librerie di collegamento dinamico delle API di win, quali
kernel32.dll, user32.dll, advapi32.dll e ntdll.dll.
Queste routine di solito trasmette il flusso di esecuzione alle librerie di interfaccia, ntdll.dll (e in parte user32.dll e gdi32.dll), che utilizza le istruzioni speciali, come INT 0x2E, SYSENTER o syscall, per chiamare il kernel.
Le hooks si pongono all'inizio di questo processo, evitando che venga trasmesso codice nocivo.
Tuttavia, tutte le librerie di linking dinamico risiedono nella parte user-mode dello spazio di indirizzo del processo, quindi, se l'applicazione necessita di comunicare con il kernel, è possibile utilizzare l'istruzione di chiamata di sistema direttamente.
E questa azione non può essere bloccata da nessuna forma di hooking.


=== Proof of Concept ===

Un chiarimento generale sulle SSDT:
Le System Service Descriptor Tables appartengono alla modalità kernel di implementazione dell'interfaccia di chiamata sistema e contengono gli indirizzi delle routines.
Attraverso SSDTs, si può controllare ogni passaggio utile dalla modalità utente alla modalità kernel.
Il security hooking spesso modifica indirizzi memorizzati nelle tabelle per puntare a proprie routine e funzioni di hooking.
Queste funzioni eseguono controlli per verificare pericoli per il sistema o minacce per la sicurezza delle applicazioni stesse.
In questi casi, il gestore di hooks chiede all'utente finale quale azione intraprendere.

Da questo ragionamento è nato il Proof of concept sviluppato dalla MatoUsec relativamente alle SSDTs, all'interno del progetto KHOBE (Kernel Hook Bypassing Engine), un malware sviluppato appositamente per mettere in pratica la linea teorica di bypassing spiegata brevemente sopra.

Per chi volesse approfondire l'argomento (che è sinceramente abbastanza lungo da trattare qui, e la resa in italiano non è sempre ottimale ed esplicativa del concetto quanto quella inglese) :

http://www.matous...ftware.php <<< KHOBE
http://www.sophos...th-shaker/ <<< La risposta della azienda SOPHOS, relativamente alla NON vulnerabilità (secondo loro e il loro HIPS) del malware.