Cloud-based service requires an average of 12 hours to decrypt VPN traffic.

Researchers have devised an attack against a Microsoft-developed authentication scheme that makes it trivial to break the encryption used by hundreds of anonymity and security services, including the iPredator virtual private network offered to users of The Pirate Bay.

The attack, unveiled by Moxie Marlinspike and David Hulton, takes on average just 12 hours to recover the secret key that iPredator and more than 100 other VPN and wireless products use to encrypt sensitive data. The technique, which has been folded into Marlinspike's CloudCracker service, exploits weaknesses in version 2 of a Microsoft technology known as MS-CHAP, short for Microsoft challenge-handshake authentication protocol. It's widely used to log users into VPN and WPA2 networks and is built into a variety of operating systems, including Windows and Ubuntu.

"We hope that by making this service available, we can effectively end the use of MS-CHAPv2 on the Internet once and for all," the researchers wrote in a blog post published over the weekend. "We find many popular VPN products are susceptible to a variety of practical user deanonymization attacks. Weaknesses stem from lack of security analysis of the composition of VPNs, applications, and the TCP/IP stack on each respective operating system."

Microsoft officials are "actively investigating the issue and will take the necessary steps to help protect customers," the company said in a brief statement.

MS-CHAP is the widely used authentication component of several encryption technologies including the PPTP, or Point to Point Tunneling Protocol, which is used by many VPN programs to implement secure functionality. The Microsoft technology uses the MD4 cryptographic function to convert user-selected passwords into a one-way hash that is then broken up into three smaller chunks.

Each chunk forms a Data Encryption Standard key that's used in a separate encryption operation. Exhausting every possible combination of the entire MD4 hash requires 2128 attempts, making such brute-force attacks infeasible. But by breaking the key into three keys—the first two consisting of 7 bytes and the third of just 2 bytes—they become susceptible to what cryptographers call a "divide and conquer" attack.

There are only 65,535 possible combinations for the last key, requiring just a few seconds to crack it using brute-force methods. Cracking the first 14 bytes of the MD4 hash would normally require enough work to make most attacks infeasible, but the researchers found a way to significantly reduce the overhead. Because the two remaining unknown keys are used to encrypt the same plaintext, the cracking routine for each can be consolidated into a single iteration through the possible keyspace. That translates into just 256 possible combinations, which is the same complexity offered by a single DES encryption.

"Since the third DES key is only two bytes long, a keyspace of 216, we can immediately see the effectiveness of [a] divide-and-conquer approach by brute forcing the third key in a matter of seconds, giving us the last two bytes of the MD4 hash," the researchers wrote. "We're left trying to find the remaining 14 bytes of the MD4 hash, but can divide-and-conquer those in two 7 byte chunks, for a total complexity of 257."

The service added to CloudCracker relies on powerful hardware sold by Hulton's Pico Computing firm. It uses FPGA, or field-programmable gate array, technology to quickly cycle through each possible combination until the right one is found. Users who want to crack the key protecting a target's VPN- or WPA2-protected traffic need only capture a single login attempt and then upload the packets to the online service. It takes a maximum of 23 hours to crack the key, with the average crack requiring just half a day.

The divide-and-conquer technique is a vast improvement over an attack first described in 1999 by Bruce Schneier and a researcher known as Mudge. That exploit made it easy to decrypt communications that were protected by weak passwords. In the years that followed, many services that relied on MS-CHAP responded by requiring users to use long, randomly generated passwords. VPN services offered by riseup.net, for example, selected a 21-character password on behalf of the user that used a combination of 96 different numbers, symbols, and upper- and lower-case letters to withstand such attacks. MS-CHAP is also used in the iPredator VPN used to decrypt traffic between The Pirate Bay and its end users, Marlinspike said.

"What we're doing is giving you a 100-percent success rate," Marlinspike told Ars. "It doesn't matter what password you choose. We demonstrate that [MS-CHAP] is never secure."

Other cryptographers agreed that the new attack is significant.

"Once you have something that can crack DES in half a day, it's kind of like having a master key for DES," Matthew Green, a professor specializing in cryptography in the computer science department at Johns Hopkins University, told Ars. "And at that point, any protocol that works like MS-CHAP is going to just fall apart."

Marlinspike said people should immediately stop using VPN and WPA2 products that rely on MS-CHAP. They should instead rely on certificate-based authentication methods, such as OpenVPN, SSL VPN, or certain types of IPsec, as long as it doesn't use a pre-shared key for authentication.

59 Reader Comments

Researchers have devised an attack against a Microsoft-developed authentication scheme that makes it trivial to break the encryption used by hundreds of anonymity and security services, including the iPredator virtual private network offered to users of The Pirate Bay.

Poor pirate bay.

Quote:

"We hope that by making this service available, we can effectively end the use of MS-CHAPv2 on the Internet once and for all," the researchers wrote in a blog post published over the weekend.

A hint of something personal?

Quote:

Marlinspike said people should immediately stop using VPN and WPA2 products that rely on MS-CHAP. They should instead rely on certificate-based authentication methods, such as OpenVPN, SSL VPN, or certain types of IPsec, as long as it doesn't use a pre-shared key for authentication.

Has anyone got the chapcrack script to spit out the MSCHAPv2 handshake from a packet dump? I've got it to work (obviously) with the sample pcap files that are included with the dump, however when I took a packet capture of my ethernet interface and initiated a PPTP connection across it, chapcrack couldn't find any handshakes in the dump. I can't figure out what I'm doing wrong.

Since I don't know all the specific technicalities behind all this, is the key something that can be obtained, then cracked away from the target network, then used to gain access? Meaning can it be mitigated by blocking traffic coming from a source after too many attempts, or is it something where they can get the encrypted key, decrypt it elsewhere, and then just come back to clean house with valid credentials?

Note that typically with WPA(2) Enterprise *PEAP*-MSCHAPv2 is used, which uses TLS to protect the MSCHAPv2 challenge-response. In this case the attack can be stopped by verifying the certificate.

I thought something like this was probably the case. Thanks for your post as it confirms my understanding. So an attack against this would be to exploit user's general poor practice of accepting certificate warnings, and set up another AP with the same SSID and security settings, just different certificate, and see how many people connect to that.

Edit: The problem is what the recommendations will not be easy for something like a router. IPSec is a royal pain to set up, while OpenVPN as far as most consumer routers makes an appearance when using 3rd part firmware. There's also the backwards compatibility problem.

Edit2: That third DES key and it's padding. How difficult would it be to patch to have a full key there?

So when you authenticate to your VPN, does it use the same parameters every time? If it's cracked once, it never has to be cracked again? If so, does changing your password reset the scheme such that it would have to be cracked again?

I don't get what all the fuss is about. We've known the weaknesses of mschap v2 for about ever now and tools for cracking it have been available for ages. I mean I have a good deal of respect for both these guys but could someone explain to me why this is news?

Since I don't know all the specific technicalities behind all this, is the key something that can be obtained, then cracked away from the target network, then used to gain access? Meaning can it be mitigated by blocking traffic coming from a source after too many attempts, or is it something where they can get the encrypted key, decrypt it elsewhere, and then just come back to clean house with valid credentials?

It's an "offline" attack. They get a sample of data to work on, then go away ("offline") to use their own resources to break the cryptography. Any time you see stuff about custom hardware, or FPGAs, or arrays of GPUs, it's pretty much guaranteed to be talking about an offline attack. "Online" attacks, where the attacker makes lots of requests to the server until one finally works, don't usually involve throwing raw computing power at it because the target server is the bottleneck.

I think the article misses the point of why this mattered (it took me a bit to even understand why this was news at all). The basic weakness in MSCHAPv2 has been known for many many years. Many implementations have been made and released for the attack too.

I know both of these guys, and it didn't sound right that they'd be hyping some very old attack as being new. And thats not what they're doing at all. No, what makes this novel is that they're using some slick hardware gear (FPGAs) to ensure that this attack is much more than an extremely efficient large scale dictionary attack (which has been shown already to be very effective in real life I should say). The novel thing here is that they're cracking DES very very quickly to ensure that they get 100% success on the attack.

The novel thing here is that they're cracking DES very very quickly to ensure that they get 100% success on the attack.

I think the real novelty is the offline part. This means that not only do active users need to ensure they are not broadcasting where they can be captured (i.e. PPTP on wifi is dead), but anyone sending zips of packet captures that include PPTP now needs to encrypt them as well - or there is a 100% chance it can be cracked by someone that intercepts it. I doubt the email thing happens every day for most people, but for security or network people troubleshooting a PPTP user, it occurs fairly frequently.

The novel thing here is that they're cracking DES very very quickly to ensure that they get 100% success on the attack.

I think the real novelty is the offline part. This means that not only do active users need to ensure they are not broadcasting where they can be captured (i.e. PPTP on wifi is dead), but anyone sending zips of packet captures that include PPTP now needs to encrypt them as well - or there is a 100% chance it can be cracked by someone that intercepts it. I doubt the email thing happens every day for most people, but for security or network people troubleshooting a PPTP user, it occurs fairly frequently.

You've been able to do it offline forever as well, thats not novel. All the MSCHAPv2 exploits work offline. The novel part now is that no matter how long and strong your password is, it can be hacked.

Note that typically with WPA(2) Enterprise *PEAP*-MSCHAPv2 is used, which uses TLS to protect the MSCHAPv2 challenge-response. In this case the attack can be stopped by verifying the certificate.

I thought something like this was probably the case. Thanks for your post as it confirms my understanding. So an attack against this would be to exploit user's general poor practice of accepting certificate warnings, and set up another AP with the same SSID and security settings, just different certificate, and see how many people connect to that.

There actually isn't a warning for the user, it's a checkbox labelled "Validate Server Certificate". If it's checked, then it will only connect if the certificate has a valid/trusted CA chain. In an company this is almost always configured via group policy, so it's really up to your administrator. I believe it's unchecked by default, and things can be enough of a PITA to set up that once things are working admins will often leave it unchecked.

gmerrick wrote:

