The 802.1x protocol had experienced a number of vulnerabilities when the industry decided to adapt it to wireless. The protocol was originally used for wired port-based authentication, not wireless. These vulnerabilities came about from the initial thought that all network equipment would be physically secure, locked into a rack inside a telecommunication closet or data center. All the user would see and connect to was a wall jack. That wall jack could most likely be considered secure, and a general understanding that it is connected to a company switch and only a company switch. In the wireless world, this determination cannot be made because the access points are placed throughout a facility and clients can connect from wherever there is an access point sending signal. This means the existence of rogue access points set up by attacks is a real threat. Some way to validate that the access points are those belonging to the company was needed. When the 802.1x protocol was created, this thought process was never taken into consideration, and a validation step to ensure that users connected to the correct piece of networking equipment was never created in the standard. As of today, the 802.1x standard along with the EAP standard have made a number of modifications to better accommodate wireless communications.
Because of the issue of allowing any piece of network equipment to communicate with an authentication server, a lot of man-in-the-middle attacks occurred. Many groups, schools, and companies produced research papers outlining this vulnerability. The general 802.1x vulnerability is achieved by setting up a rogue access point and getting clients to authenticate to this rogue access point. When these clients connected and passed their credentials, the attacker would use those credentials to connect to the actual network.
When looking at this in relation to current-day wireless systems and clients, one notices that Windows XP has a built-in ability to connect to a network on its own. Service Pack 2 updated the wireless configuration tool on Windows XP and allowed for more manageability for wireless connections. Even with the service pack two, wireless client cards will automatically connect to networks. This means that Windows users are using the default wireless configuration tool and they can easily be swayed off their access point and onto the one an attack controls.
Let us now walk through a real-world example of how to compromise an MS PEAP 802.1x wireless network. An attacker will need to find a target that is using an 802.1x wireless network. For this example, let us assume that the victim is running 802.1x with MS PEAP. This is one of the more common architectures used today because of the cost savings of using an existing MS server, and the savings connected with not deploying a PKI has often led companies down this road.
Getting back to the attack scenario, the first step is to find the network. To do this, an attacker can war drive around until he stumbles upon a network or use some information-gathering technique (discussed previously). For this example, the attacker has his eyes set on a single company. As the first step, the attacker war drives past the building to see if it has any wireless networks. This has proven valuable in letting the attacker know for sure that a wireless network exists at the target location.
The next part of the process involves sniffing the airwaves to find the SSID and making sure that the network is using MS PEAP with 802.1x. An attacker can sniff the network in two ways. One way is to set up a long-range directional antenna such as a yagi. With this, an attacker can sit completely out of sight of the physical security guards. With this, he can point the yagi attached to his laptop toward the building and sniff the airwaves. The other way is much more risky but just as easy. The attacker could just walk right in the door ask the person at the front desk about using the restroom or inquire about a job. All the while, the attacker could have a PDA in his pocket capturing packets and integrating the company’s network with a number of wireless tools. Next, the attacker will try to find the SSID. This is easy, although some 802.1x deployments encrypt the management frames. This might pose a problem; however, today, even with certain implementations where management frames are encrypted, all probe requests and probe responses will have a cleartext easy-to-read SSID.
So now the attacker has found the SSID. What is he then going to do? First, he needs to set up a server and an access point to use as a rogue device. The server needs to run on a laptop for portability; it also needs to run the following services: DHCP, DNS, and Web Server. This server could also be set up with one of the many hotspot authentication programs available and will provide this functionality for the attacker in a single software package. Next, the attacker will need to set up the access point to use the same SSID as the target. The access point should have no security on it and be set up just with the SSID and full power. This will allow any wireless device to connect to the attacker’s wireless network if the attacker’s signal is stronger.
Now that the attacker has set up the access point with the server, he needs to go back to the target company and attach a yagi antenna to the access point. Once this is done, he will point it into the window of the target’s building. As more and more people start connecting to the real company’s wireless network, some will actually connect to his (the attacker’s) access point instead. Once this happens and someone connects to it, a screen pops up asking if they want to connect to this network even though it is not secure. This may turn off the first user and make him think about it; however, given time and the number of users getting this screen, someone will just click on it. It does have a familiar-looking SSID that they are accustomed to. Even if no one connects to it, if someone leaves his PC on the desk, boots it up, and walks away, XP will try to connect anyway. Any of the listed ways to get someone to connect will work. The real purpose is to get a single person to connect and, thus, all that is needed is one person.
Finally, someone connects and associates to the attacker access point. Now that the user is connected, the DHCP server on the attacker’s setup will serve up an IP address, default gateway, and DNS. Now the user is going to try to connect to some kind of network service or resource. Maybe he will try e-mail first and nothing will happen; in troubleshooting, he will eventually attempt to access the Internet. The goal is to get someone to access the Web. Although it might not be the user’s first attempt, once he connects to the network, he will most likely attempt to go to the Web as part of his troubleshooting efforts before calling the helpdesk. Once the Web attempt is made, a DNS request will be sent to the default gateway for the DNS server. The attacker will take the request and respond with his Web server’s IP address as the page the user was requesting. Now the user will be directed toward the attacker’s Web server without even knowing it.
Once the Web page opens, a piece of Java script will launch that pops up a window. This window will look just like the default 802.1x authentication windows that the user has seen previously. Now the user will breathe a sigh of relief and type in his username and password. Once he hits the OK button, the form is sent back to the attacker along with the user’s full credentials. Now the attacker turns off his access point and the user connects back to his original access point and re-authenticates. Once the user does this, everything works and he (the user) has no idea what happened. To make things worse, he never thinks twice about even placing a helpdesk call because everything is now working.
And now the attacker can break in as a valid user without attempting any password guessing or brute forcing. This will not alert anyone, even with a conventionally wired IDS. The only way to detect this attack would be with a rogue access point detection software suite or wireless IDS. This can be prevented by using EAP-TLS; however, most enterprises are reluctant to deploy PKI across the entire enterprise unless they have some regulation requiring it.
