Provando a leggere tutti i bugfix di un programma utilizzato sulla nostra macchina (un browser, un client di posta elettronica o anche lo stesso kernel Linux) ci troveremo davanti un vero e proprio bollettino di guerra. Infatti, gli attacchi che è possibile condurre per scalare i privilegi possono essere di varia natura, così come lo sfruttare innumerevoli tipi di vulnerabilità, con il target comune di avere l’accesso privilegiato alla macchina al fine di prenderne il controllo. In questi casi il primo obiettivo dell’attaccante sarà quello di inserire “oggetti estranei” e/o modificare componenti critiche del sistema. Si pensi, ad esempio, ai rootkit LKM (Loadable Kernel Module) e/o non LKM. I primi interessano lo spazio kernel mentre i secondi si installano in user space. Non limitando la nostra attenzione ai soli rootkit possiamo immaginare anche l’introduzione di backdoor (utilizzate in genere per bypassare una fase di autenticazione) e malware in genere, senza disdegnare, per i sistemi critici, l’analisi e il monitoraggio dei file di log (non ultimo quello dedicato all’accesso), abilitazione al controllo sui file dei bit SUID e SGID nonché modifiche sul contenuto di file/directory e ai loro attributi: il primo caso comporta generalmente modifiche sui tre tempi che li contraddistinguono, nel secondo caso si hanno modifiche sui permessi e sul proprietario di appartenenza.
In merito ai “tre tempi” è bene sapere che ogni file su GNU/Linux ha tra le sue proprietà tre tipologie di tempo. Con ls -l ( man ls ) viene mostrato di default, nel sesto campo, il tempo di ultima modifica ( modification time ) corrispondente all’ultima volta che il contenuto del file è stato modificato. Qualora le modifiche sul file riguardino le proprietà (ad esempio un cambio dei permessi) il modification time rimane invariato e ciò che cambia è il tempo di ultimo cambiamento ( change time noto anche come status change time ) visualizzabile con l’opzione -c del comando ls . Tutte le volte che invece si accede al contenuto del file viene cambiato il tempo di ultimo accesso ( access time ) visualizzabile con l’opzione -u di ls . La modifica del tempo di ultimo accesso può anche essere disabilitata, ad esempio, al livello globale del file system imponendo l’opzione noatime nel file /etc/fstab oppure utilizzando il comando chattr ( man chattr ) con l’opzione -A sul singolo file. Vale la pena osservare come non sia stato definito alcun tempo di creazione del file, che in un sistema Unix-like non esiste. Quando un file viene creato i tre tempi riportati vengono impostati al tempo corrente e le informazioni verranno sovrascritte a seconda delle successive operazioni effettuate sul file. Se si vogliono preservare tali tempi anche nelle operazioni di copia occorre utilizzare l’opzione -p del comando cp ( man cp ), opzione che preserverà anche permessi e proprietario.
Per completezza di informazione specifichiamo anche che il bit SUID (Set User ID) e il bit SGID (Set Group ID) vennero introdotti per modificare il comportamento del sistema nell’esecuzione dei programmi al fine di elevarne i privilegi di esecuzione. Naturalmente si applicano solo a file eseguibili. Il bit SUID, nello specifico, se attivato fa si che il kernel imposti il corrispondente EUID (Effective User ID) a quello dell’utente proprietario del file. Poiché gli EUID vengono utilizzati per il controllo degli accessi ecco che l’attivazione del bit SUID fa sì che il programma venga eseguito con i privilegi dell’utente (e/o del gruppo nel caso di attivazione del SGID) a cui appartiene e non in base all’utente che lo ha lanciato. Tipico esempio di bit SUID impostato, il programma passwd ( man passwd ). Infatti, se provassimo ad impartire il comando ls -l /usr/bin/passwd nell’output nel campo dei permessi potremo osservare la sequenza rwsr-xr-x laddove i primi tre indicano i permessi dell’utente proprietario del file: la “s” minuscola sta a ricordare che su quel programma è attivo il bit SUID.
Generalità sul software
Ma torniamo al cuore dell’articolo. Acronimo di Host-based Intrusion Detection System , i software HIDS ricoprono un ruolo fondamentale nell’ambito della sicurezza poiché permettono di controllare l’aderenza a policy stabilite. Per i soli programmi rilasciati con licenza GNU GPL possiamo trovare vari software, ognuno dei quali presenta pregi e difetti, se poi aggiungiamo i software commerciali il numero cresce ulteriormente. Poiché l’obiettivo è analizzare la base di un software HIDS (un’analisi approfondita sarebbe impossibile poiché i libri scritti sull’argomento presentano centinaia e centinaia di pagine), prenderemo in considerazione il software che in ambito Open Source è, probabilmente, il più completo in termini di funzioni fornite: Samhain .
Sebbene abbia oramai qualche anno sulle spalle, non tutte le distribuzioni lo implementano nei propri repository a meno di impostarne qualcuno di terze parti (laddove esistenti). Inoltre, anche avendolo a disposizione nel proprio repositorio, una caratteristica dei pacchetti precompilati è quella di avere delle impostazioni predefinite, ciò significa che se ci occorresse abilitare una data funzione dovremo gioco forza compilare il pacchetto sorgente o creare un nuovo pacchetto per la distribuzione in uso. Fermo restando che per la prova in oggetto possiamo fare riferimento al pacchetto precompilato presente nei repository della distribuzione, per i motivi addotti vedremo la procedura di installazione da sorgenti.
Installiamo Samhain
Come prova installeremo Samhain su una “normale” macchina desktop, ma è evidente che la procedura di installazione, ad esempio su una macchina critica, dovrà essere effettuata idealmente subito dopo l’installazione del sistema base. In questo modo si evita che nel tempo intercorrente possano essere effettuate modifiche non volute e/o introdotti software estranei, politica che, ovviamente, è valida per qualsiasi tool di sicurezza si debba e/o si voglia installare.
Scarichiamo dal sito del progetto il pacchetto samhain-current.tar.gz ed estraiamone il contenuto con il comando tar xzvf samhain-current.tar.gz . Verranno estratti i file samhain-4.2.0.tar.gz , l’archivio compresso contenente i sorgenti da compilare, e il file samhain-4.2.0.tar.gz.asc , contenente la firma digitale per il pacchetto in formato.tar.gz. Per motivi di sicurezza il primo passo sarà verificare l’integrità dell’archivio compresso utilizzando il suddetto file .asc .
Cos’è un file.asc? Un file.asc è un comune file ASCII utilizzato da PGP (Pretty Good Privacy), o GPG (GNU Privacy Guard) in ambiente Open Source, ovvero programmi di crittografia impiegati per la comunicazione sicura. La convenzione vede l’utilizzo dell’estensione.asc per i file che contengono rappresentazioni testuali delle chiavi PGP, ovvero un messaggio con firma digitale. La verifica della firma la si effettua con l’opzione –verify di gpg , che richiede come argomento il file della firma. Senza entrare in ulteriori dettagli che esulerebbero dall’attuale contesto, potremo verificare la firma per Samhain con il comando gpg --verify samhain-4.2.0.tar.gz.asc samhain-4.2.0.tar.gz direttamente nella cartella dove sono presenti i due file indicati. Ci verrà restituito un warning sull’impossibilità di trovare la chiave pubblica associata all’ID della chiave 0F571F6C . Per questo motivo dovremo dapprima importare la chiave con gpg --keyserver pgp.mit.edu --recv-key 0F571F6C , verificarne l’impronta digitale con gpg --fingerprint 0F571F6C per passare, infine, alla verifica del pacchetto sorgente impartendo di nuovo il comando gpg --verify samhain-4.2.0.tar.gz.asc samhain-4.2.0.tar.gz .
Effettuata la verifica e appurata la validità della firma, decomprimiamo il pacchetto dei sorgenti con tar xzvf samhain-4.2.0.tar.gz : verrà creata la cartella samhain-4.2.0 .
Per le fasi di configurazione e compilazione possiamo seguire due strade differenti, entrambe riportate nel tutorial che segue. Optando per la procedura pseudo-grafica assicuriamoci di aver prima installato almeno uno tra i pacchetti dialog o xdialog , presente nei repository di tutte le distribuzioni. Terminata la fase di compilazione, sia che seguiamo la modalità grafica che quella classica, il passo successivo prevede l’autenticazione nel terminale come utente amministratore al fine di procedere con il comando make install che installerà tutti i file nei percorsi indicati durante la fase di configurazione.
Va osservato che i pacchetti sorgenti prevedono un comodo comando make uninstall che rimuove tutto quanto installato a patto, ovviamente, di non cancellare la cartella dove sono stati compilati i sorgenti. Per lo stesso scopo possiamo utilizzare il comando ./samhain-install.sh uninstall con l’ipotesi di salvare tale script senza necessità di portarsi dietro i sorgenti compilati. Al comando make install possiamo far seguire il comando make install-boot al fine di avere il lancio di Samhain all’avvio del sistema; viceversa dovremo ricordarci di lanciarlo ogni volta in modalità demone. Per disinstallare il lancio del programma all’avvio si può utilizzare invece il comando ./samhain-install.sh uninstall-boot .
Configuriamo e compiliamo Samhain
Apriamo un terminale, entriamo nella cartella samhain-4.2.0 e lanciamo ./Install.sh . Alla prima finestra di dialogo clicchiamo su OK per iniziare la fase di configurazione. Samhain ha un’architettura client/server che gli permette di essere utilizzato in ambienti complessi. Per il nostro test opteremo per disable-network: Single desktop machine .
Clicchiamo OK . Nella schermata successiva dovremo selezionare le opzioni da attivare. Nella prova l’opzione enable-static creava qualche problema in fase di compilazione, pertanto è stata disattivata. Al di là di questo le opzioni di default vanno bene. È possibile attivare l’opzione enable-login-watch per la verifica degli accessi alla macchina.
Il supporto a PGP appone la firma digitale ad ogni evento, rendendo così difficoltoso modificare qualcosa senza lasciare tracce. Se vogliamo abilitare questa funzione premiamo Si assicurandoci che sia installato GPG perché dovremo riportarne il percorso all’eseguibile a cui farà seguito l’impronta digitale della chiave da utilizzare.
Altra caratteristica è la funzione stealth che offusca la presenza del programma. Optando per Si verrà aperta la finestra Stealth options dove indicare il livello di offuscamento. Su sistemi critici è suggerito optare per full: Enable full stealth mode . Verrà richiesto un numero compreso tra 128 e 255 per ottimizzare l’offuscamento.
Seguirà l’inserimento di una parola che prenderà il nome dell’eseguibile da lanciare e infine una stringa da utilizzarsi sempre come primo parametro nel richiamare il programma. L’ultimo passo vede la scelta dei percorsi. Per accettare quelli di default optare per cancel: Don’t change the paths confermando con OK .
Con ./configure potremo optare per la configurazione manuale attraverso la quale è possibile configurare in maniera puntuale ogni singola voce: tra parentesi quadre le impostazioni di default. Per abilitare il controllo sul bit SUID e la modalità stealth, ./configure --enable-suid --enable-stealth=150 a cui fare seguire make .
Come ogni altro programma, prima di mettere in moto il tutto occorre analizzare la configurazione, che per Samhain è riportata nel file /etc/samhainrc il quale fornisce un template completo ma da affinare a seconda delle applicazioni. Un file, come si avrà modo di vedere aprendolo con un comune editor di testi con le credenziali dell’amministratore, piuttosto lungo ma con una struttura molto intuitiva, sebbene a prima vista possa sembrare complicata. Tutti i nomi delle sezioni, alquanto esplicativi, sono racchiusi tra parentesi quadre. Le righe che iniziano con i caratteri ” # “, ” ; ” o ” // ” vengono ignorate. Per evidenti motivi di spazio non possiamo elencarle tutte, ad ogni modo vediamone alcune fermo restando che il file risulta essere ben commentato con un inglese sufficientemente comprensibile.
Per l’approfondimento puntuale delle varie voci in ogni sezione si rimanda al manuale in linea man 5 samhainrc . Scorrendo il file balzano subito all’occhio le due sezioni più numerose, [Attributes] e [ReadOnly] : nella prima vengono verificate le variazioni legate ai permessi e al proprietario dei file mentre nella seconda vengono monitorate tutte le modifiche a file e directory eccetto l’attributo sulla data di ultimo accesso. A seguire abbiamo due coppie di sezioni tra loro, per certi versi, complementari e di preciso [IgnoreAll] nella quale qualsiasi variazione su file e/o directory viene ignorata (a parte accessi non riusciti che verranno invece segnalati) e di converso la [IgnoreNone] nella quale qualsiasi variazione su un file e/o directory viene segnalata. Infine, l’altra coppia di sezioni complementari, [LogFiles] , nella quale vengono ignorati i timestamp dei file nonché la loro ampiezza e relativa firma, e [GrowingLogFiles] che è uguale alla precedente solo che vengono ignorate le variazioni delle dimensioni del file solo se queste aumentano. L’apparente complessità, nonché l’elevato numero di righe, deriva dal fatto che ognuna di queste sezioni può contenere righe del tipo file=percorso_assoluto per il controllo dei singoli file nonché righe dir=Numero/percorso_directory laddove Numero indica un’analisi ricorsiva nelle sottodirectory a partire dalla directory riportata subito dopo.
Da quanto detto possiamo intuire come un tuning fine di questo file possa permettere a Samhain di controllare ogni più remoto elemento all’interno del file system nonché in tutte le sue caratteristiche peculiari. Altre sezioni riguardano le configurazioni di carattere generale alla cui categoria appartiene ad esempio [EventSecurity] che contiene voci del tipo Severity[Sezione]=valore laddove [Sezione] rispecchia uno dei nomi riportati in precedenza (ad esempio SeverityReadOnly , SeverityLogFiles , ecc.) mentre valore definisce diversi livelli di criticità tra info (la più bassa), warn (media) e crit (alta) in base alle quali è possibile definire una policy di gestione delle notifiche da poter affinare passo dopo passo.
È possibile inserire altre voci per le quali si rimanda al manuale in linea. Una seconda sezione che rientra nella configurazione di carattere generale è [Log] . Come indica il nome stesso definisce le regole di filtro per gli eventi. Tutti le voci che presentano un valore superiore o al limite uguale alla soglia ne verranno registrati gli eventi. I livelli sono definiti dai valori debug , info , notice , warn , mark , err , crit , alert o none ai quali è possibile associare gli specificatori * (con il significato di tutto), ! (tutto tranne) e = (soltanto), una sintassi già nota a chi conosce syslogd ( man 8 syslogd ). La sintassi == invece impone la segnalazione dell’evento solo quando questo è uguale al valore riportato. Con tutti questi parametri e sezioni varie è facile comprendere come il raggiungimento di un risultato soddisfacente sulla precisione nelle segnalazioni lo si può ottenere solo dopo un’accurata messa a punto, che può richiedere anche molto tempo e diverse prove.
Pronti? Via!
Poiché l’HIDS Samhain monitora, tra le altre cose, le modifiche nel file system, la prima operazione da compiere – il prima possibile – sarà allora l’inizializzazione del database del software, creando così una fotografia del sistema nelle attuali condizioni, immagine che sarà poi il modello preso a riferimento per i confronti successivi. Una volta effettuato lo snapshot dell’attuale condizione, ogni quanto tempo, poi, verranno attuati i confronti? Dipende dalla variabile SetFileCheckTime presente nel file samhainrc nella sezione [Misc] (Miscellaneous configuration options): di default è impostato un valore di 7200 secondi (2 ore), ma per le prove possiamo abbassarlo a un valore più consono (ad esempio 600 secondi: 10 minuti). Va da sé che l’esatto valore non è definibile a priori e occorre realizzare un compromesso, poiché con un valore troppo basso si rischierebbe di caricare eccessivamente la macchina mentre, di converso, un intervallo di tempo troppo lungo farebbe trascorrere troppo tempo prima di un’eventuale segnalazione in caso di violazione. Nella stessa sezione possiamo verificare che sia impostato su Yes il parametro Daemon affinché sia possibile avviare il programma in modalità demone. Altro parametro è ReportOnlyOnce , sarebbe opportuno decommentarlo (di default è disabilitato) e impostare il valore su True , in questo modo verrà generata una sola notifica in caso di violazione. Impostandolo su False si avrà invece sempre la stessa notifica ad ogni ciclo di verifica. A voi la scelta. Infine, se abbiamo abilitato Samhain per la verifica SUID/SGID dei binari sarebbe opportuno verificare se nella parte Optional modules almeno le righe di seguito elencate siano decommentate (quindi attive):
[SuidCheck]
SuidCheckActive=yes
SuidCheckInterval=7200
SuidCheckQuarantineFiles=yes
SuidCheckQuarantineMethod=2
mentre le prime 3 righe sono oramai intuitive, in particolare le ultime due opzioni permettono, rispettivamente, di mettere in quarantena i file sospetti spostandoli nella cartella /var/lib/samhain/.quarantine . Salviamo le modifiche così effettuate e creiamo una fotografia del sistema lanciando il programma con il comando samhain -t init . Partirà la scansione dell’intero sistema in base alle impostazioni riportate nel file di configurazione.
L’intera procedura potrà prendere diverse decine di minuti e nel terminale sarà un susseguirsi di messaggi i cui dati immagazzinati nel database del software (nel file samhain_file in /var/lib/samhain ) costituiranno le attuali condizioni della macchina, la “fotografia”.
Creazione del database: ogni elemento nel file system viene vagliato
Al termine possiamo provare a creare un file di nome rootkit_test con il comando touch /usr/bin/rootkit_test ( man touch ) o ad effettuare una qualunque modifica che rientri, ad esempio, almeno nel valore warn in qualunque altra parte del file system in funzione delle policy e della configurazione generale attuata nel file samhainrc. Creato il file proviamo un check sul sistema utilizzando il comando:
samhain -t check -p warn --foreground
dovremo vedere tra i vari livelli (warning in su) una voce appartenente a una modifica critica relativa proprio alla presenza del nuovo file estraneo in quel contesto.
Primo semplice test. Osservare l’output del programma
Va inoltre ricordato che dopo modifiche obbligatorie, quali quelle relative all’aggiornamento dei pacchetti (quando segnalato dal gestore dei pacchetti della distribuzione in uso), è d’obbligo aggiornare il database utilizzando samhain -t update eventualmente da utilizzare con l’opzione –interactive dove verrà chiesta l’autorizzazione al cambio del database per ogni voce cambiata. Qualora non effettuassimo questa operazione, al check successivo verranno segnalati una marea di eventi, almeno uno per ogni file cambiato. Il comando samhain ha svariate opzioni, suggerita è la consultazione del manuale online ( man 8 samhain ).
In conclusione…
L’output di Samhain non è tra i migliori in termini di leggibilità. Occorre districarsi tra tutta una serie di policy violate (il sistema aggiorna continuamente diversi file) nonché tutta una serie di voci con il suffisso _old e _new a rappresentare rispettivamente il vecchio e il nuovo stato (o valore) di file e/o directory che hanno avuto una variazione dal momento in cui è stata creata l’immagine. Vista la scarsa leggibilità di questo output è stata creata una Web-console grafica in PHP nella quale vengono riportati gli eventi notificati dal demone samhain. Non solo, ma è possibile creare file di log in formato XML e memorizzare gli eventi in un database relazione (MySQL o PostgreSQL).