I NTRUSION D ETECTION S YSTEM

Transcript

1 UNIVERSITÀ DEGLI STUDI DI SALERNO FACOLTÀ DI SCIENZE MM.FF.NN. CORSO DI LAUREA DI 1 LIVELLO IN INFORMATICA I NTRUSION D ETECTION S YSTEM RILEVAMENTO ED ANALISI DEGLI ATTACCHI RELATORE CANDIDATO Prof. Visconti Ivan Fontanella Alberto ANNO ACCADEMICO 2008/09

2 INDICE INTRODUZIONE I VIRTUAL MACHINE & SERVIZI DI RETE Introduzione Applicazione Pratica 1.1 : Implementazione della Virtual Machine Applicazione Pratica 1.2 : Soft Hardering della VM/Sensore II INTRUSION DETECTION SYSTEM Introduzione Tecniche di Evasione dell'ids Applicazione Pratica 2.1 : Implementazione del NIDS/IPS SNORT Applicazione Pratica 2.2 : Interfaccia per Intrusion Detection System Applicazione Pratica 2.3 : Test di Penetrazione ed Analisi dei Log III HONEYPOT Introduzione Honeypot: Vantaggi/Svantaggi Fingerprinting di un Honeypot Applicazione Pratica 3.1 : Implementazione Honeypot Bassa Interazione Fingerprinting di Nepenthes Applicazione Pratica 3.2 : Implementazione Interfaccia per Honeypot Applicazione Pratica 3.3 : Implementazione Honeypot Alta Interazione IV SVILUPPO PLUGIN PER SURFids Applicazione Pratica 4.1 : Norman SandBox Plugin v.1.0 Applicazione Pratica 4.2 : Sort by Country Plugin v.1.0 CONCLUSIONI BIBLIOGRAFIA & NOTE Alberto Fontanella itsicurezza<0x40>yahoo.it

3 INTRODUZIONE L'obbiettivo di tale pubblicazione è finalizzato allo studio degli attacchi portati a sistemi informatici ed al rilevamento ed all'analisi delle intrusioni. Per attacchi intendiamo sia attacchi automatizzati, eseguiti senza l'intervento dell'attaccante da codice malevolo come trojan, worm ecc. che attacchi lanciati da un attaccante contro un sistema target. Tale documento si propone di fornire una visione della quantità di attacchi a cui un sistema pubblico collegato alla rete Internet è soggetto e di mettere sotto la giusta ottica l'importanza della sicurezza informatica soprattuto in campo aziendale, governativo e militare. Si inizierà con l'implementazione di un ambiente virtualizzato mediante l'utilizzo di una Virtual Machine e l'installazione di un sistema operativo GNU/Linux con i relativi servizi di rete. Tale ambiente sarà utilizzato come Sensore, con il compito di ricevere attacchi dall'esterno. Si passerà poi alla realizzazione pratica di un soft hardering della macchina virtuale creata, riducendone la superficie di attacco. Si procederà studiando i Sistemi per il Rilevamento delle Intrusioni (IDS) e le metodologie utilizzate dagli attaccanti per bypassare il rilevamento che tali strumenti si propongono di realizzare, e come sopperire a tali situazioni. Si vedrà praticamente come implementare, configurare e testare mediante test di penetrazione il NIDS/IPS open source SNORT. Si implementerà anche l'interfaccia BASE per gestire i log e gli alert generati da SNORT. Si procederà studiando gli Honeypot, ovvero i sistemi esca che simulano determinati servizi di rete e vulnerabilità, utilizzati per l'analisi più approfondita degli attacchi. Si passerà ad analizzare i vari vantaggi e svantaggi che si potranno avere utilizzando varie tipologie di honeypot, e le tecniche utilizzate per il fingerprinting degli honeypot, ovvero i metodi che permettono ad un attaccante di riconoscere un honeypot da un sistema reale. Si passerà all'implementazione pratica dell'honeypot a bassa interazione Nepenthes, capace anche di collezionare il malware (ovvero il codice malevolo, come virus, trojan, worm) che sta tentando di sfruttare la vulnerabilità simulata dall'honeypot per replicarsi; per poi passare alle tecniche di fingerprinting di Nepenthes. Si passerà poi all'implementazione dell'interfaccia per honeypot, SURFids che darà la possibilità di gestire i log generati da honeypot in varie parti della rete, in maniera strutturata e facilmente gestibile, ed all'implementazione pratica dell'honeypot web based ad alta interazione HIHAT, che permetterà di monitorare in maniera approfondita gli attacchi lato web server. Come penultimo passo si procederà allo sviluppo di due plugin per l'interfaccia per honeypot SURFids, che ne estenderanno le funzionalità. In particolare un plugin permetterà di poter sottomettere i binari del malware collezionati dall'honeypot Nepenthes alla SandBox Norman direttamente tramite l'interfaccia SURFids, nonché la possibilità di scansionare mediante antivirus tutti i binari di malware collezionati, semplicemente cliccando su un tasto dell'interfaccia. Il secondo plugin invece permetterà di ricercare gli attacchi per paese di provenienza, nonché darà la possibilità di vedere la città da cui è partito un attacco. Infine nelle note conclusive si forniranno le statistiche degli attacchi ricevuti dal sensore nel corso di circa 3 mesi di attività di analisi e monitoraggio.