One hopes that they cannot use the exchange server self-signed cert problem to further crack this. I didn't realize that MD4 was still used for anything.

When selecting to validate the server certificate, you have to explicitly select which root CAs you will trust, so it's not a problem (assuming you are validating the server certificate). Of course if your organization doesn't have a CA set up then you will be using a self signed cert and won't be able to validate the cert.

Note that typically with WPA(2) Enterprise *PEAP*-MSCHAPv2 is used, which uses TLS to protect the MSCHAPv2 challenge-response. In this case the attack can be stopped by verifying the certificate.

I thought something like this was probably the case. Thanks for your post as it confirms my understanding. So an attack against this would be to exploit user's general poor practice of accepting certificate warnings, and set up another AP with the same SSID and security settings, just different certificate, and see how many people connect to that.

There actually isn't a warning for the user, it's a checkbox labelled "Validate Server Certificate". If it's checked, then it will only connect if the certificate has a valid/trusted CA chain. In an company this is almost always configured via group policy, so it's really up to your administrator. I believe it's unchecked by default, and things can be enough of a PITA to set up that once things are working admins will often leave it unchecked.

--snip--

OS X will prompt if the certificate isn't trusted, and as far as I can remember in the most recent versions of the OS requires that the trust is established before it will connect. This trust can be established during the initial connection to the WiFi network.

3DES ~= DES(DES(DES(key))). What was implemented was DES(key1)+DES(key2)+DES(key3) where key3 == two bytes and the rest padded with zeroes...

Impressive fail. What is worse is how long it will take for a stronger protocol to be as widely deployed.

If it's that broken, why did it take so long to figure out this attack?

The hard part was having the dedicated hardware from Pico Computing to pull off the attack on the keyspace.

With that being said, wouldn't GPUs be the poor man's "Pico"?

GPU's and FPGA are entirely different beasts - you can't quite call either one a poor man's version of the other. What Pico is doing is pretty cool though - very much at the forefront of the FPGA industry.

What they did was implement some fixed-function algorithm on the FPGA to speed up the brute force calculation. It's analogous to performing video transcoding using Intel Quicksync (fixed-function) vs Nvidia CUDA (GPU accelerated general code). If you get the algorithm right - fixed-function hardware will always win. Cool thing about FPGA's though - it is reprogrammable

What was implemented was DES(key1)+DES(key2)+DES(key3) where key3 == two bytes and the rest padded with zeroes...

Impressive fail.

I have difficulty believing this. Please let it not be true.

If it is true, then in the long history of Microsoft's crypto stuff ups this has got to be the worst.

You are forgetting that 3DES i.e. 168bit crypto was "military grade" by US export standards at the time (1990s). It was probably intentionally done like this to avoid export controls. The extra two DES blocks were just to fill the field to be computable with LM auth (which is even worse). This is a VERY old protocol... The strange thing is MS upgraded windows Auth to NTLMv2 which uses HMAC-MD5 for the 128bit challenge response calculation (which is still pretty secure - the MD5 collision attacks have no bearing on HMAC-MD5) so why didn't they upgrade MS-CHAP? My guess is their hardware VPN "partners" started whining about upgrade costs and MS didn't want to rock the boat as usual...

gmerrick wrote:

Yuhong bao wrote:

Note that typically with WPA(2) Enterprise *PEAP*-MSCHAPv2 is used, which uses TLS to protect the MSCHAPv2 challenge-response. In this case the attack can be stopped by verifying the certificate.

One hopes that they cannot use the exchange server self-signed cert problem to further crack this. I didn't realize that MD4 was still used for anything.

Ironically MD4 isn't the problem. It's collision resistance is basically zero and its preimage resistance is lower than it should be ~2^100 but neither matter for key derivation which is just about converting a x byte PW into an evenly distributed 128bit key. The only property for key derivation needed is non-invertability which MD4 provides (you can't get the password from the MD4 hash without brute force).

Also exchange doesn't use MSCHAP, it uses SPNEGO i.e NTLM or kerberos. So as long as you mandate NTLMv2 you should be fine. Note: if using outlook anywhere (RPC over https tunneling) it can potentially use basic auth so you really shouldn't use self-signed there (well you shouldn't anyway)...

There's nothing novel about this. But everyone complaining about it is missing the point.

A protocol which has been broken for a long time now is still being used as if it were still secure. This stops immediately. That's what this story is about. It's a wake-up call.

The novel thing here is that they can always crack it 100% no matter how good the password. Basically its the final nail in the coffin of MSCHAPv2.

Sadly my experience in security tells me that they're not going to get the wakeup call, and at best, they get it, then some genius will implement something new with a nearly identical flaw and we'll start this all over again.

Why is an authentication scheme using DES and MD4 still being used in production anyway, both were rendered weak by modern computers(as far as I know)?

Is it just a case of vandor to lazy to update?

Because the protocol is really old and try as we might it is actually very hard to totally move away from legacy systems in the real world; no matter how bad they are. Still DES and MD4 are not the worst parts of MSCHAPv2. Although they are attacking those algorithms here, MSCHAPv2 is fatally flawed due to the way they handle the last DES block.