:: Sicurezza nelle Reti - Riassuntonio ::
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.
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.
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.
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.
Sono scan diversi, ma simili:
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.
Mando un ACK. Le specifiche dicono che:
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.
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.
È uno scan complesso in cui c'è uno Scanner, uno Zombie ed un Target.
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.
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:)
È un'opzione IP che permette di specificare attraverso quali IP la route di un pacchetto dovrà passare. Ovviamente non è cosa buona e giusta, cmq:
Un server è predisposto ad accettare connessioni da un client.
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.
Le linee-guida che utilizza SANS per dare un valore ad una vulnerabilità sono:
La condivisione è molto rapida. Al contrario, l'applicazione delle patch è ardua perché:
Se siamo a livello di automatizzazione, vuol dire che chiunque è in grado di provare un attacco sfruttando quella vulnerabilità (script kiddies).
Un Internet Worm è un sw malevolo che automatizza un'intrusione. Ha le seguenti caratteristiche:
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...
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.
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.
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.
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.
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.
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.