Swappa :: Sicurezza nelle Reti

 :: Sicurezza nelle Reti - Riassuntonio ::

ARP Poisoning/spoofing

ARP è un protocollo che si usa nei segmenti di rete locale, e serve per tradurre un IP in un MAC. Infatti, ogni scheda di rete ha un MAC, che la identifica univocamente. Per come è fatta Ethernet, i frame viaggiano per la rete e vengono letti solo dal MAC a cui sono destinati.

Quando voglio mandare un pacchetto IP a qualcuno sulla mia stessa rete, mi serve il suo MAC. Se non lo so, mando un messaggio di query, e attendo la risposta. Una volta ricevuta la risposta, la salvo nella mia ARP table, così per un po' di tempo non devo reinvestigare su chi ha quel tale IP.

Per poisonare tale roba, è sufficiente che ad una query ARP non sia il legittimo possessore di quell'IP a rispondere, ma sia qualcun'altro. In questo modo è possibile fare il man in the middle della situazione, e non essere intercettato, perché non c'è verso.

La pericolosità di sta roba, nonostante l'elevata criticità, è bassa, perché occorre essere fisicamente nello stesso segmento di rete.

Frammentazione IP

I pacchetti IP hanno il flag MF, che dice che dopo questo ci sono altri pacchetti da attendere per ricomporre il messaggio originale. Assieme a sto flag c'è indicato anche l'offset che dice in quale posizione si collocano i dati del frammento corrente, rispetto al messaggio originale.

Se manca il frammento numero uno, che è l'unico che contiene l'intestazione TCP o chi per esso, può darsi che sia stato bloccato dal FW, e va bene.
Se manca invece quello finale, non c'è verso: c'è sotto qualcosa, il che vuol dire o che non è mai partito, o che qualcuno si diverte a mandare pezzi di frammenti così che il router li mantiene tutti in memoria in attesa di ricomporli. Lo stesso accade se ci sono degli offset ripetuti.

A questo proposito, guardare più sotto per le faccende relative agli attacchi che bypassano i NIDS.

TCP scan

Semplicemente, invio un SYN ad una certa porta su un certo IP. Se mi risponde SYN/ACK, quella porta è aperta. Il tentativo di connessione viene tuttavia loggato dall'host.

TCP SYN SCAN

Invio un SYN, e se mi risponde con SYN/ACK, rispondo con RST. Rispetto al TCP scan semplice, c'è il vantaggio che diversi sistemi non loggano questo tipo di connessioni troncate sul nascere.

TCP FIN, Xmas, null scan

Sono scan diversi, ma simili:

FIN: mando un pacchetto con FIN a 1
NULL: mando un pacchetto senza flag
XMAS: mando un pacchetto con una certa combinazione di FIN, URG e RST a 1

Secondo le specifiche, quando arriva un pacchetto così, se la porta è aperta l'host deve rispondere con RST, altrimenti rimanere silente. Anche queste scansioni spesso non vengono loggate. Altri SO invece vanno contro le specifiche e rispondono sempre con RST.

ACK scan

Mando un ACK. Le specifiche dicono che:

se la porta è OPEN o CLOSED (ma cmq raggiungibile), devo rispondere con RST
altrimenti scarto il pacchetto

ACK scan + SYN scan

Si usa per determinare se un FW è static o stateful.
Prima faccio un SYN scan. Se ottengo udienza, cioè la porta è aperta, provo con un ACK. Se mi risponde con RST, allora vuol dire che il FW è di tipo static. Se non risponde niente, vuol dire che il FW è stateful.

Infatti, il FW static è predisposto per accettare, in ingresso verso una porta aperta su di un host, sia i pacchetti con SYN che quelli con ACK, e quindi non fa storie se mando un ACK singolo. Un FW stateful, invece, rejetta tutti i pacchetti non appartenenti ad una connessione, e quindi non lo fa passare.

UDP scan

Mando un pacchetto UDP con payload di 0 byte. Secondo specifiche, se la porta è chiusa mi ritorna una risposta con "ICMP - port unreachable". Se non ottengo risposta, si assume che sia aperta.

Idle scan

È uno scan complesso in cui c'è uno Scanner, uno Zombie ed un Target.

