The wireless medium is inherently susceptible to man-in-the middle attacks. Whether the objective of such an attack is to capture traffic, or simply make an “evil” access point more believable by connecting clients to the Internet, there are a few different approaches one can take to inserting themselves between their target(s) and the Internet.
This post explores two of those methods. The first (and quicker) option assumes your attack box is virtualized on a host with its own wireless connection. The second option is suitable for (but not exclusive to) attack boxes running as physical machines. Though both approaches would work with a wired Internet connection, the focus here is on wireless and the mobility and flexibility it affords. Both examples use hostapd (specifically, hostapd-wpe) for the evil access point. For instructions on getting that up and running, check out our post here.
Technique 1: Virtual Machine Attack Box – Bridging eth and wlan
What you need:
- A host operating system with an internet connection
- A virtualized operating system with which to conduct the attack – this example uses VMWare Workstation and Kali 2.0
- A wireless card that supports Master (AP) mode – this example uses the TP-Link TL-WN722N
- A functioning installation of hostapd-wpe (or vanilla hostapd for non-enterprise authentication)
Start up the virtual machine, ensuring that the network adapter is set to “Bridged.” In VMware Workstation, that looks like this:
The “Replicate physical network connection state” means that the virtual adapter will be updated as the host machine’s connection changes (for instance, moving from a wired to wireless network). In general that setting probably won’t be necessary in these attack scenarios, in which the host machine’s Internet connection is likely to remain consistent for the duration of any given attack.
Without any other configuration effort, the bridged host machine’s connection should show up as eth0 in Kali 2. Though this should “just work,” ensure you are pulling an IP and test connectivity before moving further.
With eth0 providing the outbound connection, it can be added to a bridge which will be included in the hostapd-wpe configuration file. Kali 2.0 doesn’t come with the bridge-utils package by default, so install it by running the following:
apt-get install bridge utils
Once installed, use bridge-utils to add a bridge interface (here br0), then add eth0 to that interface.
brctl addbr br0
brctl addif br0 eth0
ifconfig br0 up && ifconfig eth0 up
With the bridge created, it simply needs to be included in a functioning hostapd-wpe configuration. Here’s an example configuration for a WPA2 Enterprise access point that includes the bridge:
#hostapd-wpe configuration file for TheWarRoom
interface=wlan1
bridge=br0
ssid=Employee-Network
channel=6
eap_user_file=<path to hostapd-wpe.eap_user>
ca_cert=<path to ca.pem>
server_cert=<path to server.pem>
private_key=<path to server.pem>
private_key_passwd=password
dh_file=<path to dh>
eap_fast_a_id=101112131415161718191a1b1c1d1e1f
eap_server=1
eap_fast_a_id_info=hostapd-wpe
eap_fast_prov=3
ieee8021x=1
pac_key_lifetime=604800
pac_key_refresh_time=86400
pac_opaque_encr_key=000102030405060708090a0b0c0d0e0f
wpa=1
wpa_key_mgmt=WPA-EAP
wpa_pairwise=TKIP CCMP
The screen capture below shows hostapd-wpe’s output with an authentication and association involving the passage of credentials. Bridging connections gives you a two-for-one, because not only have you captured credentials, but now you are capturing traffic, which might provide other information on or insight into your target.
Below is the connection from the target’s perspective. Notice the assignment of an IP address consistent with the network to which eth0, on the attack box’s host OS, is connected. From the victim’s perspective, this is all fairly seamless (if a little slower), and only becomes obvious if there are certificate issues or they are unable to reach resources they expect to have access to (for instance, if they believed themselves to be connecting to the corporate Wi-Fi when you’re actually bridging them to the guest network).
 |
 |
Once a client is connected, sniffing with Wireshark or tcpdump on the bridge interface will allow you to capture and analyze the client’s traffic as it flows through your machine.
Technique 2: Physical Machine Attack Box – IP Forwarding
What you need:
- A physical machine attack box – this example uses Kali 2.0
- A working internet connection (e.g. onboard or USB wireless)
- A wireless card that supports Master (AP) mode – as above, this example uses the TP-Link TL-WN722
- Again, a functioning installation of hostapd-wpe (or vanilla hostapd for non-enterprise authentication)
This technique requires a little more configuration, but is ultimately more flexible and powerful. It also obviates the need for a virtual machine, which may be more appropriate for some setups.
Since we’re conducting wireless attacks, we’ll start by removing any interference:
airmon-ng check kill.
This convenient script, which is included with the aircrack-ng suite in Kali, checks for and kills processes known to conflict with management of wireless interfaces, such as NetworkManager (which attempts to automate network connections) and wpa_supplicant (a client for wireless connections). Processes such as these get in the way of hostapd, and without killing them it’s likely you’ll receive an error when trying to initiate your evil AP.
Though killing interfering processes will help hostapd, it also means you’ll need to manually connect to a wireless network (for instance, guest Wi-Fi) to provide an outbound Internet connection for clients that connect to your machine. Luckily, wpa_supplicant makes this fairly painless.
To connect to an open wireless network using wpa_supplicant first create a profile with the SSID of the network to which you are connecting (case-sensitive) and the “key_mgmt=NONE” parameter, which signifies an open network. The profile format looks like this:
network={
ssid="Guest-Network"
key_mgmt=NONE
}
The default location for wpa_supplicant configuration files is /etc/wpa_supplicant/<profile name>.conf. With the configuration file created, pass it to wpa_supplicant along with your interface and driver. The ‘-d’ parameter increases the output verbosity:
wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/Guest-Network.conf -D nl80211 -d
If this is successful, you’ll see “CTRL-EVENT-CONNECTED” in the wpa_supplicant output. You can verify that you are associated to the network by checking iwconfig, but to pull an IP address you’ll have to poll the DHCP server:
dhclient wlan0
If everything is successful, you should be able to browse the Internet using that connection as you normally would. However, wpa_supplicant is only controlling the designated interface (not your evil AP interface) and there is no pesky NetworkManager to contend with.
With this approach we’ll manage DHCP for our clients rather than passing it off to the open network. Install dnsmasq, which describes itself as a “lightweight DNS, TFTP, PXE, router advertisement and DHCP server.” Clearly its capabilities extend beyond DHCP, which is what makes this approach more flexible, but for the purpose of this post we’ll simply get up-and-running with the basic DHCP capabilities:
apt-get install dnsmasq
If you haven’t already, plug in the wireless card which will act as your evil access point, as it will be the interface through which we assign IP addresses to connecting clients. Assign that card an IP address that will function as a gateway and correspond with your dnsmasq settings below:
ifconfing wlan1 172.16.10.1 && ifconfig wlan1 up
dnsmasq can be run from the terminal or as a service. By default it will use parameters defined in a configuration file located at /etc/dnsmasq.conf, but these parameters can be passed in the command line as well. If a configuration file exists, be sure any parameters you pass in the command line do not conflict with those in the configuration file. For very basic usage, run:
dnsmasq --interface wlan1 --dhcp-range=172.16.10.10,172.16.10.50,12h --log-queries
This runs dnsmasq on the designated interface and specifies the range of addresses that will be assigned, along with a 12 hour lease time. With –log-queries enabled, events, such as address assignments and DNS queries, will be logged to /var/log/dnsmasq.log. This is, of course, a useful place to look for troubleshooting any issues.
At this point we have a functioning outbound connection and a DHCP server for clients, but the two interfaces are not connected, nor is the AP functioning. Use iptables to forward traffic from your evil AP interface (wlan1 in this example) to your legitimate outbound connection (wlan0).
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
iptables -A FORWARD -i wlan1 -o wlan0 -j ACCEPT
echo '1' > /proc/sys/net/ipv4/ip_forward
The first command adds a rule to the NAT table, essentially enabling NAT on the outbound interface, which is acting as the gateway for your victims. MASQUERADE is used in situations where the interface receives its IP address dynamically, as opposed to S(tatic)NAT, in which you specify the outbound address. All packets flowing through your host will appear to come from its IP address. The second command forwards traffic from the evil AP interface out your legitimate connection, setting ACCEPT as the default policy for all traffic coming in to wlan1. Finally, writing “1” to ip_forward tells the Linux kernel that IP forwarding is enabled.
With the necessary configurations made, launch hostapd to attract clients, assign them an IP address, and let them browse the internet. Sniff with Wireshark or tcpdump on the evil AP interface (wlan1 in this example) to view traffic generated by the connected clients:
Remember that dnsmasq provides a lot more capabilities than just dynamically serving IP addresses, such as DNS spoofing, which you could use to redirect traffic intended for specific sites. Furthermore, though this approach involves some configuration, it could easily be scripted for faster execution in the future.
Finally, remember there are more ways to go about this, and the tools and techniques listed here aren’t mutually exclusive. Explore what’s out there to suit your specific operational needs. Happy hunting.
digby sends.
