BackTrack 5: Advanced WLAN Attacks

Wireless Networks have become ubiquitous in today's world. Millions of people use them worldwide every day at their homes, offices, and public hotspots to log on to the Internet and do both personal and professional work.
We will cover the following:

• Man-in-the-Middle attack
• Wireless Eavesdropping using MITM
• Session Hijacking using MITM

Man-in-the-Middle attack

MITM attacks are probably one of most potent attacks on a WLAN system. There are different configurations that can be used to conduct the attack. We will use the most common one—the attacker is connected to the Internet using a wired LAN and is creating a fake access point on his client card. This access point broadcasts an SSID similar to a local hotspot in the vicinity. A user may accidently get connected to this fake access point and may continue to believe that he is connected to the legitimate access point.
The attacker can now transparently forward all the user's traffic over the Internet using the bridge he has created between the wired and wireless interfaces.
In the following lab exercise, we will simulate this attack.

Time for action – Man-in-the-Middle attack

Follow these instructions to get started:

1. To create the Man-in-the-Middle attack setup, we will first c create a soft access point called mitm on the hacker laptop using airbase-ng. We run the command airbase-ng --essid mitm –c 11 mon0:
   
   
2. It is important to note that airbase-ng when run, creates an interface at0 (tap interface). Think of this as the wired-side interface of our software-based access point mitm.
   
   
3. Let us now create a bridge on the hacker laptop, consisting of the wired (eth0) and wireless interface (at0). The succession of commands used for this are—brctl addbr mitm-bridge, brctl addif mitm-bridge eth0, brctl addif mitmbridge at0, ifconfig eth0 0.0.0.0 up, ifconfig at0 0.0.0.0 up:
   
   
4. We can assign an IP address to this bridge and check the connectivity with the gateway. Please note that we could do the same using DHCP as well. We can assign an IP address to the bridge interface with the command—ifconfig mitm-bridge 192.168.0.199 up. We can then try pinging the gateway 192.168.0.1 to ensure we are connected to the rest of the network:
   
   
5. Let us now turn on IP Forwarding in the kernel so that routing and packet forwarding can happen correctly using echo > 1 /proc/sys/net/ipv4/ip_forward:
   
   
6. Now let us connect a wireless client to our access point mitm. It would automatically get an IP address over DHCP (server running on the wired-side gateway). The client machine in this case receives the IP address 192.168.0.197. We can ping the wired side gateway 192.168.0.1 to verify connectivity:
   
   
7. We see that the host responds to the ping requests as seen:
   
   
8. We can also verify that the client is connected by looking at the airbase-ng terminal on the hacker machine:
   
   
9. It is interesting to note here that because all the traffic is being relayed from the wireless interface to the wired-side, we have full control over the traffic. We can verify this by starting Wireshark and start sniffing on the at0 interface:
   
   (Move the mouse over the image to enlarge it.)
   
10. Let us now ping the gateway 192.168.0.1 from the client machine. We can now see the packets in Wireshark (apply a display filter for ICMP), even though the packets are not destined for us. This is the power of Man-in-the-Middle attacks!
    
    (Move the mouse over the image to enlarge it.)
    

What just happened?

We have successfully created the setup for a wireless Man-In-The-Middle attack. We did this by creating a fake access point and bridging it with our Ethernet interface. This ensured that any wireless client connecting to the fake access point would "perceive" that it is connected to the Internet via the wired LAN.

Have a go hero – Man-in-the-Middle over pure wireless

In the previous exercise, we bridged the wireless interface with a wired one. As we noted earlier, this is one of the possible connection architectures for an MITM. There are other combinations possible as well. An interesting one would be to have two wireless interfaces, one creates the fake access point and the other interface is connected to the authorized access point. Both these interfaces are bridged. So, when a wireless client connects to our fake access point, it gets connected to the authorized access point through the attacker machine.
Please note that this configuration would require the use of two wireless cards on the attacker laptop.
Check if you can conduct this attack using the in-built card on your laptop along with the external one. This should be a good challenge!

Wireless Eavesdropping using MITM

In the previous lab, we have learned how to create a setup for MITM. Now we will look at how to do Wireless Eavesdropping with this setup.
The whole lab revolves around the principle that all the victim's traffic is now routed through the attacker's computer. Thus the attacker can eavesdrop on all the traffic sent to and from the victim's machine over wireless.

Time for action – wireless eavesdropping

Follow these instructions to get started:

1. Replicate the entire setup as in the previous lab. Fire up Wireshark. It would be interesting to note that even the mitm-bridge shows up. This interface would allow us to peer into the bridge traffic, if we wanted to:
   
   (Move the mouse over the image to enlarge it.)
   
2. Start sniffing on the at0 interface, so that we can monitor all traffic sent and received by the wireless client:
   
   (Move the mouse over the image to enlarge it.)
   
3. On the wireless client, open up any web page. In my case, the wireless access point is also connected to LAN and I will open it up by using the address: http://192.168.0.1:
   
   (Move the mouse over the image to enlarge it.)
   
4. Sign in with my password and enter the management interface.
   
   (Move the mouse over the image to enlarge it.)
   
5. In Wireshark, we should be seeing a lot of activity:
   
   (Move the mouse over the image to enlarge it.)
   
6. Set a filter for HTTP to see only the web traffic:
   
   (Move the mouse over the image to enlarge it.)
   
7. We can easily locate the HTTP post request, which was used to send the password to the wireless access point:
   
   (Move the mouse over the image to enlarge it.)
   
8. Next is a magnified look at the preceding packet:
   
   (Move the mouse over the image to enlarge it.)
   
9. Expanding on the HTTP header, allows us to see that actually the password we entered in plaintext was not sent as is, but instead, a hash has been sent. If we look at packet no 64 in the preceding screenshot, we see that a request was made for /md5.js, which makes us suspect that it is a md5 hash of the password. It is interesting to note here that this technique may be prone to a replay attack, if a cryptographic salt is not used on a per session basis in the creation of the hash. We leave it as an exercise for the user to find out the details, as this is not part of wireless security and hence beyond the scope of this article.
   
   (Move the mouse over the image to enlarge it.)
   
10. This shows how easy it is to monitor and eavesdrop on traffic sent by the client during a Man-In-The-Middle attack.

What just happened?

The MITM setup we created is now allowing us to eavesdrop on the victim's wireless traffic without the victim knowing. This is possible because in an MITM all the traffic is relayed via the attacker machine. Thus all of the victim's unencrypted traffic is available for eavesdropping for the attacker.

Have a go hero – finding Google searches

In today's world, all of us would like to keep what we search on Google private. The traffic on Google search is unfortunately over HTTP and plain text, by default.
Can you think of an intelligent display filter you could use with Wireshark to view all the Google searches made by the victim?

Session Hijacking over wireless

One of the other interesting attacks we can build on top of MITM is application session hijacking. During an MITM attack, the victim's packets are sent to the attacker. It is now the attacker's responsibility to relay this to the legitimate destination and relay the responses from the destination to the victim. An interesting thing to note is that, during this process the attacker can modify the data in the packets (if unencrypted and sunprotected from tampering). This means he could modify, mangle, and even silently drop packets.
In this next example, we will look at DNS hijacking over Wireless using the MITM setup. Then using DNS Hijacking, we will hijack the browser session to Google.com.

Time for action – session hijacking over wireless

1. Set up the test exactly as in the Man-in-the-Middle attack lab. On the victim let's fire up the browser and type in "google.com". Let us use Wireshark to monitor this traffic. Your screen should resemble the following:
   
   
2. Apply a Wireshark filter for DNS and as we can see, the victim is making DNS requests for "google.com":
   
   (Move the mouse over the image to enlarge it.)
   
3. In order to hijack the browser session we will need to send fake DNS responses which will resolve the IP address of "google.com" to the hacker machine's IP address 192.168.0.199. The tool we will use for this is called Dnsspoof and the syntax is dnspoof –i mitm-bridge:
   
   
4. Refresh the browser windows and now as we can see through Wireshark, as soon as the victim makes a DNS request for any host (including google.com), Dnsspoof replies back:
   
   
   (Move the mouse over the image to enlarge it.)
   