lo Scanner invia un SYN/ACK allo Zombie, ed attende il relativo RST. Salva il valore IP identification che ogni stack associa ad una connessione
lo Scanner invia un SYN al Target, specificando però come IP sorgente l'IP dello Zombie
lo Scanner invia un SYN/ACK allo Zombie, ed attende il relativo RST

A questo punto si confrontano gli IP identifier letti nel passo 1, con quello letto nel passo 3. provenienti dallo Zombie. Se la porta sul Target è aperta, esso avrà risposto con SYN/ACK allo Zombie. Ma lo Zombie, non sapendo che cosa farsene di quella connessione non voluta, avrà risposto RST. E siccome tutto ciò è avvenuto immediatamente DOPO il passo numero 1, allora lo Zombie avrà incrementato di 1 il suo IP identifier, e quindi al passo 3 lo Scanner leggerà un IP identifier più grande di 2 rispetto a quello ricevuto al passo 1.
Se invece la porta è chiusa, il Target avrà inviato un RST, e lo Zombie l'avrà accettato senza fare nulla. Quindi, al passo 3, genererà in risposta allo Scanner un IP Identifier che sarà maggiore solamente di 1 rispetto a quello del passo 1.

Più facile immaginarlo che spiegarlo.

OS Fingerprinting

Si inviano pacchetti anomali, e si vede come risponde il sistema. Siccome si sa che i SO rispondono in un certo modo a certi pacchetti, si è in grado di identificarli. Fyodor, autore di nmap, ha passato l'estate ad aggiornare questi database di fingerprinting:)

Source routing

È un'opzione IP che permette di specificare attraverso quali IP la route di un pacchetto dovrà passare. Ovviamente non è cosa buona e giusta, cmq:

se la lista è loose, il pacchetto può anche andare su altri host;
se la lista è strict, il pacchetto può passare solo da quegli host indicati.

Mitnick attack

Un server è predisposto ad accettare connessioni da un client.

L'Intrusore invia un SYN al Server, con IP spoofato del client
Il Server risponde con SYN/ACK al client
Il client legittimo risponderebbe con RST perché non sa niente della connessione
ma prima di fare ciò, l'Intrusore invia un ACK con IP spoofato al Server, e IP identifier CORRETTO
La connessione viene quindi accettata e prosegue, e l'Intrusore invia comandi remoti al server

Tutto ciò si basa sulla predicibilità dei numeri di sequenza che identificano le connessioni IP. La specifica dice solo che devono essere diversi per ogni connessione, e ovviamente c'è chi li genera in modo banale e chi invece li genera in modo serio. In questo attacco, tutto va a buon fine SOLO SE al passo 4 l'Intrusore è in grado di imbroccare il sequence number che il client avrebbe scritto.
Altra conseguenza è che il client legittimo viene isolato dalla comunicazione, e non può più fare nulla.

Per controbattere a ciò, occorre usare SSH, SSL, firewallare, autenticare in modo forte etc.

Classificazione delle vulnerabilità

Le linee-guida che utilizza SANS per dare un valore ad una vulnerabilità sono:

diffusione del sw incriminato
lato server o lato client
se si trova nella configurazione di default
se è facile da utilizzare (esistono già tool automatici, docs in rete etc.)
il valore dei sistemi coinvolti
la probabilità che vengano attaccati

Ciclo di vita di una vulnerabilità

Creazione, quando si scrive il codice di un sw
Scoperta
Condivisione (documenti in rete) e automatizzazione (tool automatici)
Pubblicazione patch e upgrade dei sistemi

La condivisione è molto rapida. Al contrario, l'applicazione delle patch è ardua perché:

il sistemista non ne è a conoscenza
ce ne sono troppe
possono inficiare altre funzionalità del sw

Se siamo a livello di automatizzazione, vuol dire che chiunque è in grado di provare un attacco sfruttando quella vulnerabilità (script kiddies).

Caratteristiche di un Internet Worm

Un Internet Worm è un sw malevolo che automatizza un'intrusione. Ha le seguenti caratteristiche:

è in grado di sniffare e scansionare altri sistemi per trovare nuovi target
offre un'interfaccia per i comandi
è in grado di automatizzare l'intrusione (solito concetto dell'opportunismo: si attacca chi è semplice da attaccare)
è in grado di autopropagarsi

