Bettercap/Failed DNS Spoofing Attack 2
First experiment is covered here: Bettercap/Failed DNS Spoofing Attack
Second experiment, now that I know I need to be running an ARP spoofing attack simultaneous with the DNS attack.
Configure DNS File
We configured this attack to hijack requests for charlesreid1.com:
# Empty lines or lines starting with # will be ignored. local .*charlesreid1\.com
Run ARP+DNS Attack
Start by running the Bettercap command:
bettercap -I wlan1 -O bettercap_extrabacon.log -S ARP -X \ --gateway 192.168.0.1 --target 192.168.0.7 \ --dns extrabacon.conf --dns-port 53 \ --httpd --httpd-path ./pub
This sets up the ARP poisoning, and runs the DNS spoofing on port 53. It runs an HTTP host to host the NOPE page.
Now, we have the sheep being DNS-spoofed. Let's test it out.
(NOTE: This did not work, should have added
Testing It Out
On the sheep, I visit an insecure site, but NOT one that is in the DNS configuration file: http://nytimes.com
Immediately the sheep shows the NOPE page. It's not supposed to.
I visit another insecure site, NOT one that is in the DNS configuration file: http://nba.com
Again, the sheep shows the NOPE page. It's not supposed to.
I visit a secure site: https://dropbox.com.
The Dropbox site loads as expected - no redirects, no issues.
I visit another secure site: https://en.wikipedia.org
Wikipedia loads as expected.
I visit an insecure site: http://mlb.com
The sheep shows the NOPE page. It's not supposed to.
This attack is not working as expected.
It's possible my DNS cache is crusty.
Watching the packet traffic, here's what I'm seeing for the requests for insecure sites (e.g., nytimes):
- Sheep types "nytimes.com" into browser
- DNS request packet for nytimes.com server, addressed to gateway, arrives at attacker
- Attacker forwards DNS request to Google public DNS server, 126.96.36.199
- Google public DNS server responds to attacker with 188.8.131.52
- Attacker, masquerading as gateway, sends DNS query response to sheep
Watching the packet traffic flowing, I can actually see from inspecting the DNS packets that the sheep should not be redirected to the NOPE page. And yet... the sheep is still going there, for some reason.
Well duh, it's my firewall rule. All the packets going through port 80 are being redirected to port 8081.
Without the Firewall
On the sheep, I visit a secure page, dropbox.com:
No spoofing happening.
On the sheep, I visit a secure page, sourceforge.net:
No spoofing happening.
On the sheep, I visit an insecure page, battle.net (definitely not in the DNS cache):
I see the NOPE page. So, things are still not working correctly.
Packet Traffic Again
Inspecting packet traffic again, for the battle.net request, I can see the DNS request packet from the sheep (192.168.0.7) to the gateway (192.168.0.1), which is intercepted by the attacker. The attacker then forwards the DNS request to Google's public DNS servers, gets a response, and forwards the response along to the sheep (spoofing the gateway).
I can see the packet with the DNS query response, which contains the battle.net server IP address, 24,105.29.40, but again, the sheep is doing something else that leads it to connect instead to the HTTP server on the attacker.
Cache Problem Again
Okay, proof this is (also?) a cache problem:
When the DNS spoofing from the attacker stops, and has been stopped for a good 10 minutes, I point the sheep to nytimes.com, and what do I see?
An empty black background, and a missing NOPE graphic.
Re-Running Adjusted Attack
Okay: have adjusted the attack somewhat to test things out.
Running ARP poisoning attack with bettercap.
Hijacking DNS but using empty configuration file.
Results: when I visit HTTP sites in the browser, they break: "Unable to connect." When I visit HTTPS sites in the browser, they work just fine.
Now trying to use a third machine (on the local network) to serve up the static content. I get the feeling the httpd flag is setting a firewall rule that's redirecting all HTTP traffic to that port.
Nope. That doesn't work either.
More ideas? Maybe packets on port 80 aren't allowed through and therefore aren't forwarded.
Well, it changed the problem, at least. I tried opening port 80 with a rule like this:
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
on the attacker machine. Now, the problem has shifted to the DNS query responses getting "destination unreachable (port unreachable)".
I KNOW I'm close, I'm just... not getting the pieces to line up correctly.
Trying dnsspoof instead.
Setting up an ARP Poisoning attack with bettercap...
$ dnsspoof -i wlan1 -f extrabacon.conf
Nope. Not working at all.
HTTPS sites have their DNS requests go through fine, as usual, and load in a reasonable amount of time.
HTTP sites either don't load at all (immediately breaking) or load eventually, without ever being DNS spoofed. Tried several entries in DNS conf file, for several HTTP and HTTPS sites. None were successfully DNS-spoofed.
I give up. I can't figure this out. Either some software bugs, or (more likely) some routing or firewall or network configuration or connection or something issues that I'm just not seeing.
About a year after I wrote this, kevin2k wrote me an email. It sez:
hi, you can add --httpd-port 80 to the command, because http server default port is 80.
Trying this again: Bettercap/DNS Spoofing Attack
man in the middle attacksin which an attacker tricks two parties into thinking they're communicating with each other, but both are communicating with the attacker.
Wireless Attacks: Man in the Middle/Wireless
Wired Attacks: Man in the Middle/Wired
Layer 1 and 2 MITM Attacks:
Network Tap: Man in the Middle/Wired/Network Tap
Layer 3 and 4 MITM Attacks:
ARP Poisoning: Man in the Middle/ARP Poisoning
Traffic Injection/Modification: Man in the Middle/Traffic Injection
DHCP Attacks: Man in the Middle/DHCP
WPAD MITM Attack: Man in the Middle/WPAD
Port Stealing: Man in the Middle/Port Stealing
Rushing Attack: Man in the Middle/Rushing Attack
Attacking HTTPS: Man in the Middle/HTTPS
Session Hijacking: Man in the Middle/Session Hijacking
Man in the Middle Labs:
Dsniff ARP Poisoning:
Bettercap ARP Poisoning: MITM Labs/Bettercap Over Wifi
Bettercap to Replace Images: MITM Labs/Bettercap to Replace Images
MITMf to Backdoor Browsers: MITM Labs/MITMf to Backdoor Browsers
Browser + Wireshark/SSLSniff to Decrypt HTTPS: MITM Labs/Decrypting HTTPS Traffic with Private Key File
Browser + Wireshark to Decrypt HTTPS: MITM Labs/Decrypting HTTPS Traffic by Obtaining Browser SSL Session Info
Bettercap to MITM Android Phone: MITM Labs/Bettercap Android EvoFlags · Template:MITMFlag · e