4 I VIRTUAL MACHINE & SERVIZI DI RETE I.1 INTRODUZIONE Il primo passo è la realizzazione di una macchina virtuale con la funzione di Sensore per la ricezione di attacchi dall'esterno che ci permetterà di monitorare i tentativi di intrusione diretti verso la macchina. Utilizzeremo una Virtual Machine (da ora in poi VM) sulla quale renderemo operativo un sistema GNU/Linux con alcuni servizi di rete. La scelta di una VM invece di un apparato dedicato ci permetterà in linea teorica di avere diversi Sensori su una stessa macchina in ascolto su IP differenti e ci permetterà di ridurre i rischi di compromissione nel caso il sensore venga violato dall'esterno. Opereremo su un sistema HOST: jenna.dia.unisa.it Che ospiterà il nostro sistema GUEST/Sensore: rootme.dia.unisa.it Utilizzeremo il noto software per la generazione di Macchine Virtuali VMware Server [1] e creeremo la nostra VM con Sistema Operativo GNU/Linux Ubuntu 8.10 [2]. La nostra scelta è ricaduta sulla versione VMware Server invece della versione Player e/o Workstation poiché questa suddetta versione oltre ad essere scaricabile gratuitamente ed oltre a permettere la creazione di singole VM, consente anche che queste vengano eseguite in background sul sistema HOST e che vengano avviate e terminate con il boot e lo shutdown della macchina HOST stessa. APPLICAZIONE PRATICA 1.1 : Implementazione della Virtual Machine Una volta installato il software VMware Server ed aver definito un utente che agisca da amministratore, l'applicativo sarà configurabile mediante un'interfaccia web, sia sulla porta 8222 con una connessione in chiaro, che sulla porta 8333 con una connessione cifrata (SSL): L'autenticazione avviene per mezzo del sistema PAM (Pluggable Authentication Modules) e quindi con le nostre credenziali di accesso che deteniamo sul sistema HOST:

5 Una volta autenticati avremo a disposizione l'interfaccia di comando:

6 L'interfaccia fornisce varie informazioni dell'host sul quale è installato VMware Server, le VM create, i task in background, la configurazione degli apparati di rete e la possibilità di creare una o più VM: Una volta creata la nostra VM con il nostro sistema operativo GNU/Linux Ubuntu procediamo ad importarla nell'inventory e passiamo a farne il boot da interfaccia. Una volta che la nostra macchina virtuale sarà lanciata provvederemo a loggarci al suo interno utilizzando la Console che VMware Server ci mette a disposizione:

7 Una volta loggati nella VM che agirà da Sensore provvediamo a settare gli indirizzi di rete. Andremo a modificare il file /etc/network/interfaces dove assegneremo l'ip fisso del Sensore, e setteremo il gateway, dns, ecc; nel nostro caso il file interfaces sarà: root@rootme:/etc/network# cat interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address netmask network broadcast gateway Fatto ciò provvediamo ad installare vari servizi di rete, tra cui SSHD (OpenSSH), il server HTTPD (Apache) ed il supporto per PHP, i database Mysql e Postgresql. root@rootme:~# apt get install openssh server root@rootme:~# apt get install apache2 root@rootme:~# apt get install php5 root@rootme:~# apt get install php5 pgsql root@rootme:~# apt get install mysql server root@rootme:~# apt get install postgresql root@rootme:/etc# runlevel N 2 Identificato il runlevel configuriamo l'avvio dei vari servizi da effettuarsi al boot della macchina. Settiamo il flag +x dei vari script in /etc/init.d/ ed impostiamo i vari link in /etc/rc2.d/. Blocchiamo anche i servizi di cui non abbiamo bisogno e magari disinstalliamoli dal sensore.

