This article is intended to provide a simple demonstration of how easy it is to sniff/intercept traffic on various types of networks, and serve as a warning to utilize secure methods of communication on a) untrusted networks and b) known networks with the potential for untrusted clients or administrators.
The first consideration is the topology of the network we’re connected to. To consider 5 common scenarios:
Wired ethernet hub network: Hubs are becoming more and more obsolete as they are changed to switches. Multiple devices can be connected to a hub, and any data received by the hub from one device is broadcast out to all other devices. This means that all devices receive all network traffic. Not only is this an inefficient use of bandwidth, but each device is trusted to accept traffic destined for itself and to ignore traffic destined for another node. To sniff such a network, a node simply needs to switch it’s network interface card to “promiscuous mode”, meaning that it accepts all traffic received.
Wired ethernet switched network: Multiple devices can be connected to a switch, however a switch has greater intelligence than a hub. The switch will inspect the traffic sent on each port, and learn the hardware (MAC) address of the client connected to a particular port. Once learned, the switch will inspect any frames it receives on a port, and forward that frame to the known recipient’s port alone. Other devices connected to the switch will not receive traffic that is not destined for them. This offers enhanced bandwidth usage over a hub. Switches rely on ARP packets which are easily forged in order to learn which devices are on which ports.
Wireless open networks: Multiple devices can connect to an open wireless network. All data is broadcast across the network in plain text, and any attacker can sniff/intercept traffic being broadcast across the network. An open wireless network may present the user with a form of hotspot login page before granting internet access, however this does not detract from the network itself being open.
WEP encrypted wireless network: A WEP encrypted network requires a WEP key to encrypt and decrypt network traffic. WEP has long been an outdated and insecure method of wireless network protection, and cracking a wireless network’s WEP key is fast and requires low skill. WEP is not secure. In addition, all clients connected to the network use the same WEP key to connect. That results in any user on the network with the WEP key being table to view any traffic transmitted to and from other nodes on the network.
WPA/WPA2 encrypted network: A WPA/WPA2 encrypted network is significantly more secure than a WEP network. Whilst attacks exist on parts of the protocol, and extensions such as WPS, no known attack is able to recover a complex WPA/WPA2 password within an acceptable period of time. Whilst all clients connect to the network with the same password, the protocol is engineered to create different keystreams between each connected client and the access point. This means that simple sniffing in the traditional sense is not possible on the network.
Now to look at some of the network attacks that can be leveraged in the above scenarios:
Switches maintain a table of MAC addresses, and once this table is full, some switches will revert to hub activity. This allows an attacker to fill the MAC address table with bogus information via spoofed ARP packets, forcing the switch to act as a hub at which point traffic can be sniffed. Another attack involves flooding the switch with ARP packets, claiming that an existing node’s MAC address is in fact on the port that we are connected to. This causes traffic originally destined for the legitimate node to be directed to our switch port allowing us to intercept it. This type of attack can be mitigated using “port security”, where the switch is either manually configured with allowed MAC addresses on each port, or it is set to learn the first MAC address on the port that it receives and refuse to accept other conflicting ARP packets. ARP spoofing applies to wireless and wired networks equally.
Most networks are configured to use DHCP which allows each node to dynamically gain its network configuration settings from a server on the fly. Setting up a rogue DHCP server is trivial, most commonly instructing the nodes to use a malicious gateway that intercepts traffic. This type of attack can be mitigated using “DHCP snooping”.
Wireless clients can communicate with each other, and therefore a malicious client can launch attacks against other clients on a wireless network. This type of attack is mitigated by utilizing “client isolation” – this is typically implemented by the access point intercepting ARP requests for other IPs on the network and responding with it’s own MAC address. This prevents clients on the network from communicating with each other – they are only permitted to communicate with the access point.
Although WPA/WPA2 networks prohibit simple sniffing, ARP spoofing is a common technique to intercept traffic on such networks.
It’s important to reiterate that “secured” networks such as WPA/WPA2 are only secure for the user as far as they trust other users on the network, and the network operator. For that reason an encrypted VPN tunnel or restricting all traffic to encrypted rather than plaintext protocols is essential.
Let’s get into an example: sniffing traffic on a WPA2 network. Unauthorized subversion of traffic on a network is illegal, and so this demonstration was performed on a private test network.
First, we need to connect to the WPA2 network using wpa_supplicant. I created a sample configuration in /etc/wpa_supplicant/test_network.conf containing my network name and PSK (password). wpa_supplicant has a number of configuration options. The most simple configuration is as follows:
Now, to connect to the network:
Once connected, I gain an IP address using dhclient:
I’m assigned an IP of 192.168.2.120/24 with a gateway of 192.168.2.1. Running tcpdump -i wlan0 -n shows sporadic network broadcasts, but nothing of interest. This makes sense, as per the above explanation all connected clients are communicating with the access point using different keys and therefore I am unable to decrypt their traffic. Instead, if I use ARP spoofing to claim the MAC address currently assigned to the router (192.168.2.1), clients will begin routing their internet bound traffic to my node. Before doing so, I will need to enable IP forwarding, allowing my node to forward the clients traffic out to the legitimate gateway, allowing them to continue accessing the internet:
arpspoof immediately begins sending ARP packets to the network, instructing nodes that the router 192.168.2.1 is found at the MAC address of my own wireless adapter wlan0.
Let’s now use tcpdump again to view any HTTP traffic on the network in ASCII format:
tcpdump soon begins providing output:
We can see that we’ve caught an HTTP request to google.com, including the full cookie data. An attacker could then hijack and replay that cookie to impersonate our session.
It’s easier to view and filter traffic visually using Wireshark:
Wireshark has been started and is listening on wlan0 whilst arpspoof continues to run. I’ve set a filter of http.host contains “google.com” to show HTTP traffic where the Host header matches google.com.
Now to view the stream, we right click on a packet and click “Follow TCP Stream”:
Wireshark now presents us with the entire TCP conversation. Different filters can be set to filter out IMAP or POP3 traffic for example. This attack was conducted on a WPA2 network using ARP spoofing, and can be easily applied to the other network scenarios described above unless adequate precautions are taken.
More advanced attack options
Firesheep is a browser plugin that demonstrates HTTP session hijacking and highlights the insecurities of using unencrypted protocols on open networks.
The scenario above can be extended by using iptables to redirect outbound traffic through application proxies running on our malicious host. sslstrip by Moxie Marlinspike acts as an HTTP proxy server that parses HTML and converts any HTTPS links to HTTP – its intention is to force unaware users to browse HTTP versions of sites rather than the encrypted HTTPS version. iptables would be used to redirect outbound traffic through sslstrip
Fake local services could be run and have traffic redirected through them in the same way as sslstrip above to present users with fake inboxes and email scenarios for example.
Lastly, an intercepting HTTPS server could be utilized that generated fake, self-signed certificates given the host name being requested. Users on the network would be presented with an SSL warning indicating that the certificate was not signed by a trusted CA, however many users would blindly accept and continue, not understanding the implications of the warning and simply wanting to access the desired remote site.
The best advice for staying secure on untrusted networks is a) using an encrypted VPN tunnel to a trusted remote host with both client and server side validation, and b) using encrypted protocols such as HTTPS, IMAPS, POP3S and SMTPS. It’s crucial not to accept SSL warnings without a thorough understanding of the situation and why the message has arisen.