As noted earlier, A. Mishra and W. Arbaugh claim that the IEEE 802.1X is vulnerable to session hijacking and man-in-the-middle attacks in their paper, “An Initial Security Analysis of the IEEE 802.1X Standard” [13]. They proposed that after a legitimate client authenticates itself to a WLAN and obtains network connectivity from the authenticator, and after the appropriate message (12) exchange, which is depicted in Figure 27, an adversary can send an 802.11 MAC disassociate management frame using the AP’s MAC address. This causes the supplicant to be disassociated from the AP, but keeps the authenticator state machine at the authenticated state. Then the adversary gains network access using the MAC address of the affected authenticated supplicant. [6]
A. Mishra and W. Arbaugh also noted that an EAP-Success message sets the eapSuccess flag, which makes a direct transition to the authenticated state irrespective of the current state. Typically this would cause the interface to come up and provide network connectivity. Thus, an attacker could forge this packet on behalf of the
authenticator and potentially start a simple Man-in-the-Middle (MiM) attack. The adversary can thus obtain all network traffic from the supplicant to pass through it. [6]
Even though the session hijacking and MiM attacks are applicable, they need an open-source platform. The aforementioned attacks require spoofing MAC addresses, generating management and EAP-Success messages, and relaying data frames. These types of attacks cannot be evaluated without open-source test-bed support. The 802.1X test-bed explained in Chapter IV could be used to generate individual management, EAP, or EAPOL messages and to spoof the MAC addresses of the 802.1X entities.
1. Demonstration of a Denial of Service Attack on a 802.11B WLAN A DoS attack was applied to demonstrate the utility of the test-bed. The WinXP supplicant served in the role of the legitimate client, the Cisco Aironet 340 access point performed in the role of the legitimate authenticator, the FreeRADIUS functioned in the role of the authentication server, and the hostap took the role of the attacker.
AuAutthheennttiiccaattoorr Authentication Server Supplicant
Attacker
Figure 35. DoS Attack Entities
HostAP was used as an attacker, because the Linux operating system allows changing the MAC address of the wireless NIC. It is crucial to change the MAC address to impersonate the legitimate authenticator.
Once the successful authentication and key distribution was finished at the legitimate connection, the attacker monitored the WLAN communication. Netstumbler, a freeware network monitor, was used to determine the MAC address and the SSID information of the legitimate access point. These are enough information for the attacker to generate a DoS attack. The legitimate AP’s MAC address and SSID were spoofed by the attacker AP with the following shell commands.
ifconfig wlan0 hw ether XX:XX:XX:XX:XX:XX iwconfig wlan0 essid “?????”
./hostapd –d hostap.conf
These commands were enough to invoke the malicious access point with the spoofed MAC address and the SSID of the legitimate AP. The hostap driver generated the deauthentication frames by default at the startup [Appendix E].
When the legitimate client received these unauthenticated deauthentication messages, it tried to reauthenticate with the AP. Since the attacker generated a stronger RF signal than the legitimate AP, the client tried to associate with the attacker’s AP.
Even though the client believed that it tried to authenticate with the legitimate AP, the malicious AP, impersonating the legitimate AP, directed the client’s RF signal to associate with itself. The client tried to complete the 802.11 open-system authentication and association procedure with the malicious AP. However, the client could not complete the 802.1X authentication because there was no authentication server. The client could not use the network services as it did with the legitimate AP, thus suffering from a denial of service as desired by the attacker.
Figure 36 illustrates the DoS attack in detail.
Spanagel 2nd Floor
Sp-257
2
Sp-238 1
3
No network connectivity, under attack
Authentication Server Legitimate AP
Client Attacker
Network connectivity
Figure 36. DoS Attack Placement
1). Client first completes an open-system authentication and association with the legitimate AP in room SP-238. The 802.1X authentication and key distribution is finished after the 802.11 open-system authentication and association is completed. The attacker then starts to run a malicious access point. That access point generates the deauthentication messages by impersonating the legitimate AP MAC address and SSID.
Since the attacker’s RF signal strength is more powerful than the legitimate AP, the client is forced to reauthenticate, but with the attacker’s AP. At this moment, the client cannot use the network services, which the legitimate AP provides. The DoS attack is successfully applied.
2). The effective attack range is examined by moving the malicious AP. It is transported through a 200 foot hallway. The dotted lines indicate the attack period. The
“Ping” command is used to check the connectivity with the authentication server because
only the legitimate AP has a wired connection with the authentication server. The client finally connects with the legitimate AP after the malicious AP’s RF signal fades.
3). When the malicious AP’s RF signal again overwhelms the legitimate AP, the client comes under attack again at point “3.” The timers at the state machines most probably cause the connectivity difference in the “interruption range.”
Since the 802.11 management frames and the 802.1X EAP/EAPOL frames are unauthenticated, these frames can be generated by changing the HostAP source code.
Being able to generate these individual frames gives attackers the ability to apply DoS attacks.