Per fare un esempio, il Sapphire Worm nel 2003 ha infettato il 90% degli host infettabili nel giro di 10 minuti, e aveva anche un bug nella generazione degli indirizzi da testare. L'unico suo limite erano le dimensioni della banda...

FTP Bounce Attack

Il comando PORT di FTP ha la sintassi:

PORT h1,h2,h3,h4,p1,p2

dove h1..4 sono i 4 componenti dell'IP, mentre p1 e p2 indicano la porta tramite l'operazione p1*256 + p2.

L'idea di questo attacco è di accedere ad un FTP, "rimbalzando" su un FTP che chiamo Gonzo. Supponiamo che il Target rifiuti la nostra connessione, per qualche motivo, ma accetti quella di Gonzo.

Come prima cosa, devo creare uno script coi comandi che mi servono e che voglio inviare all'FTP Target. In questo script, in particolare, dico di aprire la connessione DATI verso il MIO computer.

Poi, mi connetto all'FTP Gonzo, e uploado questo script. Successivamente invio a Gonzo un comando PORT in cui specifico l'IP del Target, e la porta COMANDI del Target. Dico quindi a Gonzo che voglio RECUPERARE il file contenente il mio script. Gonzo, da bravo server, lo invia sulla sua connessione DATI, che in realtà è la connessione COMANDI su Target!

Questo vuol dire che Gonzo fa eseguire il mio script su Target. Siccome il mio script contiene i comandi che aprono la connessione DATI verso il MIO computer, allora Target eseguirà quello che gli dico io, e invierà la roba al mio computer.

Questo attacco ora viene prevenuto, facendo sì che non si possa accettare un comando PORT che specifica un IP diverso da quello della connessione Comandi.

Risposta automatica dei NIDS

Un NIDS può essere configurato in modo da essere in grado di generare risposte automatiche che comprendano la riconfigurazione automatica del FW. Intuitivamente, è possibile sfruttare questi automatismi per fargli fare qualcosa che non dovrebbe. Per questo motivo occorre sempre un occhio umano su tutta la faccenda.

Evadere un NIDS: codifica

Se invio pacchetti contenenti, nel payload, le cose incriminate che il NIDS dovrebbe vedere e fermare, ma codificate in modo strano, è possibile che il NIDS non se ne accorga. Comunque ormai tutti i NIDS sono più o meno furbi, sotto questo aspetto.

Evadere un NIDS: frammentazione

Posso inviare cose cattive ad un host dietro ad un NIDS, se per caso il NIDS e l'host stesso hanno timeout diversi nel ricomporre i messaggi frammentati.

Se il NIDS ha timeout più piccolo di quello dell'host, allora semplicemente invio la prima parte del messaggio incriminato, poi faccio scadere il timeout del NIDS (ma non quello dell'host), e invio la seconda parte. Il NIDS non vede niente perché non ha più i frammenti vecchi con cui ricomporre, e che annusando avrebbe capito contenere cose cattive. L'host invece riassembla felicemente.

Se il NIDS ha timeout più grande di quello dell'host, allora invio frammenti al NIDS, e gli faccio ricomporre una cosa che gli sembra innocua. Ma quando li reinvia all'host, l'host li riassembla in ordine diverso, e non sono più innocui.

Evadere un NIDS: TTL

Funziona se c'è anche un router di mezzo. Il router decresce di 1 il TTL di tutti i pacchetti che lo attraversano. Se gli arriva un pacchetto con TTL = 1, lo porta a 0 e fa morire il pacchetto. L'idea è di mandare pacchetti con TTL diverso in modo che il NIDS li riassembli tutti e non veda niente, mentre l'host ne vede solo alcuni (guarda caso, quelli che compongono un messaggio cattivo), perché gli altri sono stati uccisi dal router.

Evadere un NIDS: offset

Se arrivano due pacchetti diversi di un messaggio frammentato, e hanno offset uguale, quale tengo, quello che è arrivato prima o quello che è arrivato dopo? Alcuni SO ne tengono uno, altri l'altro. Sfruttando queste cose, è possibile far riassemblare una cosa diversa all'host e al NIDS, così che il NIDS non si accorga del payload malvagio.

Torna alla pagina di Sicurezza nelle Reti