Attacking EAP-TLS

Attacking the EAP-TLS protocol head on is pretty much impossible. If EAP-TLS was suddenly vulnerable to some sort of cryptographic attack, it would probably mean that RSA had been broken, and you would have bigger problems than worrying about your wireless network being attacked. That's not to say that vendor X's EAP-TLS won't have a flaw (though you certainly hope not), just that the protocol is very robust. The only practical way to defeat EAP-TLS is to steal a client's private key.

Stealing a client's key can be very hard, or not that hard at all. If the key is stored inside a smartcard protected by a PIN, you have quite a lot of work ahead of you. If the key is stored on the hard drive of a minimally protected Linux or Windows box that you can attack through some other means, stealing the key could be as easy as loading up Metasploit (http://www.metasploit.com).

Once you have stolen a key (and obtained the user's certificate, which should be much easier since it is public) you configure your computer to connect to the network with the correct certificate and key. Once you are in, if you want to read someone else's traffic, you will need to ARP-spoof them or perform another man-in-the-middle attack. You can't simply decrypt anyone else's traffic with airdecap because everyone has a unique PMK.

Protecting EAP-TLS

If you have already implemented EAP-TLS, you clearly already have quite a handle on wireless security. If possible, store the client keys on smartcards or some other tamper- resistant token. If not, be sure to keep client workstations patched and up-to-date to prevent the clients' private keys from being stolen.

One minor concern with EAP-TLS is the information contained in certificates and passed around is freely available. Certificates contain mildly sensitive information such as employee names, key length, and hashing algorithms. If you're concerned about this, you can run EAP-TLS in an encrypted tunnel, thus protecting the information just mentioned. This technique is called PEAP-EAP-TLS and was invented by Microsoft.

LEAP (lightweight EAP) is Cisco's proprietary authentication technique. LEAP has an interesting history. Cisco pushed LEAP to market before WPA existed. That means there are two flavors of LEAP possibly deployed. The version of LEAP released before WPA was a big improvement over WEP. It supported temporary session keys, mutual authentication, and centralized key management. Pre-WPA LEAP uses the same 802.1X authentication model that WPA/802.11i uses. It's important to remember that pre-WPA LEAP provides improved authentication, not replay protection or any of the other finer points afforded by WPA. Pre-WPA LEAP lets you generate a dynamic WEP key from a username and password, but you're still using WEP to secure the traffic.

The newer flavor of LEAP fits more cleanly into the model of wireless security. In this case, the network is protected with WPA or 802.11i in enterprise mode. Instead of EAPTLS or WPA-PSK, however, LEAP is used as the specific EAP type for authentication.

At the end of the day, however LEAP is deployed, it is vulnerable to a severe security problem. LEAP is based on the MS-CHAPv2 challenge-response protocol. This protocol does not use the world's most secure cryptographic primitives.

LEAP works with usernames and passwords, similar to other challenge-response protocols. When a client connects to the network, the user sends his username, and the authentication server returns an 8-byte challenge. The client then computes the NT hash of the password and uses that as seed material to encrypt the challenge using DES three times. The results of the three DES encryptions are concatenated and returned to the server. The server does the same computation and verifies the results.

The problem arises because running DES three times against the challenge requires that you have 7 bytes of seed input for each iteration, or 21 bytes total. The NT hash of the password provides you with only 16, which means the third DES encryption is done with the final 2 bytes of the NT hash padded out with five NULLS. This last round of DES can be brute-forced easily. Once you've done that, you can use those 2 bytes of the NT hash to launch an efficient dictionary attack on the rest of the NT hash. If the dictionary attack succeeds, then you recover the password used to create the NT hash.

If that was too many crypto routines to follow, let me rephrase. Don't use LEAP. To "securely" use LEAP requires strong passwords in the first place. The biggest advantage LEAP has is the convenient use of client-side usernames and passwords. If you want to deploy some sort of EAP type that lets you use usernames and passwords conveniently, try PEAP (described later).

Attacking LEAP

Asleap is a tool to crack LEAP; it was made publicly available by Joshua Wright. To attack a LEAP client, you need to watch them authenticate to the network. As usual, you can simply deauth them. Asleap can actually do this for you.

Asleap supports cracking networks either in real-time or from a previously saved pcap file. Regardless of which route you take, the first thing you need to do is create a hashed dictionary file. This file can be used to recover passwords from any LEAP- protected network-unlike WPA-PSK dictionary attacks, which are tied to a specific SSID. The following command creates a hashed dictionary file:

 [johnycsh@phoenix:~/asleap]$./genkeys -r ./dict -f dict.hashed -n dict.idx
genkeys 1.4 - generates lookup file for asleap.
<jwright@hasborg.com>
Generating hashes for passwords (this may take some time) ...Done.
10205 hashes written in 0.37 seconds:  27235.77 hashes/second
Starting sort (be patient) ...Done.
Completed sort in 42321 compares.
Creating index file (almost finished) ...Done.

This command actually outputs two files: an index file (.idx) and the hashed dictionary file (dict.hashed). This part of the attack can be precomputed from a large dictionary, before you've even identified the network to attack. Once the hash dictionary is complete, you can launch the attack. In the following example, a pcap file is provided in which the LEAP authentication is captured and the password is qaleap:

./asleap -r ./data/leap.dump -f ./dict.hashed -n ./dict.idx
asleap 1.4 - actively recover LEAP/PPTP passwords. <jwright@hasborg.com>
Using the passive attack method.

Captured LEAP exchange information:
        username:          qa_leap
        challenge:         0786aea0215bc30a
        response:          7f6a14f11eeb980fda11bf83a142a8744f00683ad5bc5cb6
        hash bytes:        4a39
        NT hash:           a1fc198bdbf5833a56fb40cdd1a64a39
        password:          qaleap
Closing pcap ...

Protecting LEAP

If, for some reason, you are forced to use LEAP and can't upgrade, the only thing you can do is try to enforce a strict password policy. If there is any way you can switch to something else, do it. PEAP makes a good replacement to LEAP, and you can still employ usernames and passwords. Cisco recommends migrating to its LEAP replacement, EAP-FAST.

Certificate Validation Failure Attacks Against PEAP/EAP-TTLS

While running another form of authentication inside an encrypted tunnel seems like it could only add security, there is a possible flaw. When using PEAP, the PMK used by WPA is derived from the TLS tunnel that was created before the user authenticated, not the authentication mechanism used inside the tunnel. This is an intentional design decision that allows you to run insecure authentication techniques (that don't generate cryptographic keying material, such as plaintext passwords) inside a tunnel. Figure 7-3 shows the PEAP authentication exchange.

Figure 7-3: Example PEAP authentication exchange

Now consider what happens if the client fails to verify the authentication server's certificate. It opens PEAP up to a very damaging man-in-the-middle (MITM) attack.

If the client fails to validate the certificate, an attacker can set up an MITM attack. He just has to position himself with two radios somewhere between the victim and the real AP. Once there, he sets up one radio to look like the real AP. He then waits for a victim to connect. Once a client attempts a connection, he sends the client his own certificate, which she doesn't verify. The client will then establish a TLS tunnel with the attacker and send over her real identity.

At this point, the attacker establishes a connection to the real AP. He establishes his own TLS tunnel and sends the victim's real identity through. Once this is done, the attacker proxies authentication messages back and forth. He receives challenges on his TLS tunnel with the server, decrypts them, and sends them through his TLS tunnel to the client. Similarly, he will decrypt the victim's responses, re-encrypt them, and send them on. The attacker can bypass any sort of authentication that is now going on, because he lets the victim do all the work. It's similar to what happens in the movies when the bad guy follows Indiana Jones into the cavern to steal the loot. They let him get in and do all the hard work, only to try and step in and take it when he's finished.

Once the client has successfully authenticated herself by proxy to the authentication server, the attacker receives an EAP authentication success message. This is the point where the problem with deriving the key from the outer TLS tunnel comes into play.

Even though the attacker authenticated with some technique inside the TLS tunnel, the PMK is not derived from the internal authentication mechanism. Instead, the PMK is created with material generated from the TLS tunnel set up by the attacker. The attacker can now derive the PMK that the authentication server sends to the AP. At this point, the game is over. The attacker has the PMK.

Now the question is, what does the attacker do? A naive attacker just disconnects the user, hops on the network, and starts hacking. A sophisticated attacker (and anyone who implements this is probably in the sophisticated camp) tricks the client into thinking that she really is connected. The attacker will send the client an EAP success message as well. The client then derives a PMK from the TLS tunnel to the attacker. The attacker derives the key as well.

Now, the attacker can receive all the data packets, decrypt them, re-encrypt them, and forward them on to the real network. The attacker is in a position to do much more damage than if he had just stolen someone's PMK; he can actually modify packets as they are passed along. Figure 7-4 shows an overview of this attack.

Figure 7-4: Overview of a PEAP certificate authentication failure attack

Preventing Certificate Authentication Validation Attacks

The key to preventing these sorts of attacks against PEAP (or EAP-TTLS) is to ensure that your clients validate certificates. This might seem like a silly worry, I mean, who wouldn't validate the certificate? Well, it's not the default setting on some operating systems. On OS X, it's not clear how to require certificate validation, and on some versions of Windows XP, validation is not enabled by default.

Many people wonder why this is an option. Why is that checkbox even there? Well, in order for clients to validate certificates either they need to have the root certificate for the local organization's CA installed (which can be cumbersome to do) or the network needs a certificate issued by a well-known CA (which costs money). Allowing users not to verify certificates lets administrators avoid buying a certificate or running their own certificate authority just for wireless access.

This problem poses a serious risk to PEAP-protected networks. Unfortunately, there is no easy solution to make sure that a client does not get misconfigured. One hack you might consider implementing is to intentionally send a client an invalid certificate occasionally, ensuring he rejects it. If the client attempts to continue authenticating, blacklist the user and reconfigure the machine. Of course, this requires significant customization of an organization's authentication system, which is probably not a good idea.

A more long-term solution is to bind the tunnel-based key material cryptographically with the internal authentication technique used. This is a design decision, however, and requires modifying the standard.

Finally, there is one more concern with PEAP. When using PEAP, sending a fake identity (outside of the TLS tunnel) is optional. Many clients are (or can be easily) misconfigured to send the real identity. When using EAP-TTLS, the initial identity is always "anonymous."

Attacking Delivery of the PMK over RADIUS

After reading about the last three EAP authentication techniques, you might be wondering if there isn't an easy way to bypass all these authentication protocols. One place to look is at the delivery of the PMK via RADIUS from the authentication server to the AP. If you can sniff that, you're in great shape. If you can somehow watch the PMK as it traverses the wired LAN to the AP, you can watch the four-way handshake and derive individual user's PTKs yourself. Doing this completely sidesteps the type of EAP authentication and doesn't depend on the clients using RC4 or AES to encrypt traffic to the AP. With the stakes set so high, you would think that some very serious crypto is required to protect key delivery. You will see momentarily that while the crypto used to protect the delivery of PMKs is sufficient, the key used to protect delivery of keys is not. The following attack is feasible because the RADIUS shared secret (from here on out, referred to as RADIUS secret) is used for two purposes-a design decision with huge consequences.

Before delving into the details of this attack, it is important to emphasize that in order for it to succeed the attacker must already have some sort of presence on the wired LAN. Not only must the attacker be somewhere on the inside, but also she has to be able to position herself between an AP and the RADIUS server. Depending on the network architecture, this might be relatively easy to extremely difficult. For the rest of the discussion, let's assume the attacker can somehow observe traffic between the AP and RADIUS server.

If an attacker can sniff RADIUS traffic, the network is in serious jeopardy. RADIUS uses MD5 as the basis for its authentication. Every AP is given a RADIUS shared secret, and it's quite possible that every AP in a network uses the same shared secret, though hopefully not. In either case, if an attacker can somehow sniff RADIUS traffic, this often overlooked aspect of security is your last line of defense.

The first phase of the attack consists of getting the AP to communicate with the RADIUS server. This phase doesn't require that a client successfully authenticate, so the easiest thing is to attempt connecting. When the AP and the RADIUS server exchange messages, they include a field called the Response Authenticator. This field is used by the AP and RADIUS server to ensure that messages aren't spoofed by untrusted parties. In order to compute this field, the sender of the message needs to know the RADIUS secret. The Response Authenticator is equal to

MD5(code + id + len + request authenticator attributes + RADIUS secret)

The important thing is the RADIUS secret is the only field not included in plaintext in the RADIUS packet.

Once an attacker sniffs a packet with the Response Authenticator, she can mount an offline dictionary attack to compute the RADIUS secret. Basically, she will just compute MD5(code + id + len + request authenticator attributes + dictionary word ) until she gets the correct hash. Once she gets the correct hash, she knows the RADIUS secret.

Considering the power that knowing the RADIUS secret gives the attacker (especially if the secret is used across more than one device), you can assume she will spend considerable resources doing this. Also, since MD5 is so ubiquitous, there is no shortage of highly optimized code (and even hardware) floating around to speed up the MD5 computation. Finally, even if it takes an attacker an entire month to recover the secret, it is still likely to be in use. There is no easy way to rotate RADIUS secrets in many devices.

Assuming the attacker retrieves the RADIUS secret successfully, all the PMKs transmitted by the RADIUS server are now hers for the reading. Though they are encrypted on their way to the AP (using Microsoft Point-to-Point Encryption or MPPE), the RADIUS secret is all an attacker needs to decrypt them.

An important detail about this attack is that you are not launching an attack against the crypto used to encrypt the PMK (MPPE). In fact, the encryption scheme used to protect the PMKs is irrelevant. Instead, you are exploiting the fact that the RADIUS secret is pulling double duty. The RADIUS secret is used to authenticate messages between the AP and the RADIUS server (even if the messages have nothing to do with key delivery). The RADIUS secret is also used as the base key to encrypt PMKs for delivery. By launching a successful MD5 brute-force attack against the response authenticator field used by RADIUS, you can retrieve the RADIUS secret and, therefore, the ability to decrypt PMKs being delivered for free. This is a great example of why the same keys should never be used for authentication and encryption.

Assuming the attacker can somehow exfiltrate the sniffed PMK (preferably in realtime), she can now derive the PTK for any user. Clearly, the attacker can decrypt the user's data packets as she sends them. She can also attempt to disconnect the user without letting the user perform a proper disconnect from the network. If the attacker is successful, she can impersonate the user and gain access to the network.

Even if the attacker is in the strange position of being able to sniff and decrypt PMKs but can't get them out quickly for some reason, she can still do a lot of damage. The attacker can arrange to transmit a week's worth of PMKs to an offsite server, for example, while at the same time sniffing all the wireless traffic. Once a week, the attacker combines the PMKs with the sniffed traffic and decrypts it retroactively.

Finally, though the details are outside the scope of this book, knowing the RADIUS secret for a device may give the attacker the ability to administer the said device. And if the same shared secret is used across devices, an attacker can potentially administer all of your APs. And to think, all it took was breaking a single MD5 hash.

Protecting PMK Delivery

Unfortunately, there is no quick fix for this one. One of the most effective techniques is to place all RADIUS traffic inside an IPsec tunnel (something specifically recommended, but not required, in the RADIUS standard). Unfortunately, few products support this.

Other suggestions include using unique RADIUS shared secrets for every device, though this can be a real headache for administrators. Minimizing the number of devices that actually possess RADIUS shared secrets can help make the network more maintainable. So-called thin APs that put most of the AP brains into a centralized switch can also help. Finally, it should go without saying that you should choose a RADIUS secret that is long and random, as shown in Figure 7-5-and preferably gets changed regularly.

Figure 7-5: Setting the RADIUS shared secret for an AP. Make sure it's a good one.