Skip to content

ChapCrack’s Lesson: Computing Power Overwhelms Weak Crypto


Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

Some of the biggest news that came out of DEFCON 20 was coverage of Moxie Marlinspike’s latest evisceration of MS-CHAPv2 with his new tool, ChapCrack. Most papers about weaknesses in MS-CHAPv2 date back to 1999; It was, at the time, Microsoft’s “updated” version of their original challenge/response system for authentication, and remains widely in use.

What makes the story interesting, to me, comes down to two things: Moxie’s announcement that, for $200, his CloudCracker service will provide customers with keys that can decrypt MS-CHAPv2 traffic; And ChapCrack itself, a python tool that automates the extraction of the readily available cipher text, plain text, and key material from an MS-CHAPv2 exchange, and with CloudCracker’s help, decode it.

The availability of cloud computing resources not only make this possible, it’s practically a bargain. And now that we have a formula to crack CHAPv2, its usefulness will degrade rapidly. As sufficient computing power trickles down into smaller devices, there might even be an App for that, someday.

MS-CHAPv2’s weakness, from a technical perspective, is fairly complex, but it boils down to this: A Server sends a Client what’s known in cryptography as a challenge. The client is obligated to send a response, and in the case of MS-CHAPv2, the response has to be formed in a specific way and be a specific length. So it starts building the response by performing some operations on a 16-byte hash of the user’s password.

The algorithm, for technical reasons, needs to break the hash evenly into three pieces, seven bytes long; To make up the difference, it pads out the 16-byte password hash with five additional zeroes. When you then break that 21-byte number up into three 7-byte pieces, the last 7-byte piece always has the last two bytes from the original hash, and five zeroes.

That’s not particularly sound crypto. Because the last key (the “K3” reference inside the ChapCrack code) really only has 2 bytes of key material, attacks like this one are made far simpler.

But this has been known for a long time, so this is not news. What is news is how Marlinspike proposes using CloudCracker, his years old crypto-cracking-as-a-service business model, to offer the service to a global clientele.

ChapCrack generates a special “CloudCracker Submission” code; Submit the code with $200, and less than 24 hours later, Marlinspike’s system walks the entirety of DES key space (7.2 * 10^16 encryption keys), resulting in a value that the user can feed into ChapCrack to decrypt the encrypted data.

Consider this now comically shortsighted description of the weakness offered by Microsoft in 2002:

If the password is strong enough, it will take a single 200 MHz Pentium Pro computer an average of 2,200 years to find the keys derived from it and 5,500 years to find the password itself (or 2.2 years and 5.5 years with 1,000 such computers, and so forth).

The real story behind this story is the unmistakable demonstration of how truly numbered are the days of weak crypto systems hiding behind perceived economic impracticalities. Vendors need to learn to stop ignoring weaknesses and attacks as “theoretical” simply because they seem out of reach by today’s standards. Multi-core, cloud, and (someday) quantum computing totally invalidate such an irresponsible posture. Broken things need to be fixed upon discovery because sooner or later exploitation will become affordable, and the longer they are allowed to remain in use, the more expensive they tend to become to replace.

How big of a problem is the announcement? Big for anyone still using PPTP for their VPN solution despite a decade of awareness of the problem. But if someone is still using PPTP (instead of some form of SSL-VPN or IPsec), that’s a signal of generally questionable IT competence, which means there are likely other problems that can more easily be exploited.

As for the possibility of using this attack to crack WPA/WPA2 Enterprise traffic, that seems unlikely to happen on any sort of meaningful scale given how rare it is to find WPA/WPA2-EAP (extensible authentication protocol) using MS-CHAPv2, without TLS, in the real world. By far the most common form using MS-CHAPv2 is WPA/WPA2-PEAP, which uses TLS to protect the MS-CHAPv2 exchange. Only if the attacker manages to gain access to the TLS private-key for decryption of the outer layer (which is a far greater problem) could the inner layer be attacked with ChapCrack.

The other WPA/WPA2 cracking options available on CloudCracker (and Moxie’s before it) attacks passwords in WPA/WPA2 PSK (pre-shared key, not EAP), and is unrelated to ChapCrack. The fact that they are both present on CloudCracker might be confusing, and unnecessarily alarming to some, but most properly designed enterprise wireless systems should be safe from this method of attack.Solera blog stats

Comments are closed.

%d bloggers like this: