MITM Labs/Dsniffing Over Wifi

Lab Overview

Scenario

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.

Setting Up

Wifi Network

This will use a standard wifi network that both the sheep and attacker can connect to. They should be on the same subnet.

Sheep

Sheep will be generating web/ssh/email/dropbox traffic. The sheep needs basic programs to do that stuff.

Attacker

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.

Other tools?

Execution

Plan

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 -A flag:

$ 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.

Error

$ 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.

Failure

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.

Debrief

Failure

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?