Bettercap/Failed DNS Spoofing Attack 2: Difference between revisions
From charlesreid1
| Line 66: | Line 66: | ||
Well duh, it's my firewall rule. All the packets going through port 80 are being redirected to port 8081. | 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. | |||
Revision as of 05:18, 25 August 2016
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.
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.
Packet Traffic
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, 8.8.8.8
- Google public DNS server responds to attacker with 170.149.159.130
- 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.
Firewall
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.