5. On the victim machine, we see an error which says "Connection Refused". This is because we have made the IP address for google.com as 192.168.0.199 which is the hacker machine's IP, but there is no service listening on port 80:
   
   (Move the mouse over the image to enlarge it.)
   
6. Let us run Apache on BackTrack using the following command apachet2ctl start:
   
   (Move the mouse over the image to enlarge it.)
   
7. Now once we refresh the browser on the victim, we are greeted with It Works default page of Apache:
   
   (Move the mouse over the image to enlarge it.)
   
8. This demonstration shows how it is possible to intercept data and send spoofed responses to hijack sessions on the victim.

What just happened?

We did an application hijacking attack using a Wireless MITM as the base. So what happened behind the scenes? The MITM setup ensured that we were able to see all the packets sent by the victim. As soon as we saw a DNS request packet coming from the victim, the Dnsspoof program running on the attacker's laptop sent a DNS response to the victim with the attacker machine's IP address as that of google.com. The victim's laptop accepts this response and the browser sends an HTTP request to the attacker's IP address on port 80.
In the first part of the experiment, there was no listening process on port 80 of the attacker's machine and thus Firefox responded with an error. Then, once we started the Apache server on the attacker's machine on port 80 (default port), the browser's requested received a response from the attacker's machine with the default It Works page.
This lab shows us that once we have full control of the lower layers (Layer 2 in this case), it is easy to hijack applications running on higher layers such as DNS clients and web browsers.

Have a go hero – application hijacking challenge

The next step in session hijacking using a wireless MITM would be to modify the data being transmitted by the client. Explore software available on BackTrack called Ettercap. This will help you create search and replace filters for network traffic.
In this challenge, write a simple filter to replace all occurrences of "security" in the network traffic to "insecurity". Try searching Google for "security" and check if the results show up for "insecurity" instead.

Finding security configurations on the client

We know how to create honeypots for open access points, WEP protected and WPA, but when we are in the field and see Probe Requests from the client, how do we know which network the probed SSID belong to.
Though this seems tricky at first, the solution to this problem is simple. We need to create access points advertising the same SSID but different security configurations simultaneously. When a roaming client searches for a network, it will automatically connect to one of these access points based on the network configuration stored on it.
So let the games begin!

Time for action – enumerating wireless security profiles

1. We will assume that the wireless client has a network Wireless Lab configured on it and it actively sends Probe Requests for this network, when it is not connected to any access point. In order to find the security configuration of this network, we will need to create multiple access points. For our discussion, we will assume that the client profile is either—an open network, WEP protected, WPA-PSK or WPA2-PSK. This would mean we would have to create four access points. To do this we will first create four virtual interfaces—mon0 to mon3 using the airmon-ng start wlan0 command multiple times:
   
   
2. You could view all these newly created interfaces using the ifconfig –a command:
   
   
3. Now we will create the Open AP on mon0:
   
   
4. Let's create the WEP-protected AP on mon1:
   
   
5. The WPA-PSK AP will be on mon2:
   
   
6. WPA2-PSK AP will be on mon3:
   
   
7. We can run airodump-ng on the same channel to ensure all the four access points are up and running as shown:
   
   
8. Now let's switch the Wi-Fi on, on the roaming client. Depending on which Wireless Lab network you had connected it to previously, it will connect to that security configuration. In my case, it connects to the WPA-PSK network as shown below.
   
   

What just happened?

We created multiple Honeypots with the same SSID but different security configurations. Depending on which configuration the client had stored for the Wireless Lab network, it connected to the appropriate one.
This technique can come in handy as if you are doing a penetration test, you would not know which security configurations the client has on its laptop. This allows you to find the appropriate one by setting a bait for the client. This technique is also called WiFishing.

Have a go hero – baiting clients

Create different security configurations on the client for the same SSID and check if your set of Honeypots is able to detect them.
It is important to note that many Wi-Fi clients might not actively probe for networks they have stored in their profile. It might not be possible to detect these networks using the technique we have discussed here.

Summary

In this article, we have learned how to conduct advanced attacks using wireless as the base. We created a setup for a MITM over wireless and then used it to eavesdrop on the victim's traffic. We then used the same setup to hijack the application layer of the victim (web traffic to be specific) using a DNS poisoning attack.

---