snort icmp.rules alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP redirect host";itype:5;icode:1; reference:arachnids,135; reference:cve,CVE-1999-0265; classtype:bad-unknown; sid:472; rev:1;) alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP redirect net";itype:5;icode:0; reference:arachnids,199; reference:cve,CVE-1999-0265; classtype:bad-unknown; sid:473; rev:1;) http://www.amagri.it/attacco/strumenti/sniffer/sniffing-faq/sniffing-faq_3.htm Redirect Ci sono diversi modi per far si che il traffico passi attraverso il proprio sistema permettendo quindi la cattura delle connessioni: ARP: Si possono fare molti giochi utilizzando ARP. Prima di tutto, è possibile inviare un pacchetto ARP spacciandosi per il router locale. Questo però con tutta probabilità non farà altro che saturare le vostre connessioni visto che TUTTI crederanno che voi siate il router. Avendone le capacità è anche possibile inviare un pacchetto ARP spacciandosi per qualcuno in particolare. Questo produce buoni risultati con i sistemi Windows visto che non fa altro che chiudere tutte le proprie connessione in corso, dando in questo modo la possibilità di sostituirsi al posto di qualcuno. ICMP Redirects: Molti sistemi operativi supportano gli ICMP Redirects, ovvero la possibilità di poter dire ad una macchina di inoltrare i pacchetti attraverso il proprio sistema piuttosto che il router locale. ICMP Router Advertisements: Una variazione di ICMP che permette di ottenere lo stesso risultato di un ICMP Redirect e cioè convincere una macchina che il proprio sistema è il router locale. In tutti questi casi, bisognerà configurare la propria macchina di modo tale che inoltri poi il traffico verso la reale destinazione prevista. 3.8.2 ARP Redirect I pacchetti ARP contengono sia l'associazione locale [N.d.t. Tra indirizzo MAC ed indirizzo IP] che quella desiderata. Per esempio, supponiamo che Alice voglia trovare l'indirizzo MAC di Roberto. Roberto ha un indirizzo IP di "192.0.2.1". Alice invierà una richiesta ARP con le seguenti informazioni: Operazione Richiesta --------------------------------------------------- Alice 192.0.2.173 00-40-05-A4-79-32 Roberto 192.0.2.1 ?? ?? ?? ?? ?? ?? L'intero scambio potrebbe essere schematizzato dal diagramma sottostante. Alice ha un pacchetto IP di un certo tipo (diciamo un ping ICMP) da inviare a Roberto. Alice invia una richiesta ARP in modo da trovare l'indirizzo MAC di Roberto. Quest'ultimo risponde ad Alice, indicandogli il proprio indirizzo MAC. Ora Alice invia il suo pacchetto IP all'indirizzo MAC Ethernet appena trovato. Alice ----> ARP richiesta broadcast ----> Roberto Alice <---- ARP risposta unicast <---- Roberto Alice ----> ICMP richiesta ping ----> Roberto Alice <---- ICMP risposta ping <---- Roberto Alice <---- ICMP richiesta ping <---- Carlo Ora Roberto ha un pacchetto IP da inviare ad Alice. In teoria Roberto dovrebbe inviare una richiesta ARP per Alice in modo da trovare il suo indirizzo MAC. Ma questo non avviene. Visto che ricorda le informazioni MAC che gli sono state inviate nella richiesta ARP originale. [N.d.t. Quella fatta in precedenza da Alice]. Infatti, ognuno sulla rete locale ha visto la richiesta essendo stata questa inviata in broadcast. Così se Carlo a questo punto vorrà inviare un ping ad Alice, non necessiterà di effettuare una richiesta ARP, anche se non aveva partecipato allo scambio di battute originale [N.d.t. Tra Alice e Roberto]. I broadcast vengono inviati a tutti coloro presenti sulla rete Ethernet. Perciò, è possibile invertire il funzionamento di uno switch inviando dei pacchetti ARP sostenendo di essere qualcun'altro come indirizzo sorgente. E' possibile inviare in broadcast un pacchetto sostenendo di essere il router, in tal caso ognuno tenterà di instradare i pacchetti attraverso di voi. Oppure è possibile inviare una richiesta ARP solo all'indirizzo MAC della vittima, sostenendo di essere il router, a questo punto solo la vittima inoltrerà i pacchetti verso di voi. Al contrario, è possibile inviare un pacchetto ARP all'indirizzo MAC del router sostenendo di essere la vittima. In tutti questi casi, bisognerà essere preparati ad inoltrare i pacchetti verso la loro destinazione reale, altrimenti verranno interrotte le comunicazioni. Per alcuni programmi di esempio visitare http://www.zweknu.org/src/MiM/ 3.8.3 ICMP Redirect Un ICMP redirect indica alla macchina di inviare i suoi pacchetti in una direzione diversa. Un esempio tipico è quando vi sono due sottoreti logiche sullo stesso segmento fisico. Alice è su una sottorete e parla con Roberto sull'altra sottorete. Nessuno dei due sa di essere sullo stesso segmento fisico, ma il router locale lo sa. Quando Alice invia un pacchetto al router destinato a Roberto, il router invia un ICMP Redirect ad Alice per informarla del fatto che può inviare il pacchetto a Roberto direttamente. Un hacker (Marco) può invertire tutto questo inviando un redirect ad Alice per far si che questa invii a lui i pacchetti diretti a Roberto. 3.8.4 ICMP Router Advertisements IICMP Router Advertisements informa gli utenti su chi sia il router. Un hacker può inviare questi pacchetti sostenendo di essere un router; gli utenti crederanno a questi pacchetti ed inizieranno ad inoltrare il loro traffico attraverso quell'utente. Fortunatamente, molti sistemi non supportano questa caratteristica visto che è relativamente nuova. Ma anche ora che le implementazioni relative alla sicurezza sono ben note, molti sistemi non la supportano. Per maggiori informazioni vedere http://www.l0pht.com/advisories/rdp.txt [N.d.t. Il collegamento rimanda adesso al sito http://www.atstake.com] 3.8.5 Sostituirsi all'indirizzo MAC della vittima L'idea è di portare lo switch ad iniziare ad inoltrare verso di voi i frames destinati alla vittima. Questo è possibile semplicemente inviando dei frames con l'indirizzo sorgente della vittima. La caratteristica di "apprendimento automatico" dello switch farà credere che voi siate ora la vittima, e vi invierà i frames verso di voi. Il problema ovvio sarà che la stessa vittima continuerà ad inviare frames con il proprio indirizzo MAC (portando lo switch nella condizione iniziale). Un altro problema è dato dal fatto che se la vittima non riceve il frame, tende ad interrompere la comunicazione in corso, con la conseguenza assenza di traffico da catturare. Ci sono diverse soluzioni a questo problema, in base a quello che si vuole fare. Si potrebbe sovvertire una connessione autenticata, in tal caso si passerà ad effettuare un DoS della vittima (mettendola offline), redirigire lo switch e continuare nella connessione come se niente fosse. Per esempio, diciamo che Alice ha una connessione Telnet al server Roberto. Si effettua un DoS sulla macchina di Alice, mettendola offline. Quindi si inviano dei pacchetti con l'indirizzo MAC di Alice, portando lo switch ad inviarvi i pacchetti destinati ad Alice. Per agganciare la precedente connessione, si porterà il server ad inviare un pacchetto (per esempio utilizzando il servizio talk per richiedere una connessione). A questo punto, basterà analizzare i numeri di sequenza e di acknowledgement per continuare la connessione Telnet. Un'altra soluzione al problema è data dal "campionare" il traffico. Inviare dei pacchetti con l'indirizzo MAC della vittima ad intervalli occasionali. Si avrà la probabilità di intercettare i prossimi pacchetti destinati alla vittima, ma la vittima si ritroverà con un timeout e dovrà recuperare la connessione. In questo caso l'utente vittima noterà occasionali ritardi nella rete. Una soluzione simile potrebbe essere questa, alla ricezione di un pacchetto, basterà rigirarlo ed effettuarne il broadcast. In questo modo la vittima continuerà a ricevere il pacchetto. Un flusso stabile di traffico in uscita e successivo broadcast del traffico in ingresso ci permetterà di recuperare una buona percentuale del traffico originale. On the i5/OS system, the TCP/IP stack will notify IDS in the event of any ICMP redirect message whether the intent is valid or not, and whether or not the stack has been configured to ignore such messages. http://www.redbooks.ibm.com/redpapers/pdfs/redp4226.pdf