Log in

Site menu:



Site search

August 2020



Chapcrack and CloudCracker

Some of the biggest news that came out of DEFCON 20 was coverage of Moxie Marlinspike’s latest evisceration of MS-CHAPv2. There are papers dating back to 1999 describing weaknesses in MS-CHAPv2, Microsoft’s “updated” version of their original challenge/response system for authentication. The scheme’s weakness described briefly: a Server sends a Client a 16 byte challenge, from which the client cryptographically derives an 8 byte value. The Client then transforms this value into the 24 byte response by padding its 16 byte password hash to 21 bytes with zeros, splitting those 21 bytes into three DES keys of 7 bytes each, and encrypting the 8 byte value. The last key (the “K3” reference inside the chapcrack code) really only has 2 bytes of key material, significantly reducing the key space, and simplifying attacks like this one.

But this has been known for a long time, so this is not news. The news is in part Moxie’s python tool that automates the extraction of the readily available cipher text, plain text, and key material from an MS-CHAPv2 exchange. For example, running a PPTP packet capture containing successful authentication against chapcrack produces the following:

Got completed handshake [ –>]
Cracking K3………
User =
C1 = f8e699cbcc6ca0d5
C2 = 534f2da52b977b26
C3 = d1194e961cf2c996
P = 7daffd76455abb44
K3 = 74670000000000
CloudCracker Submission = $99$fa/9dkVau0T45pnLzGyg1VNPLaUrl3smdGc=

That last line can be submitted to CloudCracker, and $200 and less than 24 hours later, the entirety of DES space (7.2 * 10^16) will be walked, and a key will be provided that can be fed to chapcrack to decrypt the source packet capture file.

The second part of the news is the attention brought to CloudCracker, a years old Cracker-as-a-Service platform that makes perfectly affordable what was practically infeasible a decade ago. 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).” – Source

But the biggest news is the unmistakable demonstration of how truly numbered are the days of weak crypto systems hiding behind perceived economic impracticabilities. 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 WPA/WPA2-EAP (extensible authentication protocol) using MS-CHAPv2 without TLS is in practice. 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 that’s been 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.

Share: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Twitter
  • Reddit
  • Slashdot
  • LinkedIn
  • Facebook
  • email
  • Print

You must be logged in to post a comment.