Newsgroup: it.comp.sicurezza.varie
Titolo: Sniff, arp e reti switchate, domanda teorica.

Ho scoperto solo ora, da vero pollo, che e' possibile effettuare lo
sniffing anche in reti switchate. Il metodo, a mio avviso piu' "fine" e'
l'ARP spoofing, il riassunto della cui tecnica si puo' leggere su:
http://www.sans.org/newlook/resources/IDFAQ/switched_network.htm
Ora, mi par d'aver capito, che il trucco sta nel fatto che quando una
macchina, diciamo A, fa una richiesta ARP  per sapere l'indirizzo mac di
una macchina B, tale richiesta la fa in broadcast, ergo la macchina
"sniffante" puo' mandare il suo bravo pacchetto fake in cui indica il
SUO come l'indirizzo mac della macchina B, modificando cosi' la cahe arp
della macchina A, e quindi leggere i pachetti da A a B e poi
eventualmente forwardare i pacchetti alla vera macchina B.
Tutto molto bello, ma quel che mi sfugge e': quando A ha fatto la
richiesta l'ha fatta in broadcast, ergo anche la vera macchina B
risponde a tale richiesta, che fine fa la risposta della vera macchina
B? Secondo me la macchian A, cosi' per come la capisco io, dovrebbe
ricevere due risposte: l'indirizzo mac della macchina sniffante e
l'indirizzo mac della vera macchina B, perche' mai dovrebbe scegliere la
seconda?
 
E poi, piu' in pratica, quel che non capisco, se io fisso nello switch
una volta per tutte la tabella mac-ip una volta per tutte ed
immodificabile, chissenefrega? Sara' lo stesso switch a rispondere alle
arp request, non e' vero? 
Ho fato una ricerca con deja e non ho trovato che due messaggi su questo
tema, del '99 e non l'intero thread, mi scuso se ho fatto una domanda
vecchia.
Grazie mille per l'attenzione,
l.

 B? 
E chi ti ha detto che B sia, in quel momento, in grado di rispondere? <G>
-- 
Inviato il gio 31 mag 2001 16:36:57 CEST da 212.177.57.193
[212.177.57.193]
http://www.neuromante.net/

 E chi ti ha detto che B sia, in quel momento, in grado di rispondere? <G>
Infatti bisogna "tappare" B. Ma dato che, visto che mi inseressa il
traffico da A a B, e' probabile che B sia un server (di qualunque cosa),
allora tale tappatura del server puo' anche essere che venga loggata.
In sostanza se con una rete non switchata un pirla qualsiasi puo'
mettere uno sniffer su un qualsiasi 95 e vedere tutto quel che passa, in
una rete switchata deve avere della capacita' che probabilmente gli
permetterebbero di entrare nel server anche dall'esterno senza tante
balle con le tabelle arp e gli sniffer. O no?
Grazie comunque,
b.

www.oxid.it


www.oxid.it


 
www.oxid.it
Passi il quote canino degno di un subumano ma anche in doppia copia:
chi e' quel criminale che ti ha rimesso in liberta'?
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

eventualmente forwardare i pacchetti alla vera macchina B.
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Dal fondo della mia ignoranza, mi sono sempre domandato *come*. Con
che protocollo, voglio dire.
Leonardo
-- 
FORSE un virus? Accertatene! 
http://www.avp.it/
         ADOTTA ANCHE TU
Curiosita'? Prova a CERCARE! 
http://www.google.com/
              QUESTA
Informazioni utili:          
http://members.nbci.com/gouldukat
     SIGN
MAIL anonima, allegato .EXE? 
http://www.google.com/search?q=hybris
  :-)

 balle con le tabelle arp e gli sniffer. O no?
ARP, sniffer, scanner e quant\'altro possono
essere semplicemente attività di preparazione
all\' attacco del server. 
ciao
------------------------------------------------------------------------
Questo messaggio e' stato inviato tramite i Newsgroup di Punto
http://www.punto.it
------------------------------------------------------------------------

 che protocollo, voglio dire.
Dal profondissimo della mia, direi che siamo nel caso di "routing
diretto" per cui nel classico livello ip. In pratica la macchina che
sniffa fa da router con il seguente semplice algoritmo:
1)sono la destinazione? Mi tengo il pacchetto
2)la destinazione e' la macchina B? Glielo spedisco
3)la destinazine e' qualsiasi altra macchina? Spedisco al default router
Ma e' solo una mia interpretazione. Se poi vuoi sapere "in pratica" come
si faccia, allora nell'articolo citato parlava dell'ip forwarding che in
un sistema linux dovrebbe essere abilitato a livello di kernel, e che
pare si possa abilitare anche in 2000. Ma ne so ben poco.
Stammi bene,
b.

diretto" per cui nel classico livello ip.
Gia'. Ma il meccanismo e' questo:
Io, macchina A, con MAC AAAAAA, dico allo switch di avere MAC BBBBBB, e
in questo modo quando C invia pacchetti con l'IP di B ed il MAC BBBBBB,
quei pacchetti arrivano ad A, cioe' a me.
Ora io questi pacchetti li voglio forwardare a B. CHE MAC UTILIZZO? Che
fara' lo switch quando vedra' quel MAC?
E' _questo_ che mi intriga.


 Leonardo
Boh, ti dico come l'ho capita io. Semplice schemino:
C----A-----B
A e' lo sniffer e C vuole comunicare con B
All'inizio della comunicazione C fa una richiesta ARP:"Chi cazzo e' che
la l'indirizzo MAC corrispondente all'IP di B?"
Risponde A(con una balla): "L'indirizzo mac corrispondente a quell'ip ce
l'ho io, spedisci pure all'indirizzo AAAAA"
A questo punto la arp-cache nel sistema operativo di C viene modificata
ed associera' l'IP di B col Mac di A. Nello switch non cambia nulla: C
manda una trama con l'indirizzo destinatario mac di A, lo switch la
interpreta, vede l'indirizzo mac di A, e spedisce la trama sulla porta
corrispondente al Mac di A, ovvero ad A stesso. Lo switch non sa nulla
degli ip, ha solo una tavola porta-mac.
Quando io (cioe' A) ricevo la trama proveniente da C, con l'indirizzo
mac di A (ovvero il mio) MA CON L'IP di B, non faccio altro che spedire
la trama a B, di CUI HO IL VERO MAC. O se vuoi modifico l'indirizzo mac
della trama che ho ricevuto mettendoci l'indirizzo mac di B invece del
mio. Lo switch che ha solo una tabella mac-porta vede l'indirizzo mac
del destinatario e lo spdisce a quella porta che lui sa, ovvero quella
corrispondente alla macchina B.
Insomma secondo me lo switch non puo' accorgersi di nulla.
Altro e' il caso in cui ho a che fare con uno switch evoluto che associ
alla porta un determinato mac, e a quel determinato mac un ip. Ma in tal
caso non e' piu' un vero switch (secondo me), ma di fatto un router,
magari veloce e poco configurabile, ma se siamo a livello ip e' un
router. 
Sempre sottointeso per come l'ho capita io.
Spero di esserermi spiegato, magari ho scritto solo fregnacce, ma spero
siano fregnacce chiare.
Stammi bene,
b.

 fara' lo switch quando vedra' quel MAC?
<cut>
Ok vediamo se riesco a spiegarmi e soprattutto se ho capito bene la
questione:
Supponiamo:
In questo esempio connetteremo 3 sistemi in a switched network:
Il sistema 'Gate' e' il default gateway con indirizzo 10.1.1.1
Il sistema 'Pollo' e' il sistema che si vuole fregare addr.: 10.1.1.18
Il systema 'Sniffer' e' l'attacker che fungera' da 'man in the middle'
addr.:10.1.1.19
Per iniziare l'attacco per prima cosa lancio arpspoof (che fa parte di
DSNIFF) sul sistema Sniffer. Questo programma permettera' di intercettare i
pacchetti del nostro target host (Pollo) diretti ad un altro host (Gate)(di
solito si tratta del default gateway). Se fai un #man arpspoof otterai
ulteriori delucidazioni sul suo funzionamento.)
Poi 'Sniffer' fa un ping su 'Gate' e su 'Pollo'.Questo permettera' di
cache'are' i rispettivi MAC addr, necessari per lanciare arpspoof.
Next, dal systema 'sniffer' lancio un #arpspoof -t 10.1.1.18 10.1.1.1
Questo fara' redirect tutto il traffico di 'Pollo' destinato al default
gateway 'Gate'.
E' chiaro che dobbiamo anche azionare l' IP forwarding su 'Sniffer' per
trasformarlo in a router e ridirezionare il traffico da 'Pollo' a 'Gate'
dopo che lo abbiamo sniffato per bene. Volendo si potrebbe azionare il
kernel-level IP forwarding su 'Sniffer' ma non lo raccomando visto che
potrebbe spedire anche gli ICMP redirect, il che complicherebbe un po' le
cose.
Usando invece fragrouter -B1, tutto risulta molto piu' semplice e
funzionale.
Infine come packet analyzer, ho usato linsniff per effettuare il lavoro.
Quindi una volta attivato arpspoof, 'Sniffer' ha iniziato a spedire ARP
replies contraffatti a 'Gate'.
'Pollo' ha tranquillamente aggiornato il suo ARP table per riflettere il
'nuovo' Hardware address di 'Gate', il legittimo default gateway...
Per esempio supponiamo che un user from 'Pollo' inizia un FTP e POP session
to 192.168.12.12. La richiesta invece di essere spedita a 'Gate' e ricevuta
da 'Sniffer'.
'Pollo' e' stato fregato nel spedire il suo traffico a 'Sniffer' perche' il
suo ARP table e' stato modificato per map'are' il MAC address di 'Sniffer'
all' IP address di 'Pollo'. Tutto il traffico e' stato redirected a
192.168.12.12 via 'Sniffer' dato che abbiamo attivato IP forwarding usando
fragrouter che ha trasformato 'Sniffer' in un router.
Morale della favola...per evitare questo tipo di attacco e' di utilizzare
(quando possibile) static ARP entries specialmente in sistemi 'importanti'.
esempio applicherei static ARP entries tra il Firewall e i border routers.
Oppure si potrebbe utilizzare un software come arpwatch che monitora i
cambiamenti del ARP table.
HTH
Tony H

 che protocollo, voglio dire.
