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.
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
System Profiles
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 |
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 |
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 |
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 passwordtoor
- Run iwconfig to find out the name of your wireless card on the system, this is usually something like
wlan0
orwifi0
, 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 iswifi0
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 passwordtoor
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) modulemodprobe 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 caseath0
. 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 byairbase-ng
when it is run, usingairtun-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 ourdhcpd.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