cerca
Rootkit
modifica cronologia stampa login logout

Wiki

UniCrema


Materie per semestre

Materie per anno

Materie per laurea


Help

Return to Rootkit  (Edit)

Uni.Rootkit History

Hide minor edits - Show changes to output

Changed lines 73-75 from:
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.
to:
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.
Changed lines 21-22 from:
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:
to:
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:
Changed lines 29-30 from:
Per quanto riguarda l'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''
to:
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''
Changed lines 35-36 from:
Storicamente ci si sta muovendo dai ''binary rootkit'' ai ''kernel rootkit''. I primi infatti risiedono nel file system, dunque sono relativamente semplici da scansionare alla ricerca di signature che li individuino; 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).
to:
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).
Changed lines 40-42 from:
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 era 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 suddividere i ''binary rootkit'' in cinque categorie:
to:
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:
Changed line 44 from:
* quelli che garantiscono un accesso locale privilegiato al sistema
to:
* quelli che garantiscono un accesso locale privilegiato
Changed lines 55-56 from:
* (conseguenza del punto precedente) rendere inaffidabili tutti i comandi impartiti al sistema, dato che la loro esecuzione si baserà su informazioni errate impartite dal kernel
to:
* rendere inaffidabili tutti i comandi impartiti al sistema, dato che la loro esecuzione si baserà su informazioni errate impartite dal kernel
Changed lines 60-63 from:
Un terzo tipo di rootkit è quello che lavora a livello di ''librerie'' di sistema, sostituendo quelle che vengono normalmente usate per inviare informazioni dal kernel ai moduli superiori (in particolare allo spazio utente). Le librerie alterate hanno come fine quello di filtrare tutti quei dati e 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@] (stessa cosa, ma con aggiornamento dinamico) 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@], dato che tutte quelle contenute in questa directory hanno la precedenza sulle standard.
to:
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.
Changed lines 65-66 from:
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 bene o male le stesse, quindi modifica delle chiavi di registro e di altre informazioni su file e processi.
to:
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.
Changed lines 70-73 from:
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. Per la relativa facilità di rilevazione questi rootkit sono considerati di basso livello, dunque la fase di preparazione dell'incident management di un sistema da loro compromesso è stata sicuramente 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 questi vengono considerati come 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.
to:
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.
Added lines 21-28:
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.
Changed lines 37-44 from:
Considerando ora 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
.
to:
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 era 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 suddividere i ''binary
rootkit'' in cinque categorie:
* quelli che garantiscono un accesso privilegiato al sistema da remoto
* quelli
che garantiscono un accesso locale privilegiato al sistema
* 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
* (conseguenza del punto precedente) 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 per inviare informazioni dal kernel ai moduli superiori (in particolare allo spazio utente). Le librerie alterate hanno come fine quello di filtrare tutti quei dati e 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@] (stessa cosa, ma con aggiornamento dinamico) 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@], dato che tutte quelle contenute in questa directory hanno la precedenza sulle 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 bene o male 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''
.
Deleted lines 73-94:

!!Rootkit2

I primi rootkit utilizzavano una tecnica di sostituzione di binari di sistema, si attuava una modifica dei binari più critici e si proceva alla sostituzione con gli originali (attraverso anche demoni di rete). L'intruso utilizza questo tipo di procedimento per diversi motivi, uno dei quali è assicurarsi il rientro nel sistema mediante procedure remote ed un accesso da locale per eliminare tutte le evidence riguardanti la sua intrusione (in genere log file). Queste procedure di attacco prendono la forma di archivi, ove vengono immagazzinate diverse informazioni, fra le quali appunto versioni modificate dei binari di sistema che sono stati sostituiti, utility che restituiscono informazioni relative allo stato dei processi presenti nei sistemi, stato della rete, ecc.\\
Come detto in precedenta gli archivi contengono le versioni "trojanizzate" dei binari di sistema, tali binari possono essere suddivisi in cinque categorie:\\


* ''"Garantire accesso privilegiato da remoto al sistema"'';
* ''"Garantire un accesso locale privilegiato al sistema"'';
* ''"Possibilità di nascondere i processi"'';
* ''"Possibilità di nascondere i file"'';
* ''"Possibilità di celare attività utente"'';