o te lo fa il kernel (ma cosi' ti decrementa il TTL e con un tracepath lo sgami al volo)
o te lo fa lo sniffer (che non decrementa il TTL ed e' piu' difficile da scoprire...)
bye

 seconda?
protocollo stateless...
cattiva implementazione di ARP...
per una prova pratica:  
http://ettercap.sourceforge.net
bye

 E chi ti ha detto che B sia, in quel momento, in grado di rispondere? <G>
pessimo modo di poisonare... tu devi dare meno dell'occhio possibile... se lo flood e' come dire EHI SONO QUI !! TI VOGLIO POISONARE...
bye

 fara' lo switch quando vedra' quel MAC?
quello vero di B.
solo C e' poisonato, tu lo sai il mac giusto di B
bye

 bye
Grazie mille, era proprio questa  "stetelessness" dell'implementazione del protocollo arp che mi sfuggiva, e
che spiega piu' o meno tutto.
Stammi bene,
b.

 Insomma secondo me lo switch non puo' accorgersi di nulla.
ok, chiaro. ma se per caso B rispondesse a C? qui non interviene A. Non e'
che nei pacchetti di risposta di B c'č l'associazione IP-MAC? cosi' lo
switch potrebbe accorgersene (o almeno C)...
Scusate x le eventuali vaccate! :-)
--
Ciao by Beppe

 Leonardo
Lo switch costruisce la sua route table in base agli indirizzi MAC sorgenti
che vede nel frame Ethernet dei pacchetti che processa.
Quando la tua macchina (MAC A) deve rimandare fuori i pacchetti che gli sono
arrivati per
frutto di un poisoning, per non incasinare lo switch ed assicurarti che lo
stesso sia in grado di
trovare sempre su quale porta può raggiungerti, li devi mandare con indirizzo
Ethernet
sorgente (MAC A) cioè il tuo oppure con un indirizzo ethernet Spoofed (es:
00112233445566)
che non deve essere già presente sulla LAN (sempre che non sia stata abilitata
lato switch la
funzionalità di "Port Security", in questo caso infatti lo switch accetterebbe
per ogni porta un solo
un MAC address).
Ad ogni modo tu allo switch non dici niente "direttamente", è agli host che dici
che devono
parlare con tè quando vogliono raggiungersi. Il compito tuo è quello di
ri-ruotare i pacchetti modificando
il MAC sorgente (Il tuo o uno Spoofed) ed il MAC destinazione (quello corretto
che devi sapere a priori).
salutoni,
mao.
Per una prova pratica:
- Linux: 
http://ettercap.sourceforge.net
- Win2K: 
http://www.oxid.it
 (Cain v2.5)

 ok, chiaro. ma se per caso B rispondesse a C?
