The complete TechRepublic Ultimate Wireless Security Guide is available as a download in PDF form.
Towards the end of year 2000, Cisco created a proprietary EAP (Extensible Authentication Protocol) protocol called LEAP (Lightweight EAP) for its line of Wireless LAN Access Points as a way to address the security weaknesses in WEP. One year after its introduction, LEAP authentication for 802.1x Wireless LAN implementations had quickly established such a strong foothold in the enterprise market that it became difficult to sell third party or integrated Wireless LAN adapters that could not run Cisco's proprietary ACU (Aironet Client Utility).
As of 2004, Cisco's commands roughly 60 percent of the enterprise Wireless LAN market and according to one survey by Nemertes, 46 percent of IT executives in the enterprise said that they used LEAP in their organizations. So what's the problem you might ask if you're not one of Cisco's competitors? Because LEAP is used by such a significant percent of enterprise Wireless LANs, it represents a massive security hole for a vast install base in enterprise Wireless LANs where security is suppose to be priority one. What's even more shocking is that few enterprises are doing anything about it.
The theoretical weakness of LEAP was well known from the beginning since it is essentially an enhanced version of EAP-MD5 with Dynamic Key Rotation and Mutual Authentication added. Since EAP-MD5 was never meant to be used on an un-trusted wireless medium and was only to be used for wired communications where there is at least a minimal level of physical security, LEAP probably should never have been used for Wireless LAN authentication.
LEAP is fundamentally weak because it provides zero resistance to offline dictionary attacks. This is because it solely relies on MS-CHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2) to protect the user credentials used for Wireless LAN authentication. MS-CHAPv2 is notoriously weak because it does not use a SALT in its NT hashes, uses a weak 2 byte DES key, and sends usernames in clear text. Because of this, offline dictionary and brute force attacks can be made several orders of magnitude more efficient by a very large (4 gigabytes) database of likely passwords with pre-calculated hashes. What was once thought to be a strong password just became pathetically weak and breakable within minutes.
The standard response from Cisco for years was that LEAP is secure if that organization is using complex enough passwords that make it computationally infeasible to attempt an offline dictionary or brute force attack. Although it was technically true, few organizations have password enforcement policies that meet the strict requirements of strong passwords: 10 characters long with random upper case, lower case, numeric, and special characters.
The vast majority of passwords in most organizations do not meet these stringent requirements and can be cracked in a few days time and many could be cracked in minutes! Of those organizations that do have strict enough password policies, many users simply resort to writing their passwords down on sticky notes and slap it on their monitor because they're too difficult to remember. The reality is that we have now reached an era where commodity computing power has exceeded the average human's ability (or willingness) to remember sufficiently complex passwords.
What is needed is an authentication protocol that protects moderately complex passwords that humans can deal with. However, such a strong authentication technology has coexisted with LEAP from the beginning but few users deployed it thinking they were safe in deploying LEAP. These users ignored the fine print that they needed to enforce a strong enough password policy. Complicating matters is that conventional wisdom on what constitutes a strong password is totally outdated when pitted against a modern tool like ASLEAP and it is unfortunate that many enterprise organizations are not aware of this fact.
Although Cisco has maintained for two years that LEAP is secure and still do, LEAP vulnerabilities are no longer just theories. Thanks to Joshua Wright, you don't even need any kind of real hacking skills to exploit them because he has created a weapons grade LEAP cracker called ASLEAP that just about anyone can use. As a result, Cisco has now been forced to suggest that perhaps it would be wise to migrate away from LEAP for organizations that can't or won't enforce strong passwords.
An adversary can now crack the vast majority of enterprise Wireless LANs running LEAP in as little as a few minutes with virtually zero chance of detection because the attack is passive and performed offline using nothing more than commodity computer hardware. To make things even worse, since most LEAP implementations leverage the single sign-on capabilities of most RADIUS servers, the usernames and passwords cracked are usually the same credentials used for Windows Domain Authentication or some other common user database. This means that not only does the hacker gain access to your Wireless LAN, but he also gains possession of most your usernames and passwords that can directly access critical files and applications!
This is even worse than running no encryption at all on your Wireless LAN because a LEAP attack compromises both the network and your user credentials. If you still have any doubts, here is a summary (from the ASLEAP Webpage) of what ASLEAP can do.
- Recover weak LEAP passwords).
- Read live from any wireless interface in RFMON mode.
- Monitor a single channel, or perform channel hopping to look for targets.
- Actively de-authenticate users on LEAP networks, forcing them to re-authenticate. This makes the capture of LEAP passwords very fast.
- De-authenticate users who have not already been seen, doesn't waste time on users who are not running LEAP.
- Read from stored libpcap files, or AiroPeek NX files (1.X or 2.X files).
- Use a dynamic database table and index to make lookups on large files very fast. Reduces the worst-case search time to .0015% as opposed to lookups in a flat file.
- Write just the LEAP exchange information to a libpcap file. This could be used to capture LEAP credentials with a device short on disk space (like an iPaq), and then process the LEAP credentials stored in the libpcap file on a system with more storage resources.
- Works on Windows systems with limited functionality due to driver restrictions. Hopefully this restriction will be lifted soon.
Now before you start slamming Joshua Wright, keep in mind that he had kept his promise to hold back on the release of the ASLEAP until Cisco had a chance to develop and release a solution for mitigating the vulnerability of LEAP. It was already possible to break LEAP for years well before the release of ASLEAP but you had to have some hacking skills.
In April 2004, Cisco released EAP-FAST and then Mr. Wright released ASLEAP. Unfortunately, the vast majority of large enterprises have yet to even begin to evaluate this new protocol because it is so difficult for any large organization to make any kind of enterprise wide change. We now have a dire situation where a weaponized form of a LEAP cracker is readily available for anyone to use but few organizations have migrated to a secure form of EAP such as PEAP.
From a hacker's perspective, LEAP is a far more tempting target than even the weak WEP protocol because you can usually crack LEAP in 1/10th the time it does to crack WEP and you get two prizes for cracking LEAP instead of one prize for cracking WEP. Ironically, try cracking WEP on a typical wireless LAN and you might find yourself sitting there for days waiting to collect your hundred million packets. Sure you can theoretically do it in 30 minutes if the traffic is going full throttle, but I doubt that you can do it in less than 10 hours in most cases.
Cracking LEAP with ASLEAP on the other hand can be done in minutes because you can literally kick someone off their wireless connection, watch their re-authentication session, and then perform a password crack on the fly for most user credentials! Worst case, the hacker can spend a few minutes recording some LEAP authentication sessions, go home and dump the output on to his more powerful desktop computer with a massive four gigabyte database containing pre-computed hashes corresponding to potential passwords, then go to sleep and wake up in the morning with a pile of clear text user credentials on his desktop PC. Most likely, it won't even need all night since ASLEAP is able to compare about 45 million passwords in a single second on meager hardware.
As LEAP began to gain a massive foothold on the enterprise market, a superior form of EAP called EAP-TLS (Transport Layer Security) was readily available and was completely password cracking resistant because it didn't rely on user passwords. EAP-TLS relied on digital certificates on both the Server and the Client end to facilitate mutual authentication and secure key exchange. Unfortunately, the need for a PKI (Public Key Infrastructure) deployment on the server end and the installed user base was too great a barrier for many organizations.
As a result, Funk Software in conjunction with Certicom proposed a new IETF standard called EAP-TTLS (Tunneled Transport Layer Security) to ease the deployment requirements by producing a standard that only required digital certificates on the authentication server end. Digital certificates were no longer needed for the client end which posed the biggest deployment barrier of all.
Similarly Microsoft, Cisco, and RSA collaborated and created their own "lite" version of EAP-TLS called PEAP which in principal was the same as EAP-TTLS and also alleviated the need for client side certificates. As time went on, PEAP became the dominant standard because Windows XP Service Pack 1 bundled a PEAP client with the operating system and Funk made their products compatible with PEAP.
One might wonder why people are not flocking to PEAP authentication which eliminates dictionary attacks against your sensitive user credentials. It may be a combination of ignorance, the tendency to remain with the status quo, or Cisco's marketing power that tells people that LEAP is safe. Many organizations don't want to deploy a digital certificate on their authentication server because of the $300/year price tag of a publicly trusted digital certificate nor do they want to build their own Certificate Authority server or chain of servers for an in-house PKI. Regardless of the reasons, there is still a massive user base using LEAP authentication for their Wireless LAN implementations and it's a huge disaster waiting to happen. Cisco has responded to the threat of LEAP hacking and the reluctance of most of their customers to adopt PKI-based PEAP with their so-called "PKI-free" protocol EAP-FAST which has even more problems in security and ease of deployment.
Cisco LEAP authentication is a huge security risk in enterprise wireless LANs. So much attention in wireless LAN security or security in general is given to the encryption component of security that the authentication component is often neglected. If your wireless LAN is running LEAP and this document doesn't scare the living day lights out of you, it should. Move to PEAP, EAP-TLS, or EAP-TTLS.