Sto facendo un'esercitazione con penna didattica e sto cercando di intercettare il traffico da una macchina Windows compromessa. Ho utilizzato i moduli di controllo post-exploitation sniffer e packetrecorder Meterpreter, ma finora hanno contenuto solo pacchetti destinati all'host che sto utilizzando o al traffico broadcast. Sto cercando di capire se mi mancano alcuni dati o se non ci sono altri tipi di traffico nella sottorete.
Uno di questi moduli funziona in modalità promiscua?
Per rispondere se il modulo dello sniffer viene eseguito in modalità promiscua per impostazione predefinita sto eseguendo un test nel mio laboratorio in questo momento e lo aggiornerò qui al termine.
Aggiorna
Alla fine la risposta diventa SÌ. Il modulo sniffer esegue la cattura in modalità promiscua.
Per testare ho impostato un win-xp-sp2 (10.10.10.101) vm su proxmoxVE (kvm virtual env). L'ho aggiunto a un bridge e aggiunto kali-linux (con ip 10.10.10.15) e qualche altro computer (machine-a 10.10.10.100 e machine-b 10.10.10.110) al bridge. Dopo aver eseguito l'exploit per netapi, ho avviato il modulo sniffer sulla destinazione. Il problema è che linux bridge funziona come switches per impostazione predefinita, quindi di nuovo mi sono imbattuto nello stesso problema. Potevo solo vedere le macchine possedere traffico e trasmissioni. Ora per fare in modo che un bridge di Linux funzioni come un hub e non come un interruttore, l'invecchiamento della tabella di indirizzi mac di bridge deve essere impostato su 0 (quindi non ha affatto un mac-address-table e il traffico come le trasmissioni che lo ospitano a tutti i membri Per riferimento il comando è brctl setageing <bridgename> 0 . Una volta eseguito, ho eseguito il ping da machine-b a machine-a ed ecco cosa ho ottenuto:
2013-08-28 21:22:03.000000 ARP, Request who-has 10.10.10.100 tell 10.10.10.110, length 46
2013-08-28 21:22:03.000000 ARP, Reply 10.10.10.100 is-at 2e:76:03:d3:b9:72, length 46
2013-08-28 21:22:03.000000 IP 10.10.10.110 > 10.10.10.100: ICMP echo request, id 11328, seq 1, length 64
2013-08-28 21:22:03.000000 IP 10.10.10.100 > 10.10.10.110: ICMP echo reply, id 11328, seq 1, length 64
2013-08-28 21:22:04.000000 IP 10.10.10.110 > 10.10.10.100: ICMP echo request, id 11328, seq 2, length 64
2013-08-28 21:22:04.000000 IP 10.10.10.100 > 10.10.10.110: ICMP echo reply, id 11328, seq 2, length 64
2013-08-28 21:22:08.000000 ARP, Request who-has 10.10.10.110 tell 10.10.10.100, length 46
2013-08-28 21:22:08.000000 ARP, Reply 10.10.10.110 is-at 22:06:8c:52:9f:c5, length 46
Come puoi vedere, nessuno dei precedenti dovrebbe essere visto da xp2 vm oltre all'ARP che ha pacchetti. Quindi posso tranquillamente dire che tutti i pacchetti che in qualche modo raggiungono l'interfaccia che viene sniffata sono effettivamente registrati dal modulo dello sniffer ed è sicuramente in esecuzione in modalità promiscua.
Informazioni generali ma importanti
Gli switch inviano pacchetti destinati a IP su cui si ha una voce ARP solo su host remoti. L'host remoto invierà il pacchetto con un indirizzo MAC di destinazione in base alla sua tabella ARP e un switch invierà solo la porta in cui si trova l'indirizzo MAC. Quindi, anche in modalità promiscua vedrai solo pacchetti esplicitamente destinati al tuo IP o alle tue trasmissioni a cui vengono inviate tutte le porte connesse allo switch nello stesso dominio di collisione (VLAN e subnet).
Gli hub invece rispecchiano i dati ricevuti da qualsiasi luogo verso tutte le porte, indipendentemente dall'indirizzo MAC di destinazione, poiché non sono abbastanza intelligenti da sapere su quale porta è disponibile l'indirizzo MAC di destinazione. Questo porta al traffico tra le altre macchine che ti vengono mandate e probabilmente è il caso che speravi, ma da quello che hai descritto lo switch virtuale si comporta come un semi-intelligente switch con una tabella MAC e il comportamento è come descritto nel primo paragrafo.
Leggi altre domande sui tag network penetration-test sniffer metasploit