Rootkit

Torna alla pagina di Gestione degli incidenti informatici

---

:: Rootkit ::

Definizione

I rootkit sono binari/eseguibili/librerie il cui compito è garantire all'intruder la permanenza nel sistema; rappresentano la fonte più comune di compromissione, ovvero l'insieme di circostanze che portano l'attacker a prendere possesso della macchina.
Fissiamo dunque il concetto: la macchina si buca con l' exploit e si compromette con i rootkit.

Questo genere di malware ha avuto un boom nella seconda metà degli anni '90, ma in alcune comunità erano già noti dal decennio precedente; uno in particolare - log cleaner - aveva dimostrato che fonti di prova come i log, normalmente considerati trusted, potevano in realtà essere a loro volta compromessi, specie se salvati in locale.

Tipologie

I rootkit potrebbero essere classificati in base alle loro implementazioni e funzionalità.

Considerando le funzionalità, ogni rootkit ne ha una specifica, e anche due della stessa tipologia possono avere numerosissime variabili che li differenziano: solo colui (o colei) che l'ha realizzato può averne un quadro completo. Ciononostante è possibile ricondurli tutti (o quasi) a tre possibili scopi alternativi:

• mantenere l'accesso al sistema, generalmente sfruttando l'esistenza di backdoor
• utilizzare il sistema come testa di ponte, ovvero utilizzarlo come tramite per attacchi verso altri sistemi
• cancellare le tracce lasciate dall'intrusione. Ad esempio se il rootkit agisce in locale potrebbe cancellare il log, mentre da remoto potrebbe disabilitare il daemon che ne tiene traccia

Da notare che i primi due casi sono legati a problemi di segretezza, mentre l'ultimo è un problema di incident management.

Per quanto riguarda le implementazioni potremmo distinguerli in:

• binary rootkit, che vanno a sostituire alcuni binari del sistema con versioni alterate degli stessi. Sono chiamati anche User Land rootkit
• kernel rootkit, che utilizzano moduli del kernel costruiti su misura per nascondere la presenza degli intruder
• library rootkit, che fanno uso delle librerie di sistema per i loro fini
• blended rootkit, che combinano le tre strategie appena viste

Storicamente ci si sta muovendo dai binary rootkit ai kernel rootkit. I primi infatti risiedono nel file system, dunque sono relativamente semplici da rilevare grazie alle signature che caratterizzano il loro codice; la ricerca avviene con meccaniche già note per altri malware, come i virus. I secondi invece sono infinitamente più dinamici, dato che i moduli del kernel sono caricati all'occorrenza e dunque non rilevabili se non con un apposito modulo di controllo caricato in RAM (ovviamente, non statico).

Approfondiamo questi tre tipi di rootkit.

Binary rootkit

Abbiamo già detto che i primi rootkit a comparire sono stati quelli di tipo binary, anche detti user land rootkit. La tecnica da loro utilizzata è sostituire i binari di sistema più critici (come bin/login) o i daemon di rete con altri creati su misura per la compromissione della macchina, ovvero trojan e/o binari progettati per raccogliere informazioni sullo stato dei processi e della rete.

A seconda dei loro obiettivi possiamo suddividerli in cinque categorie:

• quelli che garantiscono un accesso privilegiato al sistema da remoto
• quelli che garantiscono un accesso locale privilegiato
• quelli che permettono di nascondere determinati processi
• quelli che permettono di nascondere determinati file
• quelli che permettono di nascondere alcune attività dell'utente

Come si può intuire le ultime tre tipologie hanno tra le loro finalità quelle di rimuovere o celare le digital evidence dal sistema.

Kernel rootkit

I kernel rootkit lavorano ad un livello più basso di quelli appena visti, ed assumono generalmente la forma di moduli di sistema la cui funzione principale è sostituire le chiamate di sistema originali con versioni modificate. Queste potrebbero avere i seguenti scopi:

• nascondere la presenza dell'attaccante in modo più efficace ed elusivo rispetto agli user land rootkit
• compromettere il corretto funzionamento del kernel, rendendolo di fatto imprevedibile e inaffidabile
• rendere inaffidabili tutti i comandi impartiti al sistema, dato che la loro esecuzione si baserà su informazioni errate impartite dal kernel

Esistono diverse varianti di questi rootkit, compatibili con molti dei sistemi operativi Unix-like: Linux, OpenBSD, FreeBSD, Solaris.

Library rootkit

Un terzo tipo di rootkit è quello che lavora a livello di librerie di sistema, sostituendo quelle che vengono normalmente usate dal kernel per inviare informazioni ai moduli superiori (in particolare allo spazio utente). Le librerie alterate hanno come fine quello di filtrare tutti quei dati e quelle informazioni che l'attaccante non vuole far arrivare a certi processi, nascondendo in questo modo la sua presenza. Comandi come ps (lista statica dei processi in esecuzione) e top (lista dinamica dei processi in esecuzione) non restituirebbero dunque alcun indizio di compromissione.

Per questo tipo di rootkit esistono poi delle varianti che li rendono ancora più difficili da scovare. Ad esempio alcuni di essi non sostituiscono l'intera libreria ma solo poche specifiche funzioni, così che modificando la configurazione del loro loader possano essere caricate al posto di quelle originali. Una tecnica implementativa su sistemi Linux è inserire il nome di una di queste librerie sostitutive in /etc/ld.so.preload, una cartella particolare dato che tutte le librerie ivi contenute hanno la precedenza su quelle standard.

Windows rootkit

Gli user-land rootkit che girano sotto Windows non agiscono sostituendo i binari bensì le API, i driver e le DLL, così che qualsiasi programma le usi venga a sua volta compromesso. Le tecniche di mascheramento rimangono invece più o meno le stesse, quindi modifica delle chiavi di registro e di altre informazioni su file e processi.

Alcuni esempi noti di rootkit nei sistemi Win32 sono Nt Rootkit, FU Rootkit, AFX e Shadow Walker.

Rilevazione

Le tecniche con cui vengono rilevati i rootkit nel sistema dipende dalla loro tipologia. Quando ad esempio abbiamo a che fare con gli user land rootkit un metodo potrebbe essere l'utilizzo di firme per il riconoscimento di eventuali binari alterati, operazione eseguibile con una semplice scansione del file system. Proprio per questa facilità di rilevamento questi rootkit sono considerati di basso livello, quindi avere il sistema compromesso da uno di essi è indice di una preparazione all'incident management inadeguata.
Quando invece si ha a che fare con rootkit avanzati (a livello di kernel, libreria o entrambi) bisogna effettuare controlli più specifici, scansionando ad esempio la RAM e controllando il flusso informativo. Tecniche più recenti si basano sul controllo del flusso esecutivo, ovvero si controlla il funzionamento del programma a livello di istruzioni eseguite e se si riscontrano comportamenti anomali li si considera indice di eventuale presenza di un rootkit.

Concludiamo il paragrafo con una considerazione sulla time based security, composta da tre fattori: protection time (PT), detection time (DT) e reaction time (RT). Quando si pianifica il sistema di sicurezza non bisogna porsi tanto l'obiettivo di impedire ogni possibile attacco (sarebbe impossibile), ma di far perdere all'intruder il maggior tempo possibile così da avere più tempo per la detection. La regola aurea in questi casi è che: il PT deve sempre essere maggiore o uguale alla somma di DT e RT, ovvero bisogna far perdere all'attacker abbastanza tempo per bloccarlo.

---

Torna alla pagina di Gestione degli incidenti informatici