8 APPLICAZIONE PRATICA 1.2 : Soft Hardering della VM/Sensore Effettuiamo un hardering locale del Sensore, ovvero una messa in sicurezza del nostro Sensore riducendone la superficie di attacco. Iniziamo con il rendere eseguibili solo da root i maggiori applicativi da linea di comando che permettono ad un eventuale attaccante di scaricare file sul macchina: root@rootme:/usr/bin# whereis wget curl GET links lynx ftp tftp telnet wget: /usr/bin/wget /usr/share/man/man1/wget.1.gz curl: /usr/bin/curl /usr/include/curl /usr/share/man/man1/curl.1.gz GET: /usr/bin/get /usr/share/man/man1/get.1p.gz links: /usr/bin/links /usr/share/man/man1/links.1.gz lynx: ftp: /usr/bin/ftp /usr/share/man/man1/ftp.1.gz tftp: telnet: /usr/bin/telnet.netkit /usr/bin/telnet /usr/share/man/man1/telnet. 1.gz root@rootme:~# chmod 500 wget curl GET links lynx ftp telnet.netkit Se non abbiamo bisogno di questi applicativi conviene comunque eliminarli. Scarichiamo ed installiamo un rootkit detector (ovvero un applicativo che ci permetterà di rilevare vari rootkit, ovvero vari strumenti che un attaccante utilizza una volta compromesso un sistema, per tenerne l'accesso e nascondere la sua presenza all'interno di esso), scegliamo RootKit Hunter [3] ed eseguiamo una prima scansione del sistema che ci permetterà di salvare nel database dell'applicativo i vari hash md5 dei binari del sistema ed i vari permessi di questi ultimi. Una successiva leggera anomalia nei binari del sistema sarà subito rilevata da RootKit Hunter, che provvederà a segnalarcelo con un messaggio di WARNING e l'eventuale invio di un messaggio di posta elettronica. Questi permette anche di rilevare tutti i più noti rootkit, LKM, backdoor, exploit locali e varie anomalie sul sistema. Possiamo impostare una scansione automatica del sistema da eseguirsi ad intervalli regolari, utilizzando quindi il sistema cron. Si può anche decidere di realizzare un hardering più pesante utilizzando Bastille/SElinux/AppArmor/Grsecurity, nel caso si opti per quest'ultimo, il RootKit Hunter andrà installato successivamente alle modifiche apportate dal sistema di hardering scelto. L'unico accesso autenticato del nostro sensore che dobbiamo proteggere è SSHD. Avremmo potuto impostare il demone SSH su una porta diversa dalla 22, ma abbiamo scelto la porta standard per poter analizzare i tentativi di attacco che avranno come bersaglio proprio il demone SSH. Installiamo allora uno script che ci permetterà di prevenire un bruteforce (ovvero un attacco che mira a trovare le password del sistema provando in maniera esaustiva tutte le possibili combinazioni di password o usando una lista) sulla porta 22 e di bannare (ovvero bloccare) l'ip dell'attaccante per un tempo da stabilire. Lo script sarà fail2ban [4] che permette di proteggere vari servizi come SSHD, FTP, Auth di HTTPD, ecc. da tentativi di bruteforce e DoS (Denial of Service): root@rootme:~# apt get install fail2ban Andremo a configurare fail2ban per prevenire bruteforce sulla nostra SSHD. I file di configurazione si trovano in /etc/fail2ban

9 Settiamo in /etc/fail2ban/fail2ban.conf il path per il file di log, che sarà diretto a /var/log/fail2ban.log e poi passiamo a settare il file /var/log/jail.conf, in particolare: bantime = 3600 [ssh] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 3 Abbiamo impostato che dopo 3 tentativi di login fallito sulla porta 22, fail2ban setterà un ban utilizzando il firewall iptables/ipfw/shorewall dell'ip del presunto attaccante per 3600 secondi, ovvero per un'ora. Passata un'ora dal ban, fail2ban provvederà automaticamente a togliere il blocco da quell'ip. Fail2ban andrà a scandagliare il file di log /var/log/auth.log per ricercare tentativi di login falliti relativi all'accesso SSH. Un esempio: root@rootme:/var/log# tail auth.log 3947:Jun 17 15:38:08 RootMe sshd[18659]: Invalid user asterisk from :Jun 17 15:38:10 RootMe sshd[18659]: Failed password for invalid user asterisk from port ssh2 3951:Jun 17 15:38:11 RootMe sshd[18661]: Invalid user cacti from :Jun 17 15:38:13 RootMe sshd[18661]: Failed password for invalid user cacti from port ssh2 Notiamo un tentativo di attacco da parte di che è stato repentinamente identificato e di conseguenza l'ip in questione è stato bannato per un'ora: root@rootme:/var/log# tail fail2ban.log :38:11,868 fail2ban.actions: WARNING [ssh] Ban :38:12,317 fail2ban.actions: WARNING [ssh] Unban Come detto in precedenza, dopo un'ora esatta dal ban, l'ip è stato riabilitato. Nel nostro caso gli unici servizi reali (per i servizi fittizi si veda il capitolo III sugli Honeypot) da fornire all'esterno sono SSH e HTTP, quindi provvediamo a modificare i file di configurazione dei due SQLD installati; ovvero Mysql e Postgresql in modo tale che stiano in ascolto sull'ip locale e quindi non siano raggiungibili dall'esterno.

