Bettercap/Failed DNS Spoofing Attack

Continuing notes from Bettercap#DNS_Spoofing.

Notes

Now it's time to run our DNS spoofing attack with our malicious entries file.

Let's review all the things bettercap will be doing:

• Using the wifi network interface
• Sniffing and logging goodies to a file
• Running DNS spoofing attack against the sheep
• Running DNS traffic through Bettercap DNS server
• If facebook request found, forward them to NOPE (http://charlesreid1.com/wiki/File:Nope.jpg)

Each flag in the following bettercap command corresponds to one of the above tasks:

$ bettercap -I wlan1 -O bettercap_extrabacon.log -X --gateway 192.168.0.1 --target 192.168.0.7 \
        --dns extrabacon.conf --httpd --httpd-path ./pub

This didn't work. (NOTE: should have added --httpd-port 80)

Alternatives that I tried:

# specify port 53 instead of 5300 (nope)
$ bettercap -I wlan1 -O bettercap_extrabacon.log -X --gateway 192.168.0.1 --target 192.168.0.7 --dns extrabacon.conf --dns-port 53 --httpd --httpd-path ./pub

# do not specify gateway (nope)
$ bettercap -I wlan1 -O bettercap_extrabacon.log -X --target 192.168.0.7 --dns extrabacon.conf --httpd --httpd-path ./pub

# run ARP poisoning attack too (nope)
$ bettercap -I wlan1 -O bettercap_extrabacon.log -S ARP -X --gateway 192.168.0.1 --target 192.168.0.7 --dns extrabacon.conf --httpd --httpd-path ./pub

The problem is, the image/page is not loading. Possible underlying issues:

• The redirect is happening from port 443, not from port 80, so the firewall isn't redirecting the request to 8081
• The sheep's browser is detecting that an HTTPS request for facebook is being redirected to a non-HTTPS request for something else. It serves up an HTTPS Connection Not Secure warning.

Let's try against an insecure, non-HTTPS sportsball page, to see if it's the HTTPS that's causing problems. Put this in extrabacon.conf:

local .*espn\.com

Now carry out the attack again.

We apparently have success?

Except, not really, because it blocks way more sites than it is supposed to.

For example, MLB and NBA are also blocked, probably because they're associated.

But then, the Kali Linux official site is also blocked.

Umm, wat?

I restarted the attack, watching the network interface from the beginning with Wireshark. The spoofing attack didn't seem to be working well as multiple DNS requests were being answered by the gateway. I could see requests being intercepted by attacker. But again, the requests were not being dealt with correctly - the DNS server was hijacking too many requests/domains.

I tried changing the port to port 53, but no effect. I also tried running an ARP spoofing attack to try and get all the traffic, not just the DNS traffic, from the sheep flowing through the attacker. That did not work and seemed to break something with the DNS attack. After I stopped trying a DNS and ARP attach together, I saw some very screwy behavior from the sheep: when I typed in a web address in the sheep's browser, I would not see any DNS packets at all showing up at the attacker. (Indication: maybe they're going somewhere else?)

Disconnecting from network, resetting the mac address of the attacker machine, and reconnecting had no effect.

Conclusion

Need to be running an ARP spoof attack simultaneous with the DNS spoof attack - otherwise we'll be waiting for DNS traffic, but it will never come to us, because it only passes between the router and the client and not through the man in the middle.

Picking this back up here: Bettercap/Failed DNS Spoofing Attack 2