Ci sono poi i rootkit che lavorano a livello di kernel e sono genralmente distribuiti in forma di moduli di sistema. Esistono diverse verioni di questi rootkit compatibili con le diverse versioni di Unix, come: Linux, OpenBSD, FreeBSD, Solaris. Nonostante siano diverse le versioni di questi tipi di rootkit, si ha un fattore comune, ovvere questi strumenti lavorano tutti a livello di kernel e la loro funzione principale è quella di sostituire le chiamate di sistema originali con delle versioni modificate per coprire la presenza dell'intruso.\\
Una consenguenza immediata di quanto detto in precendenza è che con questi tipi di rootkit viene compromesso il kernel stesso rendendolo di fatti inaffidabile. Con esso sono resi quindi inaffidabili tutti i comandi, in quanto esiste la possibilità che il kernel passi al sistema informazioni errate.\\


Un terzo tipo di rootkit è quello che lavora a livelli di libreria, il quale utilizza un ulteriore metodo per eludere la sua presenza. Questo metodo prevede la sostituzione di librerie di sistema che vengono utilizzate per inviare informazioni dal kernel allo spazio utente. Il compito fondamentale di queste librerie sono di far filtrare attraverso di esse le informazioni che non si vuole far arrivare ai processi ("Esempi di proscessi sono ''ps'' e ''top''"), nascondendo così la presenza dell'attaccker. Per questo tipo di rootkit esistono poi delle varianti, ovvero è possibili modificare la configurazione del loader, che ha appunto il compito di caricare le librerie, anziché sostituire un'intera libreria. Un esempio di questa particolare variante potrebbe essere il caricamento delle così dette ''librerie sostitutive'' per far utilizzare delle funzioni limitate di essa, anziché offrire quelle che normalmente sarebbero disponibili nella libreria originale, senza alterare la libreria stessa.\\


Sotto sistemi Windows si possono avere delle varianti per quanto riguarda l'utilizzo dei rootkit. Solitamente nei sistemi Win32 un rootkit non modifica e sostituisce i binari del sistema, ma sostituisce API. Di conseguenza ogni programma che utilizza queste API potrebbe essere infetto.
Changed lines 57-62 from:
Un terzo tipo di rootkit è quello che lavora a livelli di libreria, il quale utilizza un ulteriore metodo per eludere la sua presenza.
to:


Un terzo tipo di rootkit è quello che lavora a livelli di libreria, il quale utilizza un ulteriore metodo per eludere la sua presenza. Questo metodo prevede la sostituzione di librerie di sistema che vengono utilizzate per inviare informazioni dal kernel allo spazio utente. Il compito fondamentale di queste librerie sono di far filtrare attraverso di esse le informazioni che non si vuole far arrivare ai processi ("Esempi di proscessi sono ''ps'' e ''top''"), nascondendo così la presenza dell'attaccker. Per questo tipo di rootkit esistono poi delle varianti, ovvero è possibili modificare la configurazione del loader, che ha appunto il compito di caricare le librerie, anziché sostituire un'intera libreria. Un esempio di questa particolare variante potrebbe essere il caricamento delle così dette ''librerie sostitutive'' per far utilizzare delle funzioni limitate di essa, anziché offrire quelle che normalmente sarebbero disponibili nella libreria originale, senza alterare la libreria stessa.\\


Sotto sistemi Windows si possono avere delle varianti per quanto riguarda l'utilizzo dei rootkit. Solitamente nei sistemi Win32 un rootkit non modifica e sostituisce i binari del sistema, ma sostituisce API. Di conseguenza ogni programma che utilizza queste API potrebbe essere infetto.
Changed lines 56-57 from:
Una consenguenza immediata di quanto detto in precendenza è che con questi tipi di rootkit viene compromesso il kernel stesso rendendolo di fatti inaffidabile. Con esso sono resi quindi inaffidabili tutti i comandi, in quanto esiste la possibilità che il kernel passi al sistema informazioni errate.
to:
Una consenguenza immediata di quanto detto in precendenza è che con questi tipi di rootkit viene compromesso il kernel stesso rendendolo di fatti inaffidabile. Con esso sono resi quindi inaffidabili tutti i comandi, in quanto esiste la possibilità che il kernel passi al sistema informazioni errate.\\
Un terzo tipo di rootkit è quello che lavora a livelli di libreria, il quale utilizza un ulteriore metodo per eludere la sua presenza
.
Changed lines 45-58 from:
I primi rootkit utilizzavano una tecnica di sostituzione di binari di sistema, si attuava una modifica dei binari più critici e si proceva alla sostituzione con gli originali (attraverso anche demoni di rete). L'intruso utilizza questo tipo di procedimento per diversi motivi, uno dei quali è assicurarsi il rientro nel sistema mediante procedure remote ed un accesso da locale per eliminare tutte le evidence riguardanti la sua intrusione (in genere log file). Queste procedure di attacco prendono la forma di archivi, ove vengono immagazzinate diverse informazioni, fra le quali appunto versioni modificate dei binari di sistema che sono stati sostituiti, utility che restituiscono informazioni relative allo stato dei processi presenti nei sistemi, stato della rete, ecc.
to:
I primi rootkit utilizzavano una tecnica di sostituzione di binari di sistema, si attuava una modifica dei binari più critici e si proceva alla sostituzione con gli originali (attraverso anche demoni di rete). L'intruso utilizza questo tipo di procedimento per diversi motivi, uno dei quali è assicurarsi il rientro nel sistema mediante procedure remote ed un accesso da locale per eliminare tutte le evidence riguardanti la sua intrusione (in genere log file). Queste procedure di attacco prendono la forma di archivi, ove vengono immagazzinate diverse informazioni, fra le quali appunto versioni modificate dei binari di sistema che sono stati sostituiti, utility che restituiscono informazioni relative allo stato dei processi presenti nei sistemi, stato della rete, ecc.\\
Come detto in precedenta gli archivi contengono le versioni "trojanizzate" dei binari di sistema, tali binari possono essere suddivisi in cinque categorie:\\


* ''"Garantire accesso privilegiato da remoto al sistema"'';
* ''"Garantire un accesso locale privilegiato al sistema"'';
* ''"Possibilità di nascondere i processi"'';
* ''"Possibilità di nascondere i file"'';
* ''"Possibilità di celare attività utente"'';

Ci sono poi i rootkit che lavorano a livello di kernel e sono genralmente distribuiti in forma di moduli di sistema. Esistono diverse verioni di questi rootkit compatibili con le diverse versioni di Unix, come: Linux, OpenBSD, FreeBSD, Solaris. Nonostante siano diverse le versioni di questi tipi di rootkit, si ha un fattore comune, ovvere questi strumenti lavorano tutti a livello di kernel e la loro funzione principale è quella di sostituire le chiamate di sistema originali con delle versioni modificate per coprire la presenza dell'intruso.\\
Una consenguenza immediata di quanto detto in precendenza è che con questi tipi di rootkit viene compromesso il kernel stesso rendendolo di fatti inaffidabile. Con esso sono resi quindi inaffidabili tutti i comandi, in quanto esiste la possibilità che il kernel passi al sistema informazioni errate.
Added line 45:
I primi rootkit utilizzavano una tecnica di sostituzione di binari di sistema, si attuava una modifica dei binari più critici e si proceva alla sostituzione con gli originali (attraverso anche demoni di rete). L'intruso utilizza questo tipo di procedimento per diversi motivi, uno dei quali è assicurarsi il rientro nel sistema mediante procedure remote ed un accesso da locale per eliminare tutte le evidence riguardanti la sua intrusione (in genere log file). Queste procedure di attacco prendono la forma di archivi, ove vengono immagazzinate diverse informazioni, fra le quali appunto versioni modificate dei binari di sistema che sono stati sostituiti, utility che restituiscono informazioni relative allo stato dei processi presenti nei sistemi, stato della rete, ecc.
Changed line 43 from:
'''(..continua)'''
to:
!!Rootkit2
Added lines 1-46:
(:title Rootkit:)
[[#su]]
[[Torna alla pagina di Gestione degli incidenti informatici->Gestione degli incidenti informatici]]
----

%titolo%''':: Rootkit ::'''

>>frame<<
Ove non meglio specificato, tutti i testi tra virgolette vanno intesi come citazioni letterali dalle slide del prof [[Dario Forte]], 2008.
>><<

!!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à'''.

Per quanto riguarda l'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 scansionare alla ricerca di signature che li individuino; 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).

Considerando ora 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.

!!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. Per la relativa facilità di rilevazione questi rootkit sono considerati di basso livello, dunque la fase di preparazione dell'incident management di un sistema da loro compromesso è stata sicuramente 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 questi vengono considerati come 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.

'''(..continua)'''

----
[[Torna alla pagina di Gestione degli incidenti informatici->Gestione degli incidenti informatici]]