MITM Labs/Dsniffing Over Wifi
- 1 Lab Overview
- 2 Execution
- 3 Debrief
- 4 Flags
The scenario for this laboratory is an attacker and a sheep using laptops on the same wireless network. The goal here is to sniff the sheep's traffic over the network using Dsniff. Let's talk about what Dsniff does and does not do.
The Dsniff suite provides tools that read network traffic and search for interesting information/credentials - that's it. That means that we (the attacker) need to be able to read the sheep's network traffic before we can use Dsniff.
How we read the sheep's traffic depends on the type of network we're on.
- Wired networks: Man in the Middle/Wired
- You must determine whether you're on a network switch or a network hub
- Network switches selectively broadcast traffic from the gateway to the specific port corresponding to the intended destination node (this is determined using the ARP table, which maps MAC addresses to ports)
- Network hubs broadcast all traffic to all ports, so all traffic is visible to all nodes, and nodes simply ignore traffic not intended fro them
- Wireless networks: Man in the Middle/Wireless
Notes on Detection
It is important to note the impact that an ARP spoofing attack will have on the network. ARP spoofing generates a MASSIVE amount of packet traffic, so it WILL slow down the network. Also, if it is an enterprise or business network, or any network with an active IT crew, they will almost surely be alerted to the attack. This is optimal for anonymous, small, unmonitored networks.
This will use a standard wifi network that both the sheep and attacker can connect to. They should be on the same subnet.
Sheep will be generating web/ssh/email/dropbox traffic. The sheep needs basic programs to do that stuff.
To carry out the ARP poisoning attack, the attacker will need an ARP poisoning tool - this lab will use Arpspoof, part of the Dsniff suite.
To actually sniff the traffic, the attacker will need Dsniff.
The attack steps are as follows:
- Perform recon/information gathering
- Prepare for ARP poisoning attack (packet forwarding, network interfaces, etc.)
- Run ARP poisoning attack to poison ARP tables of sheep and of router
- Run Dsniff to capture goodies
- Browse some plaintext activity/upload some files on the sheep, see what you get on the attacker machine
Step 1: Recon/Info Gathering
The ARP poisoning attack requires us to be on the same subnet as our victim. If this is a foreign network, there are a couple of things we might want to know about it:
- How many other clients are there on the network?
- What is the volume of traffic on this network?
- Is this network administered? What is the potential the network is monitored?
- What kind of network router/other hardware is present?
If we're on a network like 192.168.0.* we can get a very quick picture of what other computers are on the network by doing a fast scan, or by scanning a particular port:
$ nmap -F 192.168.0.*
If you want more detailed information about the types of devices that are running, what operating systems, etc, you can run with the
$ nmap -A 192.168.0.*
With this type of Nmap scan, it is possible to discover the following information:
- Router manufacturer from MAC address lookup
- Service information and operating system
- Open ports on router/sheep
- Other potential attack vectors
Step 2: Prepare for ARP Poisoning
First, keep in mind the disclaimer section on Man in the Middle/ARP Poisoning page. This will generate lots of network traffic and be very loud packet-wise.
Gather required information
You'll want to pick out your sheep target and the gateway router, and record the MAC address and IP of each. Here's the configuration for my laboratory:
Role IP Example MAC Gateway 192.168.0.1 11:11:11 Sheep 192.168.0.7 22:22:22 Attacker 192.168.0.8 AA:AA:AA
Set up packet forwarding
When we carry out the ARP attack, we're confusing nodes on the network about which physical computer corresponds to which IP address. It's important that we keep traffic moving, however, or else the entire network will come to a grinding halt. We can do this by forwarding packets. That means that when the gateway sends a packet intended for the sheep, and it gets to the attacker instead, the attacker's network card will simply forward the packet along.
echo 1 > /proc/sys/net/ipv4/ip_forward
(This simply changing the value of the file from 0 to 1)
Change your MAC
Important: change the MAC address of the wireless interface you're using to connect to the wireless:
$ ifconfig wlan1 down $ macchanger -r wlan1 $ ifconfig wlan1 up
Step 3: ARP Poisoning Attack
What we're doing is, we're contaminating the ARP tables on the Gateway and the Sheep, so that the Gateway thinks the Sheep is at AA:AA:AA, and the Sheep thinks the Gateway is at AA:AA:AA. The ARP attack is carried out by crafting fake ARP request responses (information that neither the Gateway nor the Attacker asked for). An ARP Poisoning attack floods the network with fake ARP requests - some say "Hello, whoever wanted to know where the gateway 192.168.0.1 is, it's at AA:AA:AA" and some say "Hello, whoever wanted to know where the sheep 192.168.0.7 was, it's at AA:AA:AA". Eventually all the computers that get these fake ARP request responses will put that information into their ARP table.
Use the arpspoof utility. This one's really dead simple to use. Get some help:
$ arpspoof -h
Basically we specify the interface we're using, the target, and the gateway/destination: the same info we recorded from Steps 1 and 2 above.
Start Wireshark on the Sheep machine to watch the ARP poisoning attack's flurry of packets in action.
Connect with the wireless network with your interface (wlan1 in this case).
$ arpspoof -i wlan1 -t 192.168.0.7 -r 192.168.0.1
This generates lots of output, so you can also pipe all the output to /dev/null:
$ arpspoof -i wlan1 -t 192.168.0.7 -r 192.168.0.1 &> /dev/null
Output like this means your interface is not connected to the network:
$ arpspoof -i wlan1 -t 192.168.0.7 -r 192.168.0.1 arpspoof: couldn't arp for host 192.168.0.7
When you run the program, the output will inform you of each faked ARP reply packet that is sent out: it will specify the MAC the faked ARP response was sent to, and what the faked ARP response says.
$ arpspoof -i wlan1 -t 192.168.0.7 -r 192.168.0.1 &> /dev/null $ arpspoof -i wlan1 -t 192.168.0.1 -r 192.168.0.7 &> /dev/null
Step 4: Run Dsniff
Like arpspoof, dsniff is very simple to run. Get some help:
$ dsniff -h $ man dsniff
We will specify the interface, an output file, and any other options. A few useful flags:
-c Perform half-duplex TCP stream reassembly, to handle asymmetrically routed traffic, like when using arpspoof to intercept client traffic bound for local gateway -p pcapfile Process results of capture offline
here's the final dsniff command that you can run to sniff for plaintext goodies:
$ dsniff -i wlan1
It's probably better to run this specifying an output file:
$ dsniff -i wlan1 -w goodies.txt
but this is not working. The output file has a line in it after I log in, but I can't actually show or display the credentials in the file, and they're encoded.
Step 5: Sheep Does Stuff and We Capture Booty
On the attacker, monitor traffic (adjust this with some filters, so it doesn't spew):
$ tcpdump -i wlan1
On the sheep, you should also be running Wireshark.
Now visit a site that doesn't implement https, like the NYTimes. Log in while monitoring dsniff.
Nope. Logging in with insecure nytimes.com login page on the sheep. MITM traffic passing through attacker. dsniff running. But absolutely zero results shown in the output.
Not exactly sure why this attack failed.
The services I use day-to-day, and most websites of Fortune 1000 companies, use HTTPS. A decade or so ago, when the dsniff toolkit was more popular, HTTPS was much less common and only used for websites that really needed it, like banks. Due to the rise of tools like dsniff, and more powerful computers, encryption is not such a computational burden, so HTTPS is more commonly deployed.
Not sure how far this type of attack will take you if your aim is to monitor traffic - missing HTTPS traffic means missing most (if not all) of the interesting traffic. However, many insecure apps and web pages are still slow to jump on the HTTPS bandwagon, and a simple experiment with Firefox's "HTTPS Everywhere" extension can quickly reveal sites that do not implement HTTPS at all, or at least do not implement it by default.
Sheep Experiences The Slows
The sheep experiences a very slow wifi connection - to the point where it's clear something fishy is happening. The sheep will either lose their patience or attempt to reconnect to the wifi, causing the entire attack to have to start again.
Looking at the packets, I see ah unge number of TCP retransmissions, missing ACK packets, and so on, so the requests are simply getting lost en route and/or droppd.
Possible to look into this? What's causing TCP Dup ACK/TCP Suprious Transmission/TCP ACK unseen segment/etc...
Increase packet transmission rates?
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