Rootkit

Da Wikipedia, l'enciclopedia libera.

Il rootkit è una collezione di software, tipicamente malevoli, realizzati per ottenere l’accesso ad un computer o ad una parte di esso, che non sarebbe altrimenti possibile (per esempio un utente non autorizzato ad effettuare il login). Questi software, oltre a garantire questi accessi, si preoccupano di mascherare sé stessi o altri programmi utili per raggiungere lo scopo. Il termine inglese “Rootkit” deriva dalla concatenazione di due termini “root” (che indica, tradizionalmente, l’utente con i maggiori permessi nei sistemi Unix-like) e “kit” (che si riferisce al software che implementa lo strumento). Il termine rootkit generalmente assume una connotazione negativa, perché spesso associato ad un Malware[1].

L’installazione di un Rootkit può essere automatizzata oppure un attaccante (cracker) può installarla personalmente, una volta ottenuti i permessi di root o l’accesso come Amministratore. Ottenere questo tipo di accesso può essere il risultato di un attacco diretto verso il sistema sfruttando, per esempio, una vulnerabilità nota (come Privilege Escalation) o scoprendo una password(ottenuta tramite Cracking o Ingegneria Sociale). Una volta installato il Rootkit, è importante mantenere nascosta l’intrusione così da poter mantenere i privilegi ottenuti. La chiave di questo attacco sta quindi nei permessi di root o Amministratore. Con questi permessi è possibile avere un controllo completo del sistema, questo include anche modificare software, compreso quello nato per rilevarli e bloccarli (come gli antivirus).

Rilevare un Rootkit può essere complicato, perché la prima preoccupazione di questi software è bloccare i programmi che possono trovarli. I metodi per rilevare rootkit includono l’utilizzo di un sistema operativo alternativo e fidato, metodi di analisi comportamentale (behavioral-based methods), signature scanning, analisi dei dump della memoria (memory dump). La rimozione può essere davvero complicata se non quasi impossibile, specialmente nei casi in cui il rootkit risiede nel kernel; formattare la macchina e reinstallare il sistema operativo potrebbe essere l’unica soluzione possibile[2]. Quando però si ha a che fare con dei rootkit nel firmware, la rimozione potrebbe richiedere la sostituzione di parti hardware, oppure l’utilizzo di strumenti specializzati.

Storia[modifica | modifica wikitesto]

Il termine rootkit o root kit originariamente si riferiva ad un insieme di software di amministrazione, per sistemi operativi Unix-like modificati a scopo malevolo, per ottenere i privilegi da utente “root[3]. Se un intruso è in grado di rimpiazzare i tool di amministrazione standard di un sistema con un rootkit, allora può ottenere non solo l’accesso come utente “root”, ma allo stesso tempo può nascondere le sue attività al vero amministratore di sistema.

Questa prima tipologia di rootkit erano facili da rilevare tramite l’utilizzo di strumenti come Tripwire che non erano stati compromessi, per accedere alle stesse informazioni[4][5]. Lane Davis e Steven Dake hanno scritto il primo rootkit conosciuto, nel 1990, per i sistemi SunOs UNIX della Sun Microsystem[6]. Nel 1983, nella conferenza tenutasi dopo aver ricevuto il premio Turing, Ken Thompson dei Laboratori Bell, uno dei creatori di Unix, ha teorizzato un compilatore C alterato, nelle distribuzioni Unix, e ha discusso l’exploit. Il compilatore modificato avrebbe rilevato i tentativi di compilare i comandi Unix di login e generato, di conseguenza, del codice alterato che avrebbe accettato non solo la password corretta dell’utente, ma una password addizionale di “backdoor”, conosciuta solo dall’attaccante. Inoltre il compilatore alterato avrebbe rilevato tentativi di compilare una nuova versione del compilatore stesso, inserendo così lo stesso exploit in quello nuovo. Una revisione del codice sorgente del comando di login o l’aggiornamento del compilatore non avrebbe rilevano nessun codice malevolo[7]. Questo exploit era l’equivalente di un rootkit.

Il primo virus, che attaccava personal computer, documentato, risale al 1986 ed utilizzava una tecnica di occultamento per nascondersi: il virus Brain intercettava i tentativi di leggere il settore di avvio e li reindirizzava ad altre parti dell’hard disk, dove era mantenuta una copia del boot originale[1]. Con il passare del tempo i metodi di occultamento dei virus DOS divennero più sofisticati, con tecniche avanzate che includevano l’aggancio(hooking) di chiamate interrupt INT 13H di basso livello del BIOS, per nascondere modifiche non autorizzare ai file[1].

Il primo rootkit malevolo per Windows NT [8]è apparso nel 1999: un trojan chiamato NTRootkit creato da Greg Hoglund. Il caso é stato seguito da HackerDefender nel 2003. Il primo rootkit a bersagliare un sistema Mac OS X è apparso nel 2009[9], mentre il worm Stuxnet è stato il primo a colpire un PLC[10].

Lo scandalo rootkit sulla protezione copie della Sony BMG[modifica | modifica wikitesto]

Articolo principale: Sony BMG copy protection rootkit scandal

Nel 2005, Sony BMG ha pubblicato dei CD con dei software per la protezione contro la copia e di gestione dei diritti digitali chiamato Extended Copy Protection, creato dalla società di software First 4 Internet. Il software includeva un lettore musicale il quale di nascosto installava un rootkit che limitava la capacita dell’utente di accedere al disco[11].

L’ingegnere informatico Mark Russinovich, il quale aveva creato un tool di rilevamento rootkit chiamato RootkitRevealer, ha scoperto il problema in uno dei suoi computer[1]. Lo scandalo che ne è derivato, ha aumentato la consapevolezza del pubblico riguardo ai Rootkit[12].

Per occultarsi, il rootkit si nascondeva in ogni file  che iniziava con “$sys$”. Appena dopo la segnalazione di Russinovich, sono apparsi diversi malware che sfruttavano questa vulnerabilità che affliggeva i sistemi interessati.

Un’analista della BBC lo ha chiamato “public relations nightmare”[13] (incubo delle pubbliche relazioni). Sony BGM ha rilasciato delle patch per cancellare il rootkit, ma queste hanno esposto gli utenti ad una vulnerabilità ancora più seria[14]. La società infine si è vista costretta a ritirare i CD. Negli USA è stata intentata una class-action contro Sony BGM[15].

Lo scandalo delle intercettazione greche nel 2004-05[modifica | modifica wikitesto]

Articolo principale: Greek wiretapping case 2004–05

