An Old Trick for a New Dog WiFi and MITM (Winter, 2004-2005) ------------------------------------------------------------ by uberpenguin If you are reading this magazine, it is probably safe to assume you are familiar with the concept of a man-in-the-middle attack (which from here will be referred to as MITM for brevity) as it pertains to networking resources. In this article I hope to point out how this old and well known concept can be applied to an 802.11 WiFi network. I will use a case study of a fairly large wireless network I have access to in order to illustrate a possible scenario of a WiFi MITM attack. The Network First, let's establish that gaining access to the network is not going to be discussed here. In my case study I already had legitimate access to the network and formulated my scenario from the point of view of one of the numerous persons who also have access to this wireless network. I will not talk about the mundane technical details of the software setup; that is out of the scope and interest of this article. A general description of the wireless network setup follows. The network in question consists of numerous access points placed throughout a large area that includes both indoor and outdoor coverage. Each access point is "dumb." That is, it simply acts as a bridge between a wired and wireless network and nothing else. The wireless APs are set up with all the reasonable precautions: ESSID broadcasting turned off and WEP. The wired network that all the APs connect to is separate from the rest of the facility's networks. A single gateway is the bridge between the wireless system (including the wired network of all the APs as well as the wireless clients that connect to them) and the rest of the network resources. This gateway also acts as the DHCP server for all the wireless clients. The gateway uses a common MAC-based authentication method that requires you to log in using your user ID and password before it will allow access to the rest of the network. This login form is secured using 256-bit AES encryption that is signed by a large CA. (As we shall see later, this proves to be the most foolproof part of the system.) As you can see, the network is set up with every sensible measure that can be implemented with a non-homogeneous network (hardware, OS, or otherwise). However there are still problems. The Scenario The basic concept that this scenario considers is that of DHCP operation. For those of you not familiar, a DHCP client sends a broadcast packet to the network requesting DHCP service. It will then wait for the first DHCP server that responds to the request with configuration information; resending the DHCP broadcast if necessary. Here is where we zero in on the key phrase "first DHCP server." The DHCP client will use whatever information it first receives and ignore all subsequent DHCP responses. Thus we have the basis for our scenario. In our hypothetical setup, we have four important components: a firewall that can perform routing functions, a DNS server, a DHCP server, and an HTTP server (and a WiFi card that works with whatever 802.11 standard is being used obviously). All of these components are readily available for most Free *nix systems. The idea is to set up a clone of the "real" gateway that bridges the wireless system to everything else. Depending on where a person is physically located in relation to clients, the clone DHCP server may be able to send a response to a given DHCP request more quickly than the real gateway can. To affect a larger number of wireless users, one would merely need to change their physical location. After a client has received the alternate DHCP information and attempts to access a network resource (in this case, an HTTP resource), the normal behavior of the real gateway is mimicked. Specifically, this entails redirecting the user to a secure login page hosted on the gateway. Herein is the largest flaw in this attack, one whose effects will be discussed shortly. There is no good way to forge a secure certificate. We can replicate the normal behavior of the real gateway in every way, down to its domain name thanks to our DNS server. But the false login page will have to be insecure, unlike the real one. Here we must have faith in the ignorance of Joe WiFi User. Even a security-conscious person such as myself can neglect checking the authenticity of a host that is supposed to be secure. In a rush to do other things, one can just quickly log in to the gateway not giving a moment's thought to the security risk they just took. That fact is what makes all of this possible; otherwise the secure login would be a show-stopper. By now I am sure the reader has ascertained where this scenario is headed. Presented with a familiar login form, Joe WiFi User enters his userID and password and presses Submit. Of course our faux gateway will log him into the real gateway, passing along the values to the real HTTP server for processing and observing the result. However, upon recognizing a successful authentication routine, the script will log this userID and password combo. MITM attack successful. The Conclusion of the Matter Let's briefly consider the "flaws" in this scenario. Obviously this setup will not go undetected for long. Upon realizing that the login page being presented is insecure, any savvy user will immediately realize something is wrong and (hopefully) report it to whomever is responsible for maintaining the wireless system. The administrators will quickly be able to spot an unauthorized DHCP server and the traffic it generates. Most cards allow overriding of their built-in MAC address, so tracking the offender may not be easy. However, the network admins will at least be able to figure out general physical location of the fake gateway by determining which access point it is using for its own network connectivity. By changing location and hardware addresses, however, one could likely keep up this routine for a while without being caught. As mentioned in the network description, the wireless APs in my case study do not perform any network functions other than bridging the wired and the wireless. If these APs were given some packet forwarding and firewall functionality, they would be able to enforce rules on allowable DHCP packets and possibly eliminate the MITM problem described in this article. Another possibility for eliminating this sort of vulnerability is a bit of password trickery using RSA's SecurID system. Obviously this requires a fair monetary investment, but it is a valuable one for any large-scale wireless network. Yet another suggestion I have heard is using Windows' Active Directory policies to disallow DHCP configuration from any hosts that are not specified in a trusted list. Of course, this is only an option in a homogeneous (Microsoft) OS environment where the desktop software can be somewhat controlled. This is not the case in the network I have been describing, but it could be in other cases. Perhaps the best tradeoff that can be used to minimize the vulnerability is enforcing a strict password policy for the gateway. In my case study network setup, the userID and password used to authenticate with the gateway is the same one that is used for most other computing services. This account is meant to protect quite a bit of sensitive data, including and not limited to financial and administration information. The conclusion we are forced to make, therefore, is that our wireless network is to be treated as wholly insecure. The case study does take that stance for the most part, but a crucial detail was overlooked when important user accounts were allowed to be used for WiFi authentication. Ideally users would use a totally different userID and password to log into the gateway, or at least a different password. Doubtlessly, the users would be unhappy, but that is a small price to pay for the added security. These accounts would no longer be so useful that someone might want to go through all the trouble of collecting them. All they do is give you access to the network itself rather than all the resources on the network. Above all else, I believe this article demonstrates the extreme necessity of emphasizing to end users the importance of verifying that they are connected securely to the gateway before attempting to log in. Remember that this entire scenario relies on most users not realizing what is happening. While it cannot be reasonably expected for every WiFi user to become network competent, a little bit of knowledge can go a long way in improving your wireless security. Many thanks go to aydiosmio and openfly for their help in exploring the possibilities of this idea.