Perché non riesco a collegarmi a un indirizzo falsificato con arpspoof?

Question

Perché non riesco a collegarmi a un indirizzo falsificato con arpspoof?

#1 da (1 voti)

3

Volevo vedere quante combinazioni di siti Web e browser sono ancora vulnerabili a un attacco tls stripping (come implementare HSTS o disabilitare completamente il testo libero HTTP). Per farlo volevo vederlo in prima persona usando lo strumento sslstrip, ma non ero in grado di farlo funzionare (seguendo le istruzioni sulla stessa pagina del progetto): lo spoofing ARP apparentemente funziona bene, dal momento che il PC di destinazione non può più navigare , ma sslstrip non riceve nulla.

Ho provato ad ascoltare con un socket TCP sulla porta reindirizzato da iptables, ma non ho ricevuto nulla, quindi ho escluso anche iptables, e ora sto solo provando a ricevere connessioni direttamente sulla porta usata dal client della vittima. Ho provato sia abilitando che disabilitando l'inoltro ip (con /proc/sys/net/ipv4/ip_forward ), e usando wifi o ethernet come interfaccia dall'host attaccante, ma non cambia nulla:

Questo è il comando che sto usando dall'host che attacca (indirizzo 192.168.1.33 hostname macbook , un box Linux 3.11):

sudo arpspoof -i eth0 -t 192.168.1.31 192.168.1.1

( 192.168.1.1 è il gateway) e poi

sudo socat TCP4-LISTEN:80 STDOUT

sull'host della vittima ( 192.168.1.31 ):

socat - TCP4:192.168.1.1:80

Posso aprire la connessione, ma se provo qualcosa, non ricevo nulla sull'host che attacca (puntando socat all'indirizzo IP dell'aggressore funziona ovviamente)

traceroute mostra che apparentemente lo spoofing ARP ha avuto successo:

> traceroute 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 60 byte packets
 1 macbook.local (192.168.1.30) 2.719ms 5.932ms *
 2 * * *
 3 * * *
 4 * * *
 5 * * *
 [snip]
28 * * *
29 * * *
30 * * *

arp -n output dall'host della vittima

Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.33             ether   00:1d:4f:fc:af:fc   C                     wlan0
192.168.1.1              ether   00:1d:4f:fc:af:fc   C                     wlan0

network man-in-the-middle arp-spoofing

posta berdario 21.11.2013 - 14:16

fonte

1 risposta

Leggi altre domande sui tag network man-in-the-middle arp-spoofing

Access-Control-Allow-Origin intestazione spoofing? È possibile utilizzare un filtro servlet Java per estrarre script non inseriti nella whitelist?

score 1 · Answer 1

C'è una collisione IP in corso. Sebbene tu abbia convinto 192.168.1.31 che tu sia 192.168.1.1 con il seguente comando (il che significa che hai influenzato la sua tabella di routing):

sudo arpspoof -i eth0 -t 192.168.1.31 192.168.1.1

... il 192.168.1.1 continua a pensare al suo 192.168.1.1, quindi quando vede le richieste arp per il proprio IP, sia la macchina che il router risponderanno con un indirizzo MAC. Il primo indirizzo MAC ricevuto sarà quello per ottenere il pacchetto (non pensarlo perché vedrai una voce per il tuo IP avvelenato in arp -n che le richieste arp per quell'IP cesseranno necessariamente). Inoltre, non sa di NON inviare pacchetti alla macchina vittima, né di rispondere ad altri pacchetti che sembrano provenire da quella macchina.

In genere, man-in-the-middle è proprio questo, "nel mezzo", quindi dovresti provare quanto segue:

sudo arpspoof -i eth0 -t 192.168.1.31 192.168.1.1

sudo arpspoof -i eth0 -t 192.168.1.1 192.168.1.31

Il secondo indica al router di inviare pacchetti indirizzati a IP 192.168.1.31 all'utente (anziché alla macchina vittima originale). Se il tuo computer vittima riceve un pacchetto dal vero 192.168.1.1 con il vero indirizzo MAC di quella macchina, sai qual è il suo comportamento? Quindi è meglio evitare questa possibilità reindirizzando tutti i pacchetti dal vero 192.168.1.1 destinato a 192.168.1.31, poiché si suppone che ci si trovi nel mezzo.