Innanzitutto, bisogna sapere che un rootkit è un insieme di programmi che permette ad un attaccante di violare un computer ottenendo i massimi privilegi possibili (privilegi di root) in modo non rilevabile e permanente.
La parola stessa quindi deriva da "kit di root".
In questo articolo andremo ad analizzare i rootkit che agiscono in kernel mode con architetture a 32bit, più precisamente, quei rootkit che sfruttano la scarsa sicurezza della System Service Descriptor Table (SSDT) del kernel NT.
Ci terrei a precisare che questa tecnica è nata insieme ai primi rootkit, non ufficialmente, intorno al 2000 ed è, in questo momento, forse la tecnica più banale e più rilevata dai sistemi anti-rootkit in circolazione, a causa dell'enorme mole di materiale sul web che ne illustra (spesso con l'ausilio di codici completi) il suo funzionamento.
La tabella SSDT è una delle più importanti tabelle di tutto il kernel Nt, ed è quella che comunemente è chiamata "Dispatch Table", cioè tabella di indirizzamento perché serve al sistema operativo per indirizzare le applicazione che operano a ring 3 (User mode) alle API native. Si trova in una struttura chiamata KeServiceDescriptorTable. Le API native, appunto, sono API fornite dal kernel per permettere alle API dei sotto sistemi (win32 ecc..) di svolgere determinate operazioni possibili solo in kernel mode.
Dentro la suddetta tabella, quindi, troviamo un array di puntatori che puntano a queste API.
Quindi, in linea teorica, noi non potremmo usare le API native, perché sarebbe come operare in kernel mode e infatti il kernel prevede che il sistema di funzionamento di un applicativo sia: Applicativo -> API del sottosistema -> API Nativa -> Kernel NT.
I rootkit che operano a 32 bit sfruttano appunto la tabella SSDT per interfacciarsi direttamente con il kernel, usando un sistema di funzionamento diverso, cioè: Applicativo -> API Nativa -> Kernel NT.
Il rootkit ha quindi, il compito di:
-Trovare l'indirizzo della tabella SSDT, importanto la struttura della KeServiceDescriptorTable
-Leggere l'indirizzo dell' API nativa che gli interessa
-Richiamare l'API nativa e quindi avere, con i limiti dell'API stessa, i massimi privilegi sul sistema.
Come al solito, non posso dilungarmi troppo e spiegare tutto il procedimento di creazione di un rootkit qua in questo articolo, ma vi consiglio di scaricare questo interessantissimo PDF in italiano Rootkits.pdf e se volete qualcosa di più pratico, vi consiglio questo articolo: [Tutorial] Writing drivers to perform kernel-level SSDT hooking. . Poi consiglio per approfondimenti di cercare un po su google, anche se è necessaria la conoscenza dell'inglese
Se avete problemi a comprendere la guida che vi ho linkato, chiedete pure e cercherò, come sempre, di rendere la cosa un po più semplice, anche se penso che sia molto chiara.
Vorrei comunque accennarvi che con l'avvento della tecnologia a 64 bit non è più così semplice fare un rootkit che agisce tramite l'SSDT Hooking, perché la microsoft, si è resa conto che il suo kernel era un pò titubante e ha deciso di implementare una specie di sistema di sicurezza, che però ovviamente è vulnerabile ugualmente (solo la microsoft può farsi bucare in così poco tempo) cioè, la SSDT adesso è formata da un array di puntatori ottenuti dall'operazione: (Indirizzo Funzione Nativa - Indirizzo KiServiceTable) << 4
Questa "protezione" è bypassabile con un driver dove è implementato un algoritmo di analisi della KeSystemServiceStart.
Spero quindi di aver suscitato in voi un minimo di interesse in quello che è lo studio della sicurezza informatica, che come al solito alla fine, non può che trasformarsi, in un modo per studiare nuovi sistemi per attaccare il sistema.
A breve farò anche un'articolo quasi alla portata di tutti, che spiega come sfruttare la IAT Hooking su un programma per manipolarlo a nostro piacimento.
Intanto, buono studio
Nessun commento:
Posta un commento