Il caso delle intercettazioni greche nel 2004-05, anche noto come Greek Watergate[16], riguardava le intercettazioni illegali di oltre 100 telefoni cellulare della rete Vodafone greca, questi telefoni appartenevano per lo più a membri del governo e funzionari pubblici di alto livello. Le intercettazioni cominciarono circa ad Agosto 2004 e andarono avanti fino a Marzo 2005, senza che l’identità dei colpevoli venisse mai scoperta. Gli intrusi installarono un rootkit che aveva come bersaglio l’AXE telephone exchange della Ericsson[17]. In accordo con la IEEE Spectrum, questo è stato il primo attacco rootkit mai osservato su un sistema special-pourpose, in questo caso la centrale telefonica Ericsson. Il rootkit è stato progettato per modificare la memoria di scambio, mentre stava operando, abilitando così le intercettazioni, mentre disabilitava i registri di controllo, modificava inoltre i comandi che elencavano i processi e i blocchi di dati attivi e interveniva sul comando di verifica del blocco dati di checksum. Una backdoor consentiva ad un operatore, con i permessi da amministratore di sistema, di disattivare il log delle transazioni della centrale, gli allarmi e i comandi di accesso relativi alla sorveglianza[17]. Il rootkit venne scoperto in seguito ad un aggiornamento errato che causava la mancata consegna degli SMS, il quale generava un rapporto di errore automatico. Gli ingegneri della Ericsson furono chiamati ad investigare sul problema, e scoprirono così dei blocchi di dati nascosti contenenti le liste dei numeri di telefono da sorvegliare, insieme al rootkit e al software di monitoraggio illecito.

Utilizzi[modifica | modifica wikitesto]

I rootkit moderni non si preoccupano più di elevare i permessi[3], ma piuttosto mascherano il caricamento di un altro software aggiungendo funzioni per renderlo invisibile[8]. La maggior parte dei rootkit sono classificati come malware, perché sono legati a software malevolo. Per esempio il carico (payload) che si porta dietro un rootkit potrebbe segretamente rubare le password dell’utente, informazioni sulle carte di credito, risorse dal computer oppure potrebbe svolgere attività non autorizzate. Un numero ridotto di rootkit può essere utile all’utente: per esempio, potrebbe mascherare un driver di emulazione dei CD-ROM, permettendo di superare le misure anti-pirateriadi un videogioco che richiedono, ad esempio, di inserire il CD nell’apposito lettore per verificare l’autenticità del programma (questa misura di protezione potrebbe risultare fastidiosa anche a chi ha legalmente comprato il software).

I rootkit con il loro payload, possono avere diversi utilizzi:

  • Forniscono all’attaccante un accesso non autorizzato e completo tramite backdoor, con lo scopo, per esempio, di rubare o falsificare documenti. Uno dei posibili metodi per raggiungere tale scopo è quello di alterare il meccanismo di login, che per i sistemi UNIX-like può essere il programma /bin/login oppure GINA per i sistemi Windows. Il sostituto sembra funzionare normalmente, ma accetta anche una combinazione di login (username e password) segreta che permette all’attaccante un accesso diretto al sistema con privilegi di amministratore, bypassando così l’autenticazione standard e i meccanismi di autorizzazione.
  • Nascondere altri malware, in particolar modo i keyloggers in grado di rubare password e i virus informatici[18].
  • Si appropriano della macchina compromessa rendendola un computer zombie e poterna cosi sfruttare per attacchi ad altri computer (l’attacco parte dal computer zombie invece che direttamente dal computer dell’attaccante, rendendo cosi molto difficile, se non impossibile, rintracciarloe l'autore. I computer “zombie” fanno tipicamente parte di una vasta botnet che può lanciare attacchi di tipo DDoS (Distributed Denial of Service), spam di mail distribuito, click fraud, etc.
  • Forzatura dei DRM (Digital Rights Management)

In alcuni casi i rootkit forniscono funzionalità desiderate, e possono essere installati intenzionalmente dall’utente sul proprio computer:

  • Programmi di occultamento dei cheats nei giochi online, per evitare software come Warden[19].
  • Scovare attacchi, per esempio, con un honeypot[20].
  • Software di emulazione avanzata e di sicurezza[21]. Alcohol 120% e Daemon Tools sono esempi di rootkit commerciali non ostili usati per superare i sistemi di protezione dalla copia come SafeDisc o SecuROM. Anche il software antivirus Kaspersky usa tecniche che lo fanno assomigliare ad un rootkit per proteggere sè stesso da azioni malevole. Infatti lui carica dei suoi drivers per intercettare le attività di sistema ed impedire che queste vadano a danneggiarlo. I suoi processi non sono nascosti ma non possono essere terminati con metodi standard (Può essere terminato tramite Process Hacker)
  • Protezione antifurto: I portatili possono avere un software rootkit a livello di BIOS che periodicamente riferiscono ad una autorità centrale, permettendo così di monitorare, cancellare o rendere inaccessibili le informazioni sulla macchina in caso di furto[22].
  • Bypassare il Microsoft Product Activation[23]

Tipologie[modifica | modifica wikitesto]

Computer security rings (l'anello -1 non è mostrato)

Esistono almeno 5 tipi di rootkit, che vanno da quelli a livello più basso nel firmware (con i privilegi più alti), fino a quello con i privilegi minori, cioè a livello utente, che operano nell’anello 3. Esistono combinazioni ibride che possono combinare, per esempio, la modalità utente e la modalità kernel[24].

Modalità Utente[modifica | modifica wikitesto]

I rootkit in modalità utente  lavorano nell’anello 3, insieme alle altre applicazioni dell’utente, piuttosto che a livello più basso con i processi di sistema[25]. Hanno diversi possibili vettori di installazione per intercettare e modificare il comportamento standard delle application programing interfaces (APIs). Alcuni iniettano delle dynamically linked library (come ad esempio dei file .DLL su windows, o dei file .dylib nei sistemi Mac OS X) negli altri processi, e da qui sono in grado di eseguire all’interno di ogni processo bersaglio, nascondendo queste librerie; altri, se i loro permessi sono sufficienti, semplicemente sovrascrivono la memoria dell’applicazione bersaglio. I meccanismi di injection includono:

  • L’utilizzo di estensioni dell’applicaizioni, fornite dal produttore stesso. Per esempio, Windows Explorer ha delle interfacce pubbliche che permettono a terze parti di estenderne le funzionalità
  • Intercettazione di messaggi
  • Debuggers
  • Sfruttamento di vulnerabilità di sicurezza
  • Hooking delle funzioni o patch delle API usate più comunemente, ad esempio, per nascondere un processo in esecuzione o un file all'interno del file system[26].

…fino a quando le applicazioni in modalità utente eseguiranno solo nel loro spazio riservato, il rootkit avrà bisogno di modificare lo spazio di memoria di ogni singola applicazione. Inoltre, il rootkit ha bisogno di monitorare il sistema per  scoprire ogni nuova applicazione che esegue e modificare anche la sua memoria, solo così potrà eseguire in maniera ottimale.

—Window Rootkit Overview, Symantec

Modalità Kernel[modifica | modifica wikitesto]

I rootkit in modalità kernel (kernel-mode) lavorano con i privilegi più alti nel sistema operativo (anello 0), avendo così la possibilità di aggiungere codice o rimpiazzare porzioni fondamentali del sistema operativo, che comprendono sia il kernel, sia i driver dei dispositivi associati. La maggior parte dei sistemi operativi consentono ai driver dei dispositivi di operare in modalità kernel, quindi di lavorare con gli stessi privilegi del sistema operativo stesso. Per questa ragione molti rookit in kernel-mode sono sviluppati come driver per dispositivi o moduli caricabili, come quelli per il kernel (loadable kernel modules) su sistemi Linux o driver per dispositivi su sistemi Windows. Questa classe di rootkit ha un accesso completo senza restrizioni di sicurezza, ma sono molto più difficili da sviluppare[27]. La loro elevata complessità rende i bug abbastanza comuni ed un qualunque bug a livello kernel può avere un pesante impatto sulla stabilità del sistema, portando così alla scoperta del rootkit[27]. Uno dei più noti rootkit a livello kernel è stato sviluppato per Windows NT 4.0 e pubblicato sulla rivista Phrack da Greg Hoglund nel 1999[28][29][30].

I rootkit di questo tipo possono essere particolarmente ostici da trovare e rimuovere in quanto operano allo stesso livello di sicurezza del sistema operativo e sono quindi in grado di intercettare e sovvertire anche operazioni trusted (fidate) del sistema operativo. Qualunque software, come ad esempio un antivirus, che opera su un sistema compromesso è anch'esso vulnerabile[31]. In una situazione di questo tipo, nessun componente del sistema operativo può essere ritenuta affidabile.

Un rootkit può modificare strutture dati nel kernel di Windows usando un metodo conosciuto come DKOM (direct kernel object manipulation)[32]. Questo sistema può essere usato per nascondere processi. Un rootkit in kernel mode può poi agganciare la System Service Descriptor Table (SSDT), o modificare le “porte” per passare da user-mode a kernel-mode per nascondersi[3]. In modo del tutto analogo nei sistemi Linux, un rootkit può modificare la system call table per intervenire sulle funzionalità del kernel[33]. Non è raro che un rootkit crei un file system nascosto e criptato nel quale nascondere altri malware o le copie originali dei file infettati[34].

I sistemi operativi si stanno evolvendo per far fronte alla minaccia dei rootkit in modalità kernel. Per esempio, le versioni 64bit di Microsoft Windows ora implementano una firma obbligatoria per tutti i drivers che operano sullo stesso livello del kernel, in modo da rendere molto più difficile, per il codice non verificato, eseguire con privilegi così alti[35].

Bootkits[modifica | modifica wikitesto]

Una variante del rootkit in kernel-mode è il bootkit, il quale può infettare il codice di avvio, come il Master boot record (MBR) , Volume Boot Record(VBR) oppure il settore di boot ed in questo modo può essere usato per attaccare sistemi full disk encryption, ovvero sistemi con hard disk completamente criptati. Un esempio è l’ “Evil Maid Attack”, nel quale l’attaccante installa il bootkit su un pc incustodito e rimpiazza il boot loader originale con un altro sotto al suo controllo. Tipicamente il loader del malware sopravvive al passaggio attraverso il protected mode, quando il kernel è già stato caricato ed è quindi in grado di scavalcare questa protezione[36][37][38][39]. Per esempio lo “Stoned Bootkit” riesce a sovvertire il sistema utilizzando un boot loader compromesso in grado di intercettare le chiavi di cifratura e le password[40]. Più recentemente l’Alureon rootkit è riuscito a superare con successo la protezione su Windows 7, basata sulla firma dei driver, per evitare rootkit in kernel-mode nelle architetture a 64bit. Questo risultato è stato ottenuto mediante la modifica del master boot record[41]. Altri malware, anche se non intesi come qualcosa che compie azioni indesiderate dall’utente, possono essere alcuni “Vista Loader” o “Windows Loader” che lavorano in maniera molto simile, iniettando  una tabella ACPI SLIC (System Licensed Internal Code) nella versione caricata in RAM del BIOS durante il boot, in modo tale da scavalcare il processo di attivazione di Windows Vista e Windows 7[42][43]. Questo vettore di attacco è stato reso inutile nelle versioni (non server) di Windows 8, il quale usa una chiave unica, specifica per ogni macchina, in ogni sistema. La chiave può essere utilizzata solo sulla macchina a cui appartiene[44].

L’unica difesa nota contro i bootkit è la prevenzione contro gli accessi fisici alla macchina non autorizzati, un problema per i dispositivi portatili, oppure l’utilizzo di un Trusted Platform Module configurato per proteggere i file di avvio[45].

Hypervisor Level[modifica | modifica wikitesto]

I rootkit sono stati creati come Type II Hypervisors, in ambito accademico, come proof of concept (prova del concetto). Sfruttando le funzionalità di virtualizzazione, come Intel VT o AMD-V , questo tipo di rootkit opera nell’Anello-1 e ospita il sistema operativo di destinazione come una macchina virtuale, in tal modo autorizzano il rootkit ad intercettare le chiamate di sistema fatte dal sistema operativo originale[5]. Diversamente  dai normali Hypervisors, loro non devono essere caricati prima del sistema operativo. Un Hypervisor Rootkit non ha bisogno di effettuare alcuna modifica al kernel del bersaglio per attaccarlo; questo però non significa che non possa essere scoperto  dal sistema operativo ospite[5]. Per esempio le differenze nelle tempistiche possono essere scoperte da istruzioni della CPU[5]. Il rootkit “SubVirt” sviluppato in laboratorio congiuntamente da Microsoft e dai ricercatori della Università del Michigan, è un esempio accademico di rootkit basato su macchina virtuale (VMBR- Virtual Machine Based Rootkit)[46], mentre Blue Pill ne è un altro esempio.

Nel 2009, i ricercatori di Microsoft e della North Carolina State University hanno mostrato il funzionamento di un hypervisor-layer anti-rootkit chiamato Hooksafe, che fornisce una protezione generica contro i rootkit in modalità kernel[47].

Windows 10 introduce una nuova feature chiamata “Device Guard”, la quale sfrutta la virtualizzazione per fornire una protezione esterna indipendente al sistema operativo contro malware di tipo rootkit[48].

Firmware and hardware[modifica | modifica wikitesto]

Un firmware rootkit utilizza il firmware del dispositivo o della piattaforma per creare un’immagine persistente del malware in un dispositivo hardware, come ad esempio in un router, una scheda di rete[49], un disco rigido o il BIOS del sistema[25][50]. Il rootkit si nasconde nel firmware, in quanto spesso non ne viene controllata l’integrità del codice. John Heasman ha dimostrato la fattibilità dei firmware rootkit sia nelle routine del firmware ACPI [51]sia nelle schede di espansione PCI della ROM[52].

Nell’Ottobre del 2008, dei criminali hanno manomesso dei lettori di carte di credito Europee, prima che fossero installate. I dispositivi intercettavano e trasmettevano i dati delle carte attraverso una rete di telefonia mobile[53]. Nel Marzo 2009, i ricercatori  Alfredo Ortega e Anibal Sacco hanno pubblicato i dettagli di un rootkit a livello BIOS per sistemi Windows, in grado di resistere alla sostituzione dell’hard disk o alla reinstallazione del sistema operativo[54][55][56]. Alcuni mesi dopo hanno scoperto che alcuni portatili erano venduti con un rootkit legittimo, conosciuto come Absolute CompuTrace o Absolute LoJack for Laptops, preinstallato in molti BIOS. Questo rootkit è un sistema anti-furto, ma i ricercatori hanno dimostrato che può essere facilmente utilizzato per scopi malevoli.

Intel Active Management Technology, parte di Intel vPro, implementa un’ out-of-band management, il quale fornisce agli amministratori una amministrazione remota, una gestione remota e controllo remoto dei pc, senza alcun coinvolgimento del processore del sistema ospite o del BIOS, anche quando il sistema è spento. L’amministrazione remota include uno spegnimento o una accensione remota, reset, ridirezione del boot, ridirezione della console, accesso pre-boot alle impostazioni del BIOS, filtri configurabili per il traffico di rete in uscita e in ingresso, controllo della presenza, avvisi out-of-band basati su delle policy, accesso alle informazioni del sistema come ad esempio la configurazione hardware, log degli eventi persistente e altre informazioni che sono conservate in una memoria dedicata (non sull’hard disk), accessibile anche a pc spento o se il sistema operativo non è avviato. Alcune di queste funzioni richiedono un rootkit del livello più profondo e un secondo computer spia non removibile è costruito attorno al pc principale. Sandy Bridge e i chipset futuri hanno "l’abilità di uccidere e ripristinare da remoto un PC, perso o rubato, utilizzando il 3G”. I rootkit hardware impiantati nel chipset possono aiutare nel recupero di PC rubati, rimuovere dati o renderli inutili, ma rappresentano anche un problema di privacy e sicurezza, in quanto si trattano a tutti gli effetti di spie irrintracciabili e un hacker potrebbe ottenere il controllo della macchina da remoto.

Installazione e occultamento[modifica | modifica wikitesto]

I rootkit impiegano varie tecniche per prendere il controllo di un sistema; il tipo di rootkit va ad influire sulla scelta del vettore di attacco. La tecnica più comune è quella di fare leva su una vulnerabilità di sicurezza per ottenere un aumento dei privilegi non desiderato. Un altro approccio è quello che utilizza un cavallo di troia (trojan), ingannando l’utente di un computer facendogli credere che l’installazione del rootkit è in realtà un’installazione benigna[27] — in questo caso è la social engineering a convincere l’utente che l’installazione è benefica. Il compito di installazione è ancora più semplice se il principio del privilegio minimo non viene applicato, poiché in questo caso il rootkit non deve richiedere esplicitamente dei permessi elevati (livello amministratore). Altre classi di rootkit posso essere installati solamente da qualcuno con accesso fisico al sistema bersaglio. Alcuni rootkit possono anche essere installati intenzionalmente dal proprietario del sistema o da qualcun’altro autorizzato dal proprietario, con lo scopo, ad esempio, di monitorare gli impiegati, rendendo le tecniche sovversive inutili[57].

L’installazione di rootkit malevoli è commercialmente guidata, con un metodo di compensazione pay-per-installtipico per la distribuzione[58][59].

Una volta installato un rootkit prende misure attive per oscurare la sua presenza all’interno del sistema ospite attraverso la sovversione o l’evasione degli strumenti standard di sicurezza del sistema e delle API usate per la diagnosi, scansione e monitoraggio. I rootkit ottengono questo con la modifica del comportamento delle parti fondamentali di un sistema operativo attraverso il caricamento di codice nei processi, l’installazione o la modifica di drivers o moduli kernel. Le tecniche di offuscamento includono il nascondere i processi in esecuzione ai meccanismi di monitoraggio del sistema e nascondere i file di sistema e altri dati di configurazione[60]. Non è raro per un rootkit disabilitare la capacità di event logging di un sistema operativo, nel tentativo di nascondere le prove di un attacco. I Rootkit possono, in teoria, sovvertire ogni attività del sistema operativo[61]. Il “rootkit perfetto” può essere pensato come il “crimine perfetto”: quello che nessuno si rende conto che ha avuto luogo.

I rootkit inoltre prendono una serie di misure, oltre alla installazione nel Ring 0 (kernel-mode), per assicurarsi la loro sopravvivenza contro il rilevamento e la pulizia da parte di software antivirus. Questo include il polimorfismo, tecniche di occultamento, rigenerazione, blocco di software anti-malware[62] e la non installazione su macchine virtuali, nelle quali sono più facili da scoprire e analizzare per i ricercatori.

Rivelazione[modifica | modifica wikitesto]

Il problema fondamentale nella scoperta dei rootkit è che il sistema operativo stesso viene compromesso, specialmente dai rootkit a livello kernel, esso quindi non è attendibile per quanto riguarda la ricerca di modifiche non autorizzate a se stesso o ai suoi componenti[61]. Azioni come richiedere una lista di processi in esecuzione, o una lista di file nelle directory, non sono affidabili, le risposte potrebbero non essere quelle previste. In altre parole, i programmi che identificano rootkit che lavorano mentre il sistema infetto è in esecuzione, sono efficaci solo  contro i rootkit che hanno qualche difetto nel loro occultamento, o che operano con privilegi più bassi rispetto al programma incaricato di scoprirli. Come con i virus, la scoperta e l'eliminazione dei rootkit è una lotta costante tra le due parti[61].

La identificazione può utilizzare diversi approcci differenti, incluse firme (es. Software Antivirus), check di integrità (es. firme digitali), rilevamento basato su differenze (es. risultato del confronto atteso vs risultati effettivi) e rilevamento comportamentale (es. monitoraggio dell’utilizzo della CPU o del traffico di rete). Per i rootkit in kernel mode, la scoperta è da considerarsi più complessa, essa richiede infatti un’attenta analisi della System Call Table alla ricerca di hooked functiondove il malware potrebbe compromettere il comportamento del sistema[63] oppure l’analisi della memoria alla ricerca di pattern che indicano processi nascosti.

I software per il rilevamento dei rootkit su sistemi Unix includono Zeppo[64], chrootkit, rkhunter, e OSSEC. Su ambiente Windows, i software di questo tipo sono Microsoft Sysinternals, RootkitRevealer[65], Avast! Antivirus, Sophos Anti-Rootkit[66], F-Secure[67], Radix[68], GMER[69] e WindowsSCOPE. Ogni software di questo tipo, con la scoperta di nuovi malware, migliora la sua stessa efficacia, ma allo stesso modo gli autori dei malware adattano e testano il loro codice per evitare di essere scoperti dagli strumenti più noti.

La scoperta attraverso un esame della memoria, mentre il sistema operativo preso in esame non sta operando, può mancare i rootkit non conosciuti dal software utilizzato, in quanto neanche il rootkit sta operando e quindi non sono rilevati i comportamenti sospetti. I software anti-malware convenzionali, che operano insieme al rootkit, potrebbero fallire se il rootkit si nasconde in modo efficace.

Alternative trusted medium[modifica | modifica wikitesto]

Il metodo migliore e più affidabile per la scoperta dei rootkit che operano a livello del sistema operativo è quello di spegnere il computer sospetto e fare un check della sua memoria di archiviazione attraverso l’avvio di un alternative trusted medium (es. un CD di recupero, una chiave USB)[70]. La tecnica è efficace perché il rootkit non può nascondere in maniera attiva la sua presenza, dato che non è in esecuzione.

Behavioral-based[modifica | modifica wikitesto]

L’approccio behavioral based per scovare i rootkit tenta di dedurre la presenza di un rootkit, cercando un comportamento rootkit-like. Per esempio può profilare il sistema alla ricerca di differenze nelle tempistiche e nella frequenza della chiamate API, oppure può analizzare l’utilizzo generale della CPU. Questo metodo è complesso e si ha un’alta incidenza di falsi positivi. Rootkit difettosi possono generare cambiamenti molto evidenti per un sistema: il rootkit Alureon blocca i sistemi Windows dopo che un aggiornamento di sicurezza ha portato alla luce un errore di progettazione nel suo codice[71][72].

I log di un packet analyzer, di un firewall, o di un sistema di prevenzione delle intrusioni possono evidenziare la presenza di un rootkit in ambiente di rete.

Signature-based[modifica | modifica wikitesto]

Gli antivirus raramente trovano tutti i virus nei test pubblici (a seconda di ciò che viene utilizzato e in quale misura), anche se i produttori di questi software incorporano dei rootkit detector nei loro prodotti. Se un rootkit prova a nascondersi durante una scansione antivirus, lo stealth detector potrebbe accorgersene; se il rootkit prova a rimuoversi temporaneamente dal sistema, il signature detector (o “impronta digitale”) può ancora trovarlo. Questo approccio combinato obbliga l’attaccante a implementare dei meccanismi di contrattacco, o “retro” routine che tentano di interrompere i programmi antivirus. I metodi di rivelazione signature-based possono essere efficaci con rootkit ben noti, ma lo sono molto meno con rootkit creati apposta per una specifica vittima, i custom-root rootkit[61].

Difference-based[modifica | modifica wikitesto]

Un altro metodo in grado di scoprire rootkit compara dei dati grezzi “fidati” con il contenuto “contaminato” restituito da una API. Per esempio, i file binari presenti nel disco possono essere confrontati con le loro copie all’interno della memoria operativa (in alcuni sistemi operativi, l’immagine in memoria dovrebbe essere identica alla versione su disco), altrimenti con il risultato restituito dal file system oppure dalle API del registro di sistema può essere controllato tramite le strutture grezze nei dischi fisici sottostanti[61][73] —però, nel primo caso, possono essere introdotte alcune importanti variazioni da parte di alcuni meccanismi del sistema operativo come il memory relocation o lo shimming. Un rootkit può scoprire la presenza di diversi difference-based scanner o machine virtuali (quest’ultimo viene comunemente usato per eseguire analisi forensi), e modificare il suo comportamento in modo tale che non venga rilevata alcuna differenza. La rilevazione Difference-based è stata usata da Russinovich per trovare il Sony DRM rootkit[1].

L'utility rkhunter utilizza l'algoritmo di hash SHA-1 per verificare l'integrità dei file di sistema

Integrity checking[modifica | modifica wikitesto]

La firma del codice utilizza la struttura della chiave pubblica per verificare se il file ha subito modifiche dopo essere stato firmato digitalmente dal produttore. In alternativa il proprietario o l’amministratore del sistema può usare una funzione crittografica di hash per calcolare l'“impronta digitale” al momento dell'installazione che può aiutare a scoprire successive modifiche non autorizzate alle librerie sul disco[74]. Però, i sistemi meno sofisticati controllano solo se il codice è stato modificato dopo il momento della installazione; eventuali modifiche prima di questo momento non vengono rilevate. L’impronta digitale dovrà essere ristabilita ogni volta che vengono apportate modifiche importanti al sistema: per esempio, dopo aver installato aggiornamenti di sicurezza o service pack. La funzione di hash crea un messaggio digest, ovvero un codice relativamente corto, calcolato a partire da ogni singolo bit nel file, utilizzando un algoritmo che genera grossi cambiamenti in conseguenza ad una modifica, anche minima, nel file originale. Ricalcolando e confrontando i messaggi digest del file installato ad intervalli regolari con un elenco di messaggi fidati, i cambiamenti nel sistema possono essere scoperti e monitorati —purchè la baseline originale sia stata creata prima dell’introduzione del malware. I rootkit più sofisticati sono in grado di compromettere il sistema di verifica presentando una copia non modificata del file durante l’ispezione, o attuando le modifiche al codice solo in memoria anziché su hard-disk. Questa tecnica quindi può essere efficace solo contro i rootkit poco sofisticati —per esempio, quelli che rimpiazzano i file binari di Unix, come “ls”, per nascondere la presenza di file.

In modo analogo, la scoperta nel firmware può essere ottenuta calcolando l’hash del firmware e comparandolo con una whitelist di valori attesi, oppure estendendo i valori di hash nel registro di configurazione del Trusted Platform Module (TPM) che vengono poi comparati, anche in questo caso, ad una whitelist di valori attesi[75]. Il codice che esegue l’hash, compara o estende le operazioni deve essere protetto —in questo contesto, la nozione di immutable root-of-trust sostiene che il primo codice per misurare le proprietà di sicurezza di un sistema, deve essere esso stesso attendibile per garantire che un rootkit o un bootkit non compromettano il sistema al suo livello più fondamentale[76].

Memory dump[modifica | modifica wikitesto]

Forzare un dump completo della memoria virtuale, o un dump del kernel (nel caso di un rootkit in kernel-mode) può catturare un rootkit attivo, permettendo così un’analisi forense attuata tramite un debugger applicato al file di dump, senza che il rootkit sia in grado di utilizzare alcuna misura per nascondersi. Questa tecnica è altamente specializzata, e può essere necessario l’accesso a codice sorgente non pubblico o debugging symbols. I dump della memoria avviati dal sistema operativo non sempre possono essere usati per scoprire un hypervisor-based rootkit, il quale è in grado di intercettare e compromettere i tentativi a livello più basso e di leggere la memoria —in uno scenario di questo tipo potrebbe essere necessario un dispositivo hardware, come ad esempio uno che implementa un non-maskable interrupt, per effettuare il dump della memoria[77][78]. Anche le macchine virtuali rendono più facile l’analisi della memoria di una macchina compromessa dal hypervisor sottostante, per questo motivo alcuni rootkit evitano di infettare macchine virtuali.

Rimozione[modifica | modifica wikitesto]

La rimozione manuale di un rootkit è spesso troppo complessa per un utente medio, ma molti software di sicurezza contengono tool specifici per la loro ricerca e rimozione, tipicamente questi tool fanno parte delle suite antivirus. A partire dal 2005, lo strumento Microsoft di rimozione malware per Windows è in grado di rilevare e rimuovere diversi tipi di rootkit[79][80]. Alcuni scanner antivirus possono bypassare le API del file system, le quali sono vulnerabili alla manipolazione da parte dei rootkit, e accedere direttamente alle strutture dati grezze del file system usando queste informazioni per validare i risultati delle API del sistema e individuare cosi eventuali differenze che possono essere indicative della presenza di un rootkit[81][82][83][84].

Ci sono esperti che credono che l’unica via affidabile per rimuovere un rootkit sia reinstallare il sistema operativo tramite un mezzo fidato(trusted)[85][86]. Questo perché gli antivirus e gli antimalware operano su un sistema non fidato e potrebbero quindi rivelarsi loro stessi inefficaci contro rootkit in kernel-mode ben scritti. Avviare un sistema operativo alternativo tramite un trusted media può consentire una pulizia sicura del sistema infetto e una copia dei dati critici —o, in alternativa, di eseguire un'analisi forense[24]. I sistemi operativi leggeri quali Windows PE, Windows Recovery Console, Windows Recovery Environment, BartPE o le Distro Live possono essere utilizzate per questo proposito, permettendo cosi una pulizia del sistema.

Anche se il tipo e la natura del rootkit sono noti, un intervento manuale potrebbe essere poco pratico, mentre reinstallare il sistema operativo e le applicazioni è più sicuro, semplice e veloce[85].

Disponibilità Pubblica[modifica | modifica wikitesto]

Come molti malware utilizzati dagli attaccanti, così anche molte implementazioni di rootkit sono condivise e facilmente reperibili in rete. Non è raro vedere un sistema compromesso nel quale un rootkit sofisticato e disponibile pubblicamente nasconde la presenza di un worm molto più semplice oppure tool di attacco apparentemente scritti da programmatori inesperti[24].

La maggior parte dei rootkit disponibili in rete sono nati come exploit o come “proof of concept" accademici per dimostrare la veridicità di metodi per nascondere qualcosa all'interno del sistema di un computer oppure per prendere il controllo di esso[87]. Spesso hanno sistemi per nascondersi non ottimizzati, talvolta infatti lasciano prove involontarie della loro presenza. Comunque, nonostante questo, quando sono utilizzati per un attacco, si rivelano comunque efficaci il più delle volte. Altri rootkit con feature di keylogging come GameGuard sono installati insieme a giochi online.

Difesa[modifica | modifica wikitesto]

Il system hardening rappresenta il primo strato di difesa contro i rootkit, impedendo direttamente l’installazione[88]. Applicare patch di sicurezza, applicare il principio del privilegio minimo, ridurre la superficie di attacco e installare software antivirus sono le migliori e più comuni pratiche di difesa contro tutti i tipo di malware[89].

Le nuove specifiche di avvio sicuro come Unified Estensibile Firmware Interface sono state progettate per affrontare la minaccia dei bootkit, ma anche queste si rivelano inefficaci se le caratteristiche di sicurezza che offrono non vengono utilizzate.

Per i sistemi server vengono utilizzate tecnologie come la Trusted Execution Technology (TXT) di Intel, la quale fornisce un sistema per validare questi server  che rimangono così in uno stato fidato. Per esempio, Microsoft Bitlocker cripta i data-at-rest convalidando i server  che sono in uno stato fidato all avvio.

PrivateCore Cage è un software che protegge i data-in-use (memoria), per evitare rootkit e bootkit, convalidando i server che si trovano in uno stato riconosciuto come “buono” all’ avvio.

Rootkit famosi[modifica | modifica wikitesto]

Tra i più noti si possono annoverare FU e NT Rootkit.

Un particolare tipo di rootkit è presente anche nel sistema operativo (versione 3.56 o superiori) della Playstation 3. Questo è stato introdotto da Sony con l'aggiornamento alla versione 3.56 del firmware e serve a prevenire l'accesso a PlayStation Network delle console modificate, con successivo ban dell'Indirizzo MAC della loro scheda di rete.

Note[modifica | modifica wikitesto]

  1. ^ a b c d e McAfee, Proven Security 2006, in https://web.archive.org/web/20060823090948/http://www.mcafee.com/us/local_content/white_papers/threat_center/wp_akapoor_rootkits1_en.pdf.
  2. ^ (EN) Rootkit Removal from a Windows System, su Technibble, 25 ottobre 2011. URL consultato l'8 giugno 2016.
  3. ^ a b c Symantec, Windows rootkit overview, http://www.symantec.com/avcenter/reference/windows.rootkit.overview.pdf.
  4. ^ Sparks, Sherri; Butler, Jamie (2005-08-01), Raising The Bar For Windows Rootkit Detection.
  5. ^ a b c d Myers, Michael; Youndt, Stephen (2007-08-07), An Introduction to Hardware-Assisted Virtual Machine (HVM) Rootkits.
  6. ^ (EN) Rory Bray, Daniel Cid e Andrew Hay, OSSEC Host-Based Intrusion Detection Guide, Syngress, 9 aprile 2008, ISBN 978-0-08-055877-6. URL consultato l'8 giugno 2016.
  7. ^ Thompson, Ken (August 1984), Reflections on Trusting Trust, in https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf.
  8. ^ a b (EN) Greg Hoglund e James Butler, Rootkits: Subverting the Windows Kernel, Addison-Wesley Professional, 1º gennaio 2006, ISBN 978-0-321-29431-9. URL consultato l'8 giugno 2016.
  9. ^ Advanced OSX Rootkits, in https://www.blackhat.com/presentations/bh-usa-09/DAIZOVI/BHUSA09-Daizovi-AdvOSXRootkits-SLIDES.pdf.
  10. ^ Stuxnet Introduces the First Known Rootkit for Industrial Control Systems, su Symantec Security Response. URL consultato l'8 giugno 2016.
  11. ^ XCP.Sony.Rootkit - CA Technologies, web.archive.org, 18 agosto 2010. URL consultato l'8 giugno 2016.
  12. ^ Sony, Rootkits and Digital Rights Management Gone Too Far, su Mark's Blog. URL consultato l'8 giugno 2016.
  13. ^ Sony's long-term rootkit CD woes, in BBC, 21 novembre 2005. URL consultato l'8 giugno 2016.
  14. ^ Sony's Web-Based Uninstaller Opens a Big Security Hole; Sony to Recall Discs, su freedom-to-tinker.com. URL consultato l'8 giugno 2016.
  15. ^ (EN) Will Knight, Sony BMG sued over cloaking software on music CD, su New Scientist. URL consultato l'8 giugno 2016.
  16. ^ Greek Watergate, in http://www.tiscali.co.uk/news/newswire.php/news/reuters/2006/02/03/odd/34greekwatergate34scandalsendspoliticalshockwaves.html.
  17. ^ a b The Athens Affair, su IEEE Spectrum: Technology, Engineering, and Science News. URL consultato l'8 giugno 2016.
  18. ^ Unearthing Root Kits, su www.windowsitpro.com. URL consultato l'8 giugno 2016.
  19. ^ Apple patches critical iTunes bug, World of Warcraft hackers using Sony BMG rootkit, theregister.co.uk. URL consultato l'8 giugno 2016.
  20. ^ Using Rootkit Technology for Honeypot-Based Malware Detection, in http://www.vividmachines.com/download/icsicceid.pdf.
  21. ^ Using Rootkits to Defeat Digital Rights Management, su Mark's Blog. URL consultato l'8 giugno 2016.
  22. ^ Deactivate the Rootkit: Attacks on BIOS anti-theft technologies, in http://www.blackhat.com/presentations/bh-usa-09/ORTEGA/BHUSA09-Ortega-DeactivateRootkit-PAPER.pdf.
  23. ^ Peter Kleissner, Peter Kleissner (PDF), su www.stoned-vienna.com. URL consultato l'8 giugno 2016.
  24. ^ a b c (EN) Steven Anson e Steve Bunting, Mastering Windows Network Forensics and Investigation, John Wiley & Sons, 2 aprile 2007, ISBN 978-0-470-09762-5. URL consultato l'8 giugno 2016.
  25. ^ a b Rootkits Part 2: A Technical Primer, in https://web.archive.org/web/20081205031526/http://www.mcafee.com/us/local_content/white_papers/wp_rootkits_0407.pdf.
  26. ^ .:: Phrack Magazine ::., su www.phrack.org. URL consultato l'8 giugno 2016.
  27. ^ a b c understanding anti-malware technologies, in http://download.microsoft.com/download/a/b/e/abefdf1c-96bd-40d6-a138-e320b6b25bd3/understandingantimalwaretechnologies.pdf.
  28. ^ .:: Phrack Magazine ::., su phrack.org. URL consultato l'8 giugno 2016.
  29. ^ Alisa Shevchenko, Rootkit Evolution, su Help Net Security, 1º settembre 2008. URL consultato l'8 giugno 2016.
  30. ^ An overview of Unix Rootkits, in http://www.megasecurity.org/papers/Rootkits.pdf.
  31. ^ Windows rootkits of 2005, part two | Symantec Connect, su www.symantec.com. URL consultato l'8 giugno 2016.
  32. ^ Windows rootkits of 2005, part one | Symantec Connect, su www.symantec.com. URL consultato l'8 giugno 2016.
  33. ^ Detecting Rootkits And Kernel-level Compromises In Linux | Symantec Connect, su www.symantec.com. URL consultato l'8 giugno 2016.
  34. ^ ZeroAccess – an advanced kernel mode rootkit, in http://pxnow.prevx.com/content/blog/zeroaccess_analysis.pdf.
  35. ^ Driver Signing Requirements for Windows - Windows 10 hardware dev, su www.microsoft.com. URL consultato l'8 giugno 2016.
  36. ^ Security Tools | eEye Digital Security, web.archive.org, 17 agosto 2013. URL consultato l'8 giugno 2016.
  37. ^ "Evil Maid" Attacks on Encrypted Hard Drives - Schneier on Security, su www.schneier.com. URL consultato l'8 giugno 2016.
  38. ^ VBootkit:Compromising Windows Vista security (PDF), blackhat.com.
  39. ^ BOOT KIT: Custom boot sector based Windows 2000/XP/2003 Subversion - NVlabs | Analyzing Security, web.archive.org, 10 giugno 2010. URL consultato l'8 giugno 2016.
  40. ^ Peter Kleissner, Peter Kleissner, su www.stoned-vienna.com. URL consultato l'8 giugno 2016.
  41. ^ Exploit Code, World's most advanced rootkit penetrates 64-bit Windows, theregister.co.uk. URL consultato l'8 giugno 2016.
  42. ^ (EN) Hacking at Random, in Wikipedia, the free encyclopedia, 18 settembre 2015. URL consultato l'8 giugno 2016.
  43. ^ Windows Loader. Get the software safe and easy., su Software Informer. URL consultato l'8 giugno 2016.
  44. ^ Android, Microsoft tightens grip on OEM Windows 8 licensing, theregister.co.uk. URL consultato l'8 giugno 2016.
  45. ^ (EN) Joel Scambray, Hacking Exposed Windows: Microsoft Windows Security Secrets and Solutions, Third Edition: Microsoft Windows Security Secrets and Solutions, Third Edition, McGraw Hill Professional, 25 dicembre 2007, ISBN 978-0-07-159669-5. URL consultato l'8 giugno 2016.
  46. ^ 2006 IEEE Symposium on Security and Privacy, computer.org.
  47. ^ Countering Kernel Rootkits with Lightweight Hook Protection, in http://research.microsoft.com/en-us/um/people/wdcui/papers/hooksafe-ccs09.pdf.
  48. ^ Device Guard overview (Windows 10), su msdn.microsoft.com. URL consultato l'8 giugno 2016.
  49. ^ Closer to metal: Reverse engineering the Broadcom NetExtreme’s firmware, in http://esec-lab.sogeti.com/dotclear/public/publications/10-hack.lu-nicreverse_slides.pdf.
  50. ^ (EN) Hacking Team Uses UEFI BIOS Rootkit to Keep RCS 9 Agent in Target Systems - TrendLabs Security Intelligence Blog, su TrendLabs Security Intelligence Blog, 13 luglio 2015. URL consultato l'8 giugno 2016.
  51. ^ Implementi and detecting an ACPI BIOS Rootkit (PDF), blackhat.com.
  52. ^ Implementing and Detecting a PCI Rootkit, in http://www.ngsconsulting.com/research/papers/Implementing_And_Detecting_A_PCI_Rootkit.pdf.
  53. ^ Ibm, Organized crime tampers with European card swipe devices, theregister.co.uk. URL consultato l'8 giugno 2016.
  54. ^ Persistent BIOS infection, in http://cansecwest.com/csw09/csw09-sacco-ortega.pdf.
  55. ^ Exploit Code, Newfangled rootkits survive hard disk wiping, theregister.co.uk. URL consultato l'8 giugno 2016.
  56. ^ .:: Phrack Magazine ::., su phrack.org. URL consultato l'8 giugno 2016.
  57. ^ John Wiley & Sons, Professional Rootkits, 2007, p. 244, ISBN 978-0-470-14954-6.
  58. ^ TDL3: The Rootkit of All Evil?, in http://www.eset.com/resources/white-papers/TDL3-Analysis.pdf.
  59. ^ IT Security Resources| News, Whitepapers & Videos | ESET | ESET (PDF), su www.eset.com. URL consultato l'8 giugno 2016.
  60. ^ USENIX | The Advanced Computing Systems Association, su www.usenix.org. URL consultato l'8 giugno 2016.
  61. ^ a b c d e Hacking Exposed Malware & Rootkits (Chapter10), in http://www.mhprofessional.com/downloads/products/0071591184/0071591184_chap10.pdf.
  62. ^ Trlokom Rootkit Defense White Paper, in http://www.trlokom.com/pdf/TrlokomRootkitDefenseWhitePaper.pdf.
  63. ^ SANS Institute InfoSec Reading Room. Kernel Rootkits, in https://web.archive.org/web/20120910164327/http://www.sans.org:80/reading_room/whitepapers/threats/kernel-rootkits_449.
  64. ^ zeppoo, su SourceForge. URL consultato l'8 giugno 2016.
  65. ^ RootkitRevealer, su technet.microsoft.com. URL consultato l'8 giugno 2016.
  66. ^ Anti-Rootkit Scanner | Free Rootkit Detection and Removal Tool | Sophos Virus Protection, su www.sophos.com. URL consultato l'8 giugno 2016.
  67. ^ F-Secure UK and Ireland | Switch on Freedom, su www.f-secure.com. URL consultato l'8 giugno 2016.
  68. ^ Radix, usec.at.
  69. ^ GMER - Rootkit Detector and Remover, su www.gmer.net. URL consultato l'8 giugno 2016.
  70. ^ testing_methodology_for_rootkit_removal, Testing methodology for rootkit removal, in http://www.symantec.com/avcenter/reference/testing_methodology_for_rootkit_removal.pdf.
  71. ^ Tidserv and MS10-015, su Symantec Security Response. URL consultato l'8 giugno 2016.
  72. ^ Restart issues after installing MS10-015, su MSRC. URL consultato l'8 giugno 2016.
  73. ^ Yi-Min Wang, The Strider GhostBuster Project, su research.microsoft.com. URL consultato l'8 giugno 2016.
  74. ^ Signing and Checking Code with Authenticode (Windows), su msdn.microsoft.com. URL consultato l'8 giugno 2016.
  75. ^ (EN) Stopping Rootkits at the Network Edge | Trusted Computing Group (PDF), su Trusted Computing Group, 1º giugno 2009. URL consultato l'8 giugno 2016.
  76. ^ TCG PC Specific Implementation Specification, Version 1.1, in http://www.trustedcomputinggroup.org/files/resource_files/87B92DAF-1D09-3519-AD80984BBE62D62D/TCG_PCSpecificSpecification_v1_1.pdf.
  77. ^ https://support.microsoft.com/en-us/kb/927069, su support.microsoft.com. URL consultato l'8 giugno 2016.
  78. ^ Seshadri, Arvind; et al, Pioneer: Verifying Code Integrity and Enforcing Untampered Code Execution on Legacy Systems, 2005.
  79. ^ (EN) Rootkit battle: Rootkit Revealer vs. Hacker Defender, su SearchEnterpriseDesktop. URL consultato l'8 giugno 2016.
  80. ^ https://support.microsoft.com/en-us/kb/890830, su support.microsoft.com. URL consultato l'8 giugno 2016.
  81. ^ Steve Hultquist, Rootkits: The next big enterprise threat?, su InfoWorld. URL consultato l'8 giugno 2016.
  82. ^ Security Watch: Rootkits for fun and profit - CNET Reviews, web.archive.org, 8 ottobre 2012. URL consultato l'8 giugno 2016.
  83. ^ Six ways to fight back against botnets, su PCWorld. URL consultato l'8 giugno 2016.
  84. ^ Handling Today's Tough Security Threats: Rootkits, su Symantec Security Response. URL consultato l'8 giugno 2016.
  85. ^ a b Rootkits: The Obscure Hacker Attack, su technet.microsoft.com. URL consultato l'8 giugno 2016.
  86. ^ Ellen Messmer, Experts divided over rootkit detection and removal, su Network World. URL consultato l'8 giugno 2016.
  87. ^ (EN) Larry Stevenson e Nancy Altholz, Rootkits For Dummies, John Wiley & Sons, 11 dicembre 2006, ISBN 978-0-470-10183-4. URL consultato l'8 giugno 2016.
  88. ^ (EN) Ed Skoudis, Malware: Fighting Malicious Code, Prentice Hall PTR, 1º gennaio 2004, ISBN 978-0-13-101405-3. URL consultato l'8 giugno 2016.
  89. ^ Linux RootKits For Beginners - From Prevention to Removal, in https://web.archive.org/web/20101024164136/http://www.sans.org:80/reading_room/whitepapers/linux/linux-rootkits-beginners-prevention-removal_901.

Voci correlate[modifica | modifica wikitesto]

Altri progetti[modifica | modifica wikitesto]

Collegamenti esterni[modifica | modifica wikitesto]

Controllo di autorità GND: (DE7518179-4