B risponde a C solo se C glielo chiede....
ma se io A continuo a mandare delle repies, la cache di C e' continuamente refreshata e la entry non scade mai, quindi C non fa mai la richiesta...
bye

Correzione:
nel messaggio precedente l'esempio di MAC Spoofato č 001122334455

 Ciao by Beppe
E' necessario che il poisoning sia ripetuto continuamente; se l'entry nell'ARP
cache scade
i due hosts si parleranno direttamente senza passare per la macchina A = tu
non vedi i
pacchetti.

 cambiamenti del ARP table.
Ciao Tony e complimenti per le spiegazioni.
Qualche chiarimento se possibile:
- stiamo parlando  di switch aperti come il colosseo  o funziona anche
con quelli chiusi?
- d'accordo per static entries  in etc/ethers come sicurezza ma usando
dhcpd  non dovrebbero  circolare  almeno  un paio  di  NACK quando  si
variano i mac?
Grazie Francesco.
PS mai messo le mani su una rete quindi passatemi le capperate.
-- 
<*> bash$ man -h  per il pinguino che non deve chiedere mai. <*>  
<*> lynx file:/usr/doc/*                                     <*>

 Grazie Francesco.
L'esempio che ho riportato e' molto generalizzato. Ci sono diverse tecniche
di attacco che rispecchiano le diverse configurazione del network. Ti posso
garantire che se hai accesso al network e hai i tools giusti, non esistono
ostacoli insormontabili per effettuare l'attacco.
La simulazione dell'attacco e' stata effettuata per testare e soprattutto
dimostrare ad alcuni 'ottusi' ammistratori di rete di una ben nota
compagnia, che la protezione degli switchs contro gli sniffers, non e'
assoluta.
Gli switches utilizzati sono dei Cisco Catalyst 4200 series.
Tony

 dimostrare ad alcuni 'ottusi' ammistratori di rete di una ben nota
Lavoro duro allora 8-) Tnx per i chiarimenti.
Ciao Francesco.


A = tu non vedi i pacchetti.
Credo che daro' una bella occhiata ad arp_rcv().
Una "dirty fix" potrebbe essere, cosi' sui due piedi, imporre ad
arp_send di crearsi una struttura neighbour contenente dei flags
speciali (SOLICITED).
Poi arp_rcv droppa qualsiasi reply in arrivo che non sia di tipo
SOLICITED. Cioe':
        /* Update our ARP tables */
        n = __neigh_lookup(&arp_tbl, &sip, dev, 0);
+	if ( (n)==NULL )
+	{
+		// Unsolicited. Drop.
+		// (This all but disables caching and gleaning)
+		...
+	}
+	else
+	{
+		// We requested it, apparently.
+		// Check flags, eventually printk() a warning.
+		...
+		// Check time since last timeout in jiffies
+		...
+		// Check still same ARP address, printk() a warning
+		// and (optionally? Compile time setup?) discard.
+	}




Vero, non ci avevo minga pensato :-|


+		...
++		// i.e., ARP is no longer stateless.
++		// Plenty of RFC violations herein, I'd wager.


 speciali (SOLICITED).
attento !! anche io ci avevo pensato...
ma supponi per un momento che il poisoner sia piu' veloce dell'host reale a rispondere, la tua patch non servirebbe comunque...
la reply vera arriverebbe seconda e tu la dropperesti...
bye 

la reply vera arriverebbe seconda e tu la dropperesti...
Si' e no:
+	if ( (n)==NULL )
+	{
		Qui non entriamo, perche' siamo gia' poisonati
		e (n) punta al veleno :-)
+	}
+	else
+	{
+		// We requested it, apparently.
+		// Check flags, eventually printk() a warning.
		Qui compare un primo warning: "unsolicited double"
+		// Check still same ARP address
		E qui compare un secondo warning: uno stesso IP ha
		due diversi MAC.
		In una installazione "sicura", potrei configurare il
		sistema per scartarli ENTRAMBI.
+	}
Una volta che so che fra i MAC AAAA e BBBB uno dei due e' falso, posso
ricorrere a varie strategie per appurare chi dei due e' quello buono e
nel frattempo ad es. simulare un guasto di rete.