10 II INTRUSION DETECTION SYSTEM II.1 INTRODUZIONE L'Intrusion Detection System o IDS è un dispositivo software o hardware, o la combinazione di entrambi, utilizzato per identificare accessi non autorizzati agli host o alle reti locali. Gli IDS vengono utilizzati per rilevare tutti gli attacchi alle reti informatiche e ai computer. Questi attacchi includono gli attacchi alle reti informatiche tramite lo sfruttamento di un servizio vulnerabile, attacchi attraverso l'invio di dati malformati e applicazioni malevole, tentativi di accesso agli host tramite innalzamento illecito dei privilegi degli utenti, accessi non autorizzati a computer e file, e i classici programmi malevoli come virus, trojan e worm. Un IDS è composto da quattro componenti. Uno o più sensori utilizzati per ricevere le informazioni dalla rete o dai computer. Una console utilizzata per monitorare lo stato della rete e dei computer e un motore che analizza i dati prelevati dai sensori e provvede ad individuare eventuali falle nella sicurezza informatica. Il motore di analisi si appoggia ad un database ove sono memorizzate una serie di regole utilizzate per identificare violazioni della sicurezza. Esistono diverse tipologie di IDS che si differenziano a seconda del loro compito specifico e delle metodologie utilizzate per individuare violazioni della sicurezza. Un IDS consiste quindi in un insieme di tecniche e metodologie realizzate ad hoc per rilevare pacchetti sospetti a livello di rete, di trasporto o di applicazione. Due sono le categorie base: sistemi basati sulle firme (signature) e sistemi basati sulle anomalie (anomaly). Esiste anche una terza categoria ma è un ibrido tra le 2 categorie di cui sopra. La tecnica basata sulle firme è in qualche modo analoga a quella per il rilevamento dei virus, che permette di bloccare file infetti e si tratta della tecnica più utilizzata. I sistemi basati sul rilevamento delle anomalie utilizzano un insieme di regole che permettono di distinguere ciò che è "normale" da ciò che è "anormale". Di norma un IDS non blocca i pacchetti in ingresso e/o in uscita anche se questi sono stati identificati come un possibile attacco; ma esiste la possibilità di estendere la funzionalità dell'ids e di trasformarlo in un Intrusion Prevention System (IPS) che permette mediante l'uso di firewall di bloccare quelle macchine che stanno attaccando o hanno tentato un attacco al sistema. Gli IDS a loro volta si suddividono in: NIDS Network Intrusion Detection System: analizza il traffico di rete per identificare intrusioni, permettendo quindi di monitorare non solo un singolo host ma una rete completa. Si tratta di un sistema che sniffa (legge in maniera passiva tutto il traffico passante per un segmento di rete) il traffico che passa su un segmento di rete, cercando tracce di attacchi. Le logiche su cui i NIDS si basano per riconoscere flussi non autorizzati si distinguono in: Pattern Matching: l'abilità del NIDS di confrontare i flussi a delle firme, stile Antivirus, e di notificarli prontamente. Le firme in genere indicano un set di condizioni, ad esempio: Se un pacchetto è IPv4, TCP, la porta di destinazione la 31337, e il payload contiene foo, fai

11 scattare "l'allarme". Anomaly Detection: il riconoscimento di flussi sospetti grazie ad un sofisticato meccanismo di funzioni e algoritmi matematici che si rifanno alle RFC e ai loro standard. Se uno o più flussi non rispettano gli standard, il sistema segnala l'errore con il consueto allarme. Impostando la scheda di rete del NIDS in modalità promiscua, è possibile ascoltare in maniera passiva tutto il traffico passante sul segmento di rete (sniffing), senza interferire sullo stesso. L'analisi dei pacchetti può essere effettuata mediante tre tecnologie: la Pattern Matching Analysis, la Stateful Pattern Matching Analysis e la Protocol Analysis. La Pattern Matching Analysis si occupa di analizzare i contenuti dei pacchetti alla ricerca di sequenze di bit prefissate. Questo è un approccio semplice da implementare ma, allo stesso tempo, abbastanza rigido e pesante dal punto di vista computazionale in quanto ogni pacchetto deve essere confrontato con centinaia di firme di intrusion detection. Ogni firma è associata a un attacco specifico ed istruisce l'ids sul tipo di pacchetto da considerare anomalo. Ciascuna firma assume una struttura composta da sei componenti <protocollo>, <ip_src>, <porta_src>, <ip_dst>, <porta_dst> e <payload_con_exploit> che vengono confrontati con i pacchetti in ingresso e in uscita nel seguente modo: SE il protocollo utilizzato è <protocollo>, l'indirizzo IP sorgente è <ip_src>, la porta associata all'indirizzo IP sorgente è <porta_src>, l'indirizzo IP di destinazione è <ip_dst>, la porta associata all'indirizzo IP di destinazione è <porta_dst> e il payload contenuto nel pacchetto è <payload_con_exploit>, ALLORA genera un allarme. In base a quanto descritto fino ad ora, un allarme viene generato quando si verifica il pattern matching tra un pacchetto ed una regola. Questo significa che sarebbe sufficiente dividere la stringa dell'exploit contenuta nel payload in due frame TCP (tramite frammentazione), per non far rilevare l'attacco. Per risolvere questo problema, è stata introdotta la Stateful Pattern Matching Analysis che è un criterio più sofisticato di analisi che effettua gli stessi controlli della Pattern Matching Analysis tenendo però conto dello stream TCP dei dati. Questo comporta maggiore carico computazionale in quanto capita spesso che ci siano sessioni TCP aperte da monitorare per un lungo periodo. La Protocol Analysis invece, genera un allarme per ogni violazione delle specifiche tecniche di un protocollo. Si supponga, per esempio, che un client intenda aprire una connessione TCP con un server, a tal fine invia un pacchetto SYN e si aspetta di ricevere o un pacchetto SYN/ACK o un RST/ACK. Qualsiasi altro pacchetto ricevuto viene considerato una violazione e genera un allarme. Questa tecnica minimizza, qualora il protocollo sia ben definito, il numero di falsi positivi generati se traffico lecito viene riconosciuto come anomalo, tuttavia, non è raro trovare delle RFC ambigue che lasciano spazio agli sviluppatori di implementare il protocollo a propria discrezione, o sistemi che non rispettano le RFC o parti di esse (vedi Micro$oft). I NIDS lavorano con grandi quantità di dati e per funzionare necessitano di almeno un algoritmo di generazione degli allarmi. Alcuni amministratori scelgono di ritenere anomalo tutto il traffico considerato non affidabile (politica chiusa), altri invece scelgono di ritenere affidabile tutto il traffico non considerato anomalo (politica aperta). Nella prima ipotesi il carico computazionale del NIDS sarà rilevante e verrà generato un alto numero di falsi allarmi detti falsi positivi che possono essere dovuti a: pacchetti generati da alcuni dispositivi di rete non riconosciuti dal NIDS; violazioni di protocolli non dovute ad attacchi ma ad implementazioni ambigue; circostanze normali ritenute pericolose dal NIDS, come per esempio la visualizzazione di una pagina web contenete il codice sorgente di un exploit.

12 Nella seconda ipotesi il numero di allarmi sarà notevolmente minore, ma si corre il rischio di non identificare il traffico anomalo che non trova alcuna corrispondenza con le regole impostate, generando falsi negativi che sono più difficili da rilevare e possono essere dovuti a: configurazioni non appropriate della rete; quantità di traffico elevata a tal punto da non essere supportata dal NIDS; traffico cifrato; firme errate o troppo generiche; attacchi 0 day dei quali non è stata ancora rilasciata la corrispettiva firma. Il numero di falsi negativi può essere limitato solo con una costante manutenzione del NIDS e con un frequente aggiornamento delle firme. Per trovare il giusto equilibrio tra falsi positivi e falsi negativi è opportuno analizzare approfonditamente la topologia della rete ed eliminare la causa che genera falsi allarmi. Procedere eliminando radicalmente la regola corrispondente ad un attacco, potrebbe essere una scelta troppo ingenua e superficiale che tal volta può comportare il rischio di non rilevare attacchi reali. Una delle attività maggiormente critiche nella configurazione e messa in opera di un IDS è il suo posizionamento all interno della rete da monitorare. In base alla topologia della rete, possono presentarsi diversi casi. Quando in un segmento di rete gli host sono collegati da un hub, l implementazione di un NIDS è relativamente semplice perché l hub è una componente di rete che si occupa di replicare ogni singolo pacchetto su tutte le porte. In questo modo è sufficiente collegare il NIDS a una porta qualsiasi dell hub per poter leggere tutto il traffico passante. In presenza di uno switch, invece, la situazione è diversa e l implementazione dei NIDS è maggiormente complicata. Gli switch, infatti, lavorano ad un livello superiore della pila ISO/OSI rispetto agli hub e quando devono inviare un pacchetto, lo inviano solo verso la relativa porta di destinazione. Una soluzione per poter leggere tutto il traffico del segmento di rete è il port mirroring che consiste nel monitorare una o più porte dello switch, copiandone il traffico su un altra porta detta mirror port. Tale porta dovrà necessariamente avere una capacità di banda possibilmente pari alla somma della capacità di banda di tutte le porte monitorate. Solo in questo modo il traffico potrà essere gestito in modo opportuno. Come detto, la scelta del posizionamento degli IDS è un attività molto delicata che deve tener conto delle esigenze della rete e delle risorse di cui si dispone. Un altra variabile da considerare nel posizionamento di un IDS è la sua collocazione rispetto ad un firewall. Posizionando l Intrusion Detection System all esterno del firewall, si identificheranno tutte le attività anomale incluse quelle che non avranno accesso alla rete in quanto bloccate dal firewall. Un IDS disposto in questo modo sarà più esposto agli attacchi provenienti dall esterno perché privo di protezione. Le risorse richieste sono ingenti in quanto la quantità di traffico analizzato e di log memorizzati sarà rilevante. Una soluzione più economica consiste nel posizionare l IDS all interno del firewall per monitorare solo il traffico che accede alla rete. In tal modo saranno generati meno allarmi e ci saranno meno log da analizzare. Se invece, l obiettivo dell IDS è la protezione dei server, una valida alternativa è installare il Sistema di Intrusion Detection nella Demilitarized Zone (DMZ). Tuttavia, gli altri segmenti di rete rimarrebbero privi di monitoraggio. Pertanto, nel caso in cui le risorse a disposizione siano elevate, la soluzione più robusta consiste nell installare un IDS per ogni segmento di rete. Questo permette di tenere sotto controllo l intera rete, di configurare ciascun Intrusion Detection System in maniera diversa in base alle esigenze del singolo segmento e di evitare eventuali sovraccarichi dei sistemi. Inoltre, se un IDS dovesse venire meno per una qualsiasi ragione (come ad esempio errori hardware/software o attacchi di vario tipo), gli altri segmenti di rete continuerebbero ad essere monitorati.

13 HIDS Host based Intrusion Detection System: consiste in un agente che analizza l'host alla ricerca di intrusioni. Le intrusioni vengono rilevate analizzando i file di log del sistema, le system call, le modifiche al file system della macchina (modifiche nel file delle password, nel database degli utenti e nella gestione dei privilegi, ecc), e altre componenti della stessa. PIDS Protocol based Intrusion Detection System: consiste in un agente che sarà situato solitamente all'ingresso di un server monitorandone ed analizzandone i dati in ingresso a livello di protocollo, tra una componente connessa (client) ed il server da proteggere. Solitamente viene utilizzato per situarsi all'ingresso di un web server, monitorando il flusso HTTP o HTTPS e lo stato del protocollo. Eventuali anomalie nel flusso del protocollo designato saranno segnalate con il consueto allarme. APIDS Application Protocol based Intrusion Detection System: consiste in un agente che sarà situato solitamente tra un gruppo di server, monitorando ed analizzando la comunicazione sugli specifici protocolli di Applicazione. Ad esempio in un web server con un database questo monitorerebbe lo specifico protocollo SQL e ne segnalerebbe le anomalie. HYIDS Hybrid Intrusion Detection System: una combinazione dell'approccio HIDS e NIDS. L'IDS può a sua volta essere di tipo passivo o reattivo. Nel tipo passivo l'ids una volta identificata una violazione di sicurezza provvederà a loggarla ed a notificare l'allarme alla console e/o all'amministratore dell'ids. Nel tipo reattivo conosciuto anche come IPS (Intrusion Prevention System) l'ids risponderà all'attività sospetta resettando la connessione incriminata o settando il firewall di sistema per bloccare la sorgente del presunto attacco.

14 II.2 TECNICHE DI EVASIONE DELL'IDS Un IDS non è un sistema a prova di attaccante, ma anzi necessita di un'opportuna configurazione e soprattutto di un testing opportuno tenendo conto delle possibili tecniche che un attaccante può utilizzare per bypassare il rilevamento che tali strumenti si propongono di realizzare. Alcune delle tecniche che andremo a vedere si basano sul fatto che in una comunicazione TCP i pacchetti possono essere frammentati e possono essere ricevuti non nell'ordine in cui sono stati frammentati, necessitando quindi dell'opportuno riassemblaggio. Caso 1 Il timeout del riassemblaggio della frammentazione dell'ids è più piccolo rispetto al timeout del riassemblaggio della frammentazione della Vittima. Supponiamo che il timeout dell'ids per quanto riguarda il riassemblaggio della frammentazione sia 15 secondi e che l'ids stia monitorando alcuni host linux che hanno un timeout di default di 30 sec. per quanto riguarda il riassemblaggio della frammentazione. Supponiamo che l'attaccante suddivida l'attacco in 2 frammenti. L'attaccante dopo che invierà il primo frammento può inviare il secondo frammento con un ritardo di 15 secondi ma sempre entro i 30 secondi. Il secondo frammento ricevuto dall'ids sarà scartato poiché l'ids ha già perso il primo frammento a causa del timeout. Quindi la vittima riassemblerà i frammenti e riceverà l'attacco mentre l'ids non farà nessun rumore e non genererà allarmi. Caso 2 Il timeout dell'ids per quanto riguarda il riassemblaggio della frammentazione è più grande rispetto al timeout del riassemblaggio della frammentazione del sistema operativo della Vittima. Di default, l'ids SNORT ha un timeout di riassemblaggio della frammentazione di 60 secondi. Comparato a quello di Linux/FreeBSD che è di 30 secondi. Nonostante ciò, anche questo può essere evaso. Consideriamo che l'attaccante abbia frammentato il pacchetto d'attacco in 4 segmenti: 1, 2,3, 4. L'attaccante invia il frag2* ed il frag4* con un payload falso, i quali sono ricevuti sia dalla vittima

