Networks secured using 802.1X require the client to undertake an EAP-based authentication method before network access is granted. In these scenarios there are several attack vectors;
- Client Vulnerabilities
- EAP Protocol Vulnerabilities
- Network Vulnerabilities
Directly attacking a known-good Client is probably the easiest way of circumventing security. There are endless ways of doing this, social engineering and phishing attacks are probably the most topical at the moment, but if you have access to the physical device than you can attack that directly too. At the simpler end of the physical attack spectrum you can use an in-line keylogger between keyboard and computer to steal credentials in plain text, or if you’re lucky enough to find a machine that doesn’t have an encrypted hard disk, you can directly attack the SAM file (windows) or the Shadow file (linux) by quickly removing the hard disk. (SAM/Shadow attacks don’t work on newer Operating Systems, but if you’ve got direct HDD access you might get lucky and find a file somewhere else on the HDD that contains credentials you can use).
EAP Protocol Vulnerabilities
Attacking the EAP Protocol its self is another potential way to gain Access. There are some EAP methods that, no matter how they are implemented, are always insecure – EAP-MD5 and LEAP and the two most common. These protocols can both be attacked by sniffing traffic and performing offline attacks.
Other protocols are secure, but only when implemented properly. The most common EAP-based protocol I find deployed on Wired and Wireless networks is PEAP-MSCHAPv2. PEAP-MSCHAPv2 is also the easiest to misconfigure.
At a basic level, PEAP-MSCHAPv2 uses an SSL outer wrapper (like HTTPS), and then it passes MSCHAPv2 credentials inside the SSL tunnel to the RADIUS Server. PEAP ensures it doesn’t send the credentials to the wrong RADIUS Server by implementing RADIUS Server Verification on the Client. This is the ability to tell the Client ‘only trust a RADIUS Server that presents a Certificate with a specific Common Name and that uses a Certificate signed by a particular CA‘. When PEAP is configured correctly it is very secure (it’s as secure as the SSL Certificate used on the RADIUS Server), but when RADIUS Server verification isn’t configured correctly (or at all!), the Client could send its MSCHAPv2 credentials off to whatever RADIUS Server challenges it to do so.
There are a few ways of getting the PEAP config wrong even if you have configured RADIUS Server Verification, and they all stem from not changing default Windows settings. By default, if a Client finds its self talking to an unexpected RADIUS Server, it shows the User some info they won’t understand and basically says ‘Connect anyway?’ with the default action being ‘yes’. Why Microsoft have this as the default I’ve no idea, but please do change it! Another annoyance about PEAP-MSCHAPv2 is that it sends a Username in clear text to the RADIUS Server before the RADIUS Server sends the Client a copy of the SSL Public Key (inside which the MSCHAPv2 traffic is later sent). By default, Windows will send off the User’s actual Username, which is a good way of leaking information to anybody that’s listening. Fortunately you can change this behaviour by enabling Identity Privacy.
Here’s what a good PEAP-MSCHAPv2 config looks like in Windows – the red dashes show changes from the default.
As an attacker, you can control what RADIUS Server is used by providing your own network and RADIUS Server, and connecting a victim machine to it. If you’re lucky enough to find a poorly configured Client machine that trusts the attacking RADIUS Server, it will freely provide its MSCHAPv2 credentials to the attacker, which can then be subjected to further offline attacks.
Lets assume the network and its Clients are secured using well-configured PEAP-MSCHAPv2 or EAP-TLS, the device’s Hard Disk is encrypted and all other attempts at stealing credentials have failed. A network like this is still vulnerable because of the basic properties of how 802.1X works. At its most simple, 802.1X sessions on a switch are a simple combination of switchport state and Client MAC Address tracking. If the switchport state drops, the authenticated session ends. If the MAC address changes or a new MAC address appears, it needs authenticating.
We can use these two simple characteristics in conjunction with a known working device, to piggyback an attacking device on to the network. To exploit this weakness, all an attacker needs to do is insert a transparent, intermediate device (a hub or dumb switch) between the target network and the known-good Client. Wait for the Client to authenticate as it usually would and then disconnect it from the intermediate hub/switch. Spoof the good device’s MAC address on to the attacking machine and connect the attacking machine to the intermediate hub/switch, and now you have access. The intermediate hub/switch keeps the interface up on the victim network while spoofing the MAC Address on to the attacking machine allows it to pass traffic without needing to undergo authentication because the switch has no idea there has been a swap. If the switch is configured to periodically perform re-authentications, the attacking machine won’t be able to provide the necessary credentials, but re-connecting the victim machine briefly will provide the switch/RADIUS Server with the credentials they want to see and the interface will resume service.