Rootkit: differenze tra le versioni

Versione delle 17:52, 14 giu 2016

Versione delle 16:55, 3 lug 2016

Riga 1:

Il '''rootkit''' è una collezione di [[software]], tipicamente [[Malware|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”"Rootkit" deriva dalla concatenazione di due termini “"[[Root (utente)|root]]”" (che indica, tradizionalmente, l’utentel'utente con i maggiori permessi nei sistemi [[Unix-like]]) e “kit”"kit" (che si riferisce al software che implementa lo strumento). Il termine rootkit generalmente assume una connotazione negativa, perché spesso associato ad un [[Malware]]<ref name=":0">{{Cita pubblicazione|autore=McAfee|titolo=Proven Security 2006|rivista=https://web.archive.org/web/20060823090948/http://www.mcafee.com/us/local_content/white_papers/threat_center/wp_akapoor_rootkits1_en.pdf}}</ref>.

L’installazione di un Rootkit può essere automatizzata oppure un attaccante ([[Cracker (informatica)|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|Privilege Escalation]]) o scoprendo una [[password]](ottenuta tramite [[Cracking (informatica)|Cracking]] o [[Ingegneria sociale|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).

Riga 6:

== Storia ==

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 (utente)|root]]”"<ref name=":1">{{Cita pubblicazione|autore=Symantec|titolo=Windows rootkit overview|volume=http://www.symantec.com/avcenter/reference/windows.rootkit.overview.pdf}}</ref>. 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”"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 [[:en:Open Source Tripwire|Tripwire]] che non erano stati compromessi, per accedere alle stesse informazioni<ref>{{Cita pubblicazione|autore=Sparks, Sherri; Butler, Jamie (2005-08-01)|titolo=Raising The Bar For Windows Rootkit Detection}}</ref><ref name=":5">{{Cita pubblicazione|autore=Myers, Michael; Youndt, Stephen (2007-08-07)|titolo=An Introduction to Hardware-Assisted Virtual Machine (HVM) Rootkits}}</ref>. Lane Davis e Steven Dake hanno scritto il primo rootkit conosciuto, nel 1990, per i sistemi SunOs UNIX della [[Sun Microsystems|Sun Microsystem]]<ref>{{Cita libro|nome=Rory|cognome=Bray|nome2=Daniel|cognome2=Cid|nome3=Andrew|cognome3=Hay|titolo=OSSEC Host-Based Intrusion Detection Guide|url=https://books.google.com/books?id=h37q2q3wvcUC|accesso=8 giugno 2016|data=9 aprile 2008|editore=Syngress|lingua=en|ISBN=978-0-08-055877-6}}</ref>. 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<ref>{{Cita pubblicazione|autore=Thompson, Ken (August 1984)|titolo=Reflections on Trusting Trust|rivista=https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf}}</ref>. Questo exploit era l’equivalente di un rootkit.

Riga 27:

== Utilizzi ==

I rootkit moderni non si preoccupano più di elevare i permessi<ref name=":1" />, ma piuttosto mascherano il caricamento di un altro software aggiungendo funzioni per renderlo invisibile<ref name=":2" />. 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 [[:en:Copy protection#Anti-piracy|anti-pirateria]]<nowiki/> di un [[videogioco]] che richiedono, ad esempio, di inserire il CD nell’appositonell'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 (malware)|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|UNIX-like]] può essere il programma /bin/login oppure [[:en:Graphical identification and authentication|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 [[keylogger]]s in grado di rubare password e i virus informatici<ref>{{Cita web|url=http://www.windowsitpro.com/Article/ArticleID/46266/46266.html|titolo=Unearthing Root Kits|sito=www.windowsitpro.com|accesso=8 giugno 2016}}</ref>.

* Si appropriano della macchina compromessa rendendola un [[computer zombie]] <nowiki/>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]] <nowiki/>che può lanciare attacchi di tipo DDoS ([[Denial of Service|Distributed Denial of Service]]), [[spam]] di [[Posta elettronica|mail]] distribuito, [[:en:Click fraud|click fraud]], etcecc.

* Forzatura dei [[Digital rights management|DRM]] (Digital Rights Management)

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

Riga 46:

=== Modalità Utente ===

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<ref name=":6">{{Cita pubblicazione|autore=|titolo=Rootkits Part 2: A Technical Primer|rivista=https://web.archive.org/web/20081205031526/http://www.mcafee.com/us/local_content/white_papers/wp_rootkits_0407.pdf}}</ref>. Hanno diversi possibili vettori di installazione per intercettare e modificare il comportamento standard delle application programing interfaces ([[Application programming interface|API]]<nowiki/>s). Alcuni iniettano delle [[Dynamic-link library|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’utilizzoL'utilizzo di estensioni dell’applicaizioni, fornite dal produttore stesso. Per esempio, [[File Explorer|Windows Explorer]] ha delle interfacce pubbliche che permettono a terze parti di estenderne le funzionalità

* Intercettazione di messaggi

* [[Debugger]]s

Riga 83:

== Installazione e occultamento ==

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à|vulnerabilità di sicurezza]] per ottenere un aumento dei privilegi non desiderato. Un altro approccio è quello che utilizza un [[Trojan (informatica)|cavallo di troia]] (trojan), ingannando l’utente di un computer facendogli credere che l’installazione del rootkit è in realtà un’installazione benigna<ref name=":4" /> — 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’altroqualcun altro autorizzato dal proprietario, con lo scopo, ad esempio, di monitorare gli impiegati, rendendo le tecniche sovversive inutili<ref>{{Cita libro|autore=John Wiley & Sons|titolo=Professional Rootkits|anno=2007|editore=|città=|p=244|ISBN=978-0-470-14954-6}}</ref>.

L’installazione di rootkit malevoli è commercialmente guidata, con un metodo di compensazione [[:en:Compensation methods#PPI|pay-per-install]]<nowiki/> tipico per la distribuzione<ref>{{Cita pubblicazione|autore=|titolo=TDL3: The Rootkit of All Evil?|rivista=http://www.eset.com/resources/white-papers/TDL3-Analysis.pdf}}</ref><ref>{{Cita web|url=http://www.eset.com/us/resources/white-papers/The_Evolution_of_TDL.pdf|titolo=IT Security Resources{{!}} News, Whitepapers & Videos {{!}} ESET {{!}} ESET|sito=www.eset.com|accesso=8 giugno 2016}}</ref>.

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<ref>{{Cita web|url=http://www.usenix.org/publications/login/1999-9/features/rootkits.html|titolo=USENIX {{!}} The Advanced Computing Systems Association|sito=www.usenix.org|accesso=8 giugno 2016}}</ref>. Non è raro per un rootkit disabilitare la capacità di [[:en:Event Viewer|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<ref name=":7">{{Cita pubblicazione|autore=|titolo=Hacking Exposed Malware & Rootkits (Chapter10)|rivista=http://www.mhprofessional.com/downloads/products/0071591184/0071591184_chap10.pdf}}</ref>. Il “rootkit perfetto” può essere pensato come il “[[:en:Perfect crime|crimine perfetto]]”: quello che nessuno si rende conto che ha avuto luogo.

Riga 94:

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<ref name=":7" />. 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 (informatica)|virus]], la scoperta e l'eliminazione dei rootkit è una lotta costante tra le due parti<ref name=":7" />.

La identificazione può utilizzare diversi approcci differenti, incluse firme (es. Software Antivirus), check di integrità (es. [[Firma digitale|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 [[:en:Hooking|hooked function]]<nowiki/> dove il malware potrebbe compromettere il comportamento del sistema<ref>{{Cita pubblicazione|autore=|titolo=SANS Institute InfoSec Reading Room. Kernel Rootkits|rivista=https://web.archive.org/web/20120910164327/http://www.sans.org:80/reading_room/whitepapers/threats/kernel-rootkits_449}}</ref> 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<ref>{{Cita web|url=http://sourceforge.net/projects/zeppoo/|titolo=zeppoo|sito=SourceForge|accesso=8 giugno 2016}}</ref>, [[:en:Chkrootkit|chrootkit]], [[:en:Rkhunter|rkhunter]], e [[:en:OSSEC|OSSEC]]. Su ambiente Windows, i software di questo tipo sono Microsoft Sysinternals, [[:en:RootkitRevealer|RootkitRevealer]]<ref>{{Cita web|url=https://technet.microsoft.com/en-us/sysinternals/bb897445.aspx|titolo=RootkitRevealer|sito=technet.microsoft.com|accesso=8 giugno 2016}}</ref>, [[Avast!|Avast! Antivirus]], [[Sophos]] Anti-Rootkit<ref>{{Cita web|url=https://www.sophos.com/products/free-tools/sophos-anti-rootkit.aspx|titolo=Anti-Rootkit Scanner {{!}} Free Rootkit Detection and Removal Tool {{!}} Sophos Virus Protection|sito=www.sophos.com|accesso=8 giugno 2016}}</ref>, [[F-Secure]]<ref>{{Cita web|url=http://www.f-secure.com/en_UK/security/security-lab/tools-and-services/blacklight/index.html|titolo=F-Secure UK and Ireland {{!}} Switch on Freedom|sito=www.f-secure.com|accesso=8 giugno 2016}}</ref>, Radix<ref>{{Cita web|url=http://www.usec.at/rootkit.html|titolo=Radix|autore=|data=|accesso=}}</ref>, [[:en:GMER|GMER]]<ref>{{Cita web|url=http://www.gmer.net/|titolo=GMER - Rootkit Detector and Remover|sito=www.gmer.net|accesso=8 giugno 2016}}</ref> e [[:en:WindowsSCOPE|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.

Riga 116:

=== Integrity checking ===

La [[:en:Code signing|firma del codice]] utilizza la struttura della [[chiave pubblica]] per verificare se il file ha subito modifiche dopo essere stato [[Firma digitale|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<ref>{{Cita web|url=https://msdn.microsoft.com/en-us/library/ms537364(VS.85).aspx|titolo=Signing and Checking Code with Authenticode (Windows)|sito=msdn.microsoft.com|accesso=8 giugno 2016}}</ref>. 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|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è—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<ref>{{Cita web|url=http://www.trustedcomputinggroup.org/files/resource_files/C2426F48-1D09-3519-AD02D13C71B888A6/Whitepaper_Rootkit_Strom_v3.pdf|titolo=Stopping Rootkits at the Network Edge {{!}} Trusted Computing Group|sito=Trusted Computing Group|data=1º giugno 2009|lingua=en|accesso=8 giugno 2016}}</ref>. 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<ref>{{Cita pubblicazione|autore=|titolo=TCG PC Specific Implementation Specification, Version 1.1|rivista=http://www.trustedcomputinggroup.org/files/resource_files/87B92DAF-1D09-3519-AD80984BBE62D62D/TCG_PCSpecificSpecification_v1_1.pdf}}</ref>.

=== Memory dump ===

Forzare un dump completo della [[memoria virtuale]]<nowiki/>, o un [[Core dump|dump del kernekernel]]<nowiki/>l (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 [[:en:Debug symbol|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<ref>{{Cita web|url=https://support.microsoft.com/en-us/kb/927069|titolo=https://support.microsoft.com/en-us/kb/927069|sito=support.microsoft.com|accesso=8 giugno 2016}}</ref><ref>{{Cita libro|autore=Seshadri, Arvind; et al|titolo=Pioneer: Verifying Code Integrity and Enforcing Untampered Code Execution on Legacy Systems|anno=2005|editore=|città=}}</ref>. 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 ==