15 che dall'ids. Egli attende che si verifichi il timeout di 30 sec da parte della vittima che scarta così i frammenti frag2* e frag4* con il payload falso. Il bello di questo attacco è che la vittima non ha ancora ricevuto il frammento 1 così che ella scarterà silenziosamente i pacchetti senza generare errori ICMP. L' attaccante allora invia frag1 e frag3 con un payload legittimo. In questo caso la vittima ha soltanto i frammenti 1 e 3, mentre l'ids ha i frammenti 1, 2* (con payload falso) 3 e 4* (con payload falso). Siccome l'ids ha tutti e 4 i frammenti farà un riassemblaggio TCP e siccome i frammenti 2 e 4 inviati dall'attaccante hanno un payload falso il checksum di rete computato sarà invalido, così l'ids scarterà il pacchetto. Tuttavia, adesso la vittima ha soltanto i frammenti 1 e 3. Se l' attaccante adesso invia di nuovo i frammenti 2 e 4, ma questa volta con payload corretto, l'ids avrà soltanto questi due frammenti (poiché gli altri sono stati scartati dopo il riassemblaggio) mentre la vittima li avrà tutti con payload corretto: frag1, frag2, frag3 e frag4. La vittima eseguirà il riassemblaggio e riceverà l'attacco : ) Caso 3 Attacchi basati sul TTL (Time To Live) Questi attacchi richiedo che l'attaccante abbia una conoscenza a priori della topologia della rete della vittima. Questa informazione può essere ottenuta con strumenti come traceroute che danno l'informazione sul numero di router tra l'attaccante e la vittima. Un tipico attacco basato sul TTL potrebbe essere il seguente. Un router è presente tra l'ids e la vittima e si presume che l'attaccante conosca questa informazione. L'attaccante lancia l'attacco spezzandolo in tre frammenti. Egli invia il frammento 1 con un valore grande di TTL e questo è ricevuto sia dall'ids che dalla vittima. L'attaccante invia il secondo frammento con payload falso e con il valore del TTL pari ad 1. Questo frammento è ricevuto dall'ids ma il router (che è situato tra l'ids e la vittima) lo scarta poiché il valore del TTL è diventato 0. L'attaccante allora invia il frammento 3 con un TTL valido. Questo porta l'ids ad eseguire un riassemblaggio TCP sui frammenti (frag1, frag2*, frag3), mentre la vittima sta ancora attendendo il secondo frammento (frag2). L'attaccante infine invia il secondo frammento (frag2) con un payload valido e la vittima esegue un riassemblaggio sui frammenti (frag1, frag2, frag3) e riceverà l'attacco. In questa fase l'ids ha soltanto il frammento 2, avendo già eseguito un riassemblaggio ed avendo ripulito lo stream a causa del checksum invalido.

16 Caso 4 Sovrapposizione di Frammenti In aggiunta a questi attacchi che sono basati sul timeout del riassemblaggio della frammentazione, c'è un'altra classe di attacchi basati sulla sovrapposizione di frammenti. In base al sistema operativo sono state identificate differenti politiche per quanto concerne il riassemblaggio della frammentazione, poiché sistemi operativi differenti operano differenti riassemblaggi dei frammenti. Sono state identificate 5 differenti politiche di riassemblaggio. Politica di Frammentazione Piattaforma BSD right HP JetDirect BSD AIX 2, 4.3, 8.9.3, FreeBSD, HP UX B.10.20, IRIX 4.0.5F, 6.2, 6.3, 6.4, NCD Thin Clients, OpenBSD, OpenVMS, OS/2, OSF1, SunOS 4.1.4, Tru64 Unix V5.0A,V5.1, Vax/VMS Linux Linux 2.x First HP UX 11.00, MacOS (version unknown), SunOS 5.5.1,5.6,5.7,5.8, Windows (95/98/NT4/ME/W2K/XP/2003) Last Cisco IOS First: è dove il sistema operativo favorisce i frammenti originali con un dato offset. Per esempio, Windows 95/98/NT4/ME/W2K/XP/2003. Last: è dove il sistema operativo favorisce la sottosequenza di frammenti con un dato offset. Per esempio, Cisco IOS.

17 L'attaccante invia l'attacco spezzandolo in 4 frammenti. Egli invia prima i frammenti 1,2 e 3, che entrambi i sistemi operativi accettano. Adesso l'attaccante invia il frammento 2*, il frammento 3* ed il frammento 4. In questo caso il payload del frammento 2* e del frammento 3* è differente da quello del frag2 e frag3 inviati precedentemente, ma l'offset del frammento, la lunghezza e gli altri campi nell'header IP rimangono gli stessi. In questo scenario un sistema operativo farà un riassemblaggio del frammento basato sulla politica. First farà un riassemblaggio sui frammenti 1,2,3,4; mentre un sistema operativo basato sulla politica di riassemblaggio Last riassemblerà i frammenti 1,2*,3* e 4. Caso 5 Attacco di Offuscamento del Payload Un IDS può essere evaso offuscando o codificando il payload dell'attacco in un modo che l'host vittima riuscirà ad invertire ma non l'ids. In passato, un attaccante usando il carattere Unicode poteva codificare i pacchetti dell'attacco in modo tale che un IDS non li avrebbe riconosciuti ma che un web server IIS avrebbe decodificato e riconosciuto, ed attaccare così la vittima I vari %c1%1c, %c0%9v ecc. sono la codifica del carattere /. Quindi..%c0%af.. rappresenta../.. ovvero il tentativo di attraversare la webroot del server web, tentativo che sarebbe fallito utilizzando../.. ma che in questo contesto ha avuto successo a causa della codifica Unicode che il web server IIS riconosce e decodifica nel corrispettivo carattere ascii. In passato questo attacco ha portato alla compromissione dei sistemi vittima ed all'evasione dell'ids a causa della codifica/decodifica Unicode non riconosciuta dallo stesso.

18 URL Encoding Un altro metodo di offuscamento è la codifica dell'url dell'attacco: Un attacco per prelevare il file delle password da sistemi *nix sarebbe codificato nel seguente modo: GET %2F..%2F..%2Fetc%2Fpasswd HTTP/1.1 Uso del Doppio Slash (//) Si può utilizzare il doppio slash al posto del singolo slash: Una firma dell'ids che avrebbe cercato il pattern /etc/passwd avrebbe fallito nell'incontrare la stringa //etc//passwd differente dalla prima a causa del doppio slash. Mentre il web server avrebbe accettato il formato della doppia barra trasformando l'uri nella corrispettiva: /../../etc/passwd Reverse Traversal Un altro metodo di offuscamento per aggirare le firme dell'ids è il fatto che è possibile passare un URL che per richiamare un determinato file, prima entri in una sottodirectory e poi esca da quest'ultima per puntare al file target, ad esempio: bin/qualcosa/../bugged.cgi Nel caso l'ids avesse come firma per il cgi bacato dell'esempio, qualcosa come uricontent: /cgi bin/bugged.cgi questa verrebbe aggirata. Directory di Autoreferenza Come sappiamo.. indica la directory padre mentre. indica la directory corrente. Un attacco potrebbe avvalersi di questo per offuscarsi ed aggirare le firme dell'ids: bin/./bugged.cgi Quanto sopra punterà allo stesso cgi bacato ma userà l'offuscamento delle directory di autoreferenza per aggirare la firma che cercherà nel contenuto dell'uri qualcosa del genere uricontent: /cgi bin/bugged.cgi

19 Fine Prematura della Richiesta Un altro metodo di offuscamento si avvale del fatto che alcuni IDS verificano soltanto la richiesta scartando i dati extra sottomessi dal client. Esempio: GET /some.file HTTP/1.0\r\n Header: blah \r\n Header: blah \r\n Header: blah \r\n Header: blah \r\n \r\n Se l'ids in questo caso non si cura dei dati extra sottomessi dal client ma si ferma dopo la richiesta del client, ovvero dopo: GET /some.file HTTP/1.0\r\n Si potrebbe offuscare il nostro attacco sottomettendo alla vittima: GET /%20HTTP/1.0%0d%0aHeader:%20/../../cgi bin/bugged.cgi HTTP/1.0\r\n\r\n ovvero GET / HTTP/1.0\r\n Header: /../../cgi bin/bugged.cgi HTTP/1.0\r\n \r\n Che è una richiesta valida riconosciuta dal web server. Paramentro Nascosto Qui entrano in gioco i parametri che sono sottomessi con il contenuto dinamico. Tipicamente i parametri di una pagina sono del tipo: index.php?name=hack&gid=12&album=ids&param=... Come per l'ipotesi di cui sopra, per salvare tempo e risorse l'ids potrebbe essere configurato per eseguire un check sul file richiesto e non sui suoi parametri. Quindi su: index.php Un attacco di offuscamento che sfrutta questa possibilità potrebbe essere il seguente: GET /index.htm%3fparam=/../../etc/passwd HTTP/1.0 ovvero GET /index.htm?param=/../../etc/passwd HTTP/1.0

20 Malformattazione HTTP Questo tipo di attacco si avvale di una cattiva formattazione della richiesta HTTP. Di norma la richiesta HTTP è formata da 3 parti: Metodo(GET/POST/ecc) <spazio> URI <spazio> HTTP/Versione CRLF CRLF Alcuni web server tra cui Apache permettono di utilizzare un tab al posto degli spazi, quindi la richiesta diventerebbe: Metodo(GET/POST/ecc) <tab> URI <tab> HTTP/Versione CRLF CRLF Il protocollo HTTP v0.9 ha invece la seguente sintassi: Metodo(GET/POST/ecc) <spazio> URI CRLF Un IDS potrebbe non gestire richieste HTTP che non abbiano le tre parti sopra indicate e quindi avere la possibilità di essere evaso utilizzando i tab al posto degli spazi o il metodo del protocollo HTTP v0.9. Sintassi della Directory DOS/WIN I sistemi Windows utilizzano come separatore di directory il backslash \ invece del carattere slash / comunemente usato anche nel protocollo HTTP come separatore. I sistemi Windows dovranno quindi preoccuparsi di trasformare i / della richiesta HTTP in opportuni \. È possibile sfruttare questa anomalia di protocollo contro sistemi Windows per offuscare l'attacco ed evadere l'ids: GET /cgi bin\bugged.cgi HTTP/1.0 \ continua ad essere ancora un separatore valido per piattaforme Windows ma nel caso la firma dell'ids si basasse sul contenuto dell'uri, quindi uricontent: /cgi bin/bugged.cgi questa da sola non permetterebbe la rilevazione dell'attacco di cui sopra. Case Sensitivity Sempre contro i sistemi Windows, si può utilizzare per offuscare un attacco agli occhi di un IDS il fatto che i sistemi Windows sono case INsensitive, ovvero non fanno distinzione tra maiuscole e minuscole. Quindi /cgi gin/bugged.cgi sarebbe uguale a /cgi BiN/buGgEd.CGi E quindi una firma IDS che non avesse l'opzione nocase (ovvero non tenere conto della sensitività) verrebbe elusa dal suddetto attacco.