Breaking Microsoft's PPTP Protocol

Some things never change. Thirteen years ago, Mudge and I published a paper breaking Microsoft’s PPTP protocol and the MS-CHAP authentication system. I haven’t been paying attention, but I presume it’s been fixed and improved over the years. Well, it’s been broken again.

ChapCrack can take captured network traffic that contains a MS-CHAPv2 network handshake (PPTP VPN or WPA2 Enterprise handshake) and reduce the handshake’s security to a single DES (Data Encryption Standard) key.

This DES key can then be submitted to CloudCracker.com—a commercial online password cracking service that runs on a special FPGA cracking box developed by David Hulton of Pico Computing—where it will be decrypted in under a day.

The CloudCracker output can then be used with ChapCrack to decrypt an entire session captured with WireShark or other similar network sniffing tools.

Tags: academic papers, cryptanalysis, cryptography, encryption, Microsoft, passwords

Posted on August 6, 2012 at 11:22 AM • 24 Comments

Comments

AlanS • August 6, 2012 11:55 AM

But see “Is WPA2 Security Broken Due to Defcon MS-CHAPv2 Cracking?”

http://revolutionwifi.blogspot.com/2012/07/is-wpa2-security-broken-due-to-defcon.html

JulesB • August 6, 2012 1:00 PM

Wow, that revolutionwifi article on how simple it is to protect yourself with TLS certificates reads almost as a parody of itself.

Francois Pesce • August 6, 2012 1:00 PM

This paper is similar to an oldest one: http://esec-pentest.sogeti.com/challenge-vpn-network/decipher-mppe-breaking-ms-chap-v2

stvs • August 6, 2012 1:13 PM

MS-CHAPv2 authentication is also used in several L2TP implementations: OpenVPN, OS X Server VPN, and others. Beyond PPTP, is L2TP+MS-CHAPv2 also known to be borked? Merely suspect?

AC2 • August 6, 2012 1:59 PM

@stvs

I didn’t think OpenVPN supports L2TP, but the link you’ve given is to the OpenVPN Access Server product (sold as opposed to the free core OpenVPN).

And that OpenVPN Access Server product has been ‘enhanced’ to support “PAM, LDAP, Active
Directory, and Radius Authentication
methods”.

From what I can see it is the Radius authentication where they are supporting CHAP and MS CHAP v2 authentication so maybe there is a gap there, I don’t know for sure…

Robert David Graham • August 6, 2012 3:31 PM

The part that most people miss (including me) is that it’s the DES that’s being cracked, not MD4. Thus, it breaks the protocol no matter the strength of the password.

Joe • August 6, 2012 4:41 PM

Why is it still using DES?

CD • August 6, 2012 4:59 PM

Its designed as though it was trying to be triple-DES – which is OK – but the implementation was bad, resulting in DES round + DES round + part of a DES round, which amounted to about 2^57.5 bits of “strength” instead of 565656 as 3DES should be. Due to some more implementation failures, the 2^56*2^56 is reduced to a single 2^56. The partial round was substantially padded with zeros so was effectively non-existent.

Like several of the things Moxie has done before, when he explains it you can’t help but laugh (or gasp) that no one had ever noticed it before. I was simultaneously impressed and horrified.

Joe • August 6, 2012 5:37 PM

CD, thanks for the explanation.

I’m no cryptographer or security expert, but wouldn’t it reduce the possible failure points of the implementation to just use AES or Twofish rather than have to go through the extra steps of chaining together 3DES?

Clive Robinson • August 6, 2012 7:29 PM

@ Joe,

… but wouldn’t it reduce the possible failure points of the implementation to just use AES or Twofish…

Yes and no…

You are forgetting a most important fact which Microsoft have considerable “previous” on, and that’s “backwards compatability”.

I won’t give specific details because it’s not just MS with previous, standards bodies and just about everybody else has as well.

What usually happens is you get revision N+X which adds a new protocol to do something, however it still has to work with revision N+X-1 so has to have a way to “fall back” to the old protocol.

Now this “fallback” is usually done with a “handshake protocol” at the begining of sesion initiation. The way it works is that the connecting party either sends it’s capabilities or requests the capabilities from the party being connected to. One of the parties then supposadly picks the highest common protocol and tels the other party to use that.

Hoowever this handshake is very rarely protected and thus is subject to a Man in The Middle attack. What happens is Alices machine instead of connecting directly to Bob’s machine actually routes through Eve’s machine. Eve then turns thee available protocols list into just one’s Eve knows how to break. The handshake will therfore pick a protocol that Eve can break.

Now as we know every developer instinctivly knows that users don’t want to see messages that might confuse them. So the protocol in use hardly ever get’s displayed to the users so they remain in blissfull ignorance and assume that as they are both using revision N+X they will be using the strongest protocol avaialable not the reality of the weakest.

As I said I won’t name names but one implementation of a secure tunneling system had as it’s lowest protocol “plain text”…

nobodyspecial • August 6, 2012 11:55 PM

@clive – GSM mobile phones being a notorious example

David Wachtfogel • August 7, 2012 12:11 AM

The usage of DES (instead of 3DES) is so blatantly bad that one suspects it was done on purpose to allow law enforcement to break it. Note that Microsoft defined this protocol in the late 20th century when US export laws prevented the export of strong cryptography.

Ljubljana322 • August 7, 2012 2:33 AM

Using DES implementation which is similar to non-existing 2DES cannot be safe by default (or by design 🙂 )

AlanS • August 7, 2012 8:12 AM

@JulesB

Also read the comments below especially the one referencing to Marlinspike’s earlier work on SSL.

Pat • August 7, 2012 8:56 AM

Just speculating, but program managers like to think “we have an authentication mechanism already, why bother implementing something new?” And thus we carry forward legacy protocols.

Seems just like another case of not being able to estimate future risks.

AC2 • August 8, 2012 2:10 AM

Re OpenVPN, from what details I can get my hends on:

OpenVPN setups that use a private CA and explicitly validate server certificates to prevent MITM would establish a secure TLS session between OpenVPN client and server
The additional authentication methods (including RADIUS using MS-CHAP v2) are triggered AFTER the TLS handshake is completed
But the communication between the OpenVPN server and RADIUS server is outside the TLS session established between the OpenVPN client and server
If that is not adequately secured it could be used to intercept the MS-CHAP v2 data and process via the hack

Anything I’ve missed?

sebastian buettrich • August 8, 2012 3:15 AM

@JulesB –

would you care to flesh out why you think revolutionwifi’s article reads like a parody? admitted, it brings some smiles to faces of people who need to walk not talk (” sending them a profile in an email … “), but it s also right on a few things – no?

thanks all for the discussion,
sebastian

T Chan • August 10, 2012 1:42 PM

@CS

Like several of the things Moxie has done before, when he explains it you can’t help but laugh (or gasp) that no one had ever noticed it before.

But it was noticed at least 13 years ago! Googling “holzer ms-chap” brought up a post by Peter Holzer on 1999-07-07:

On 1999-07-07 18:15:37 -0400, Burton Rosenberg wrote:
> the parallel structure of generating the challenge
> response (function ChallengeResponse() in
> http://www.ietf.org/internet-drafts/draft-ietf-pppext-mschap-v2-03.tex) cuts
> down the strength of the PasswordHash from 16 to 14 bytes.
7 Bytes. If you compute DES_X(C) for all 2^56 values of X, you will
discover both P1 and P2 (and P3, too, of course).

Bruce mentions “P. Holzer” in his paper paper (§4.1, p. 6); it’s unclear if Bruce was referring to a different observation or that he didn’t think the 1-bit improvement was worth mentioning:

It is clear that the NT hash can be recovered with just two DES exhaustive keysearches… Once the NT hash is recovered, all encrypted sessions can be read and the authentication scheme can be cracked with no effort. This shows that, even when using 128-bit RC4 keys, the MS-CHAP protocol provides at most the equivalent of 57-bit security².

² This has been independently observed by P. Holzer.

This attack is not news — it’s over 13 years old! The real news is that outsourced DES-cracking is now available for a small fee with very little technical knowledge or effort required — it’s not really worth my time writing a GPU DES-cracker when CloudCracker offers to do an exhaustive key search in under 24 hours for $200. Cracking-as-a-Service, anyone?

T Chan • August 10, 2012 2:35 PM

Addendum: I’ll also respond to Bruce’s post: I haven’t been paying attention, but I presume it’s been fixed and improved over the years.

The diff between draft 03 and RFC 2759 appears to be entirely minor corrections, whitespace changes, and editorial changes between the I-D and RFC boilerplate. Part of the problem is that the RFC merely describes MS-CHAP v2 as implemented (released in NT SP4 in October 1998, according to WP) — Microsoft’s backwards-compatibility requirements means they would need to write MS-CHAP v3 which is both embarrassing and not immediately useful, since MS-CHAP v1 would still need to be supported (and continued to be supported until Vista).

Change, especially protocol change, only seems to happen when attacks become “practical” — CAs using MD5 and the recent improvements to the “million message attack” are easy examples. Perhaps MS-CHAP v3 will be released, still with obvious security flaws, but I predict that MS-CHAP v2 will continue to be supported until 2020.

Personally, I’ve used PPTP several times in the past because DES seemed “strong enough”, though I make sure to dig around the settings and disable anything that looks like reduced security (40-bit RC4 and MS-CHAP v1, hopefully). I may have to reconsider this now, not because of any new attacks on MS-CHAP v2, but because DES is so thoroughly broken.

Joe • August 10, 2012 3:44 PM

Interesting posts. It seems that this attack is really against DES, or at the very least, their flawed implementation of 3DES. Backwards compatibility issues aside, would dumping DES from the list and requiring the use of AES or an AES finalist solve it? If it comes down to having to attack the algorithm in order to be practical, then this would probably do it.

Clive Robinson • August 10, 2012 4:54 PM

@ Joe,

If it comes down to having to attack the algorithm in order to be practical, then this would probably do it

No the protocol it’s self is iredeemably broken in it’s design and should just be consigned to the dustbin/trashcan of history.

That is because if you think about it, the interface to the basic algorithm would not work/be improved, just pulling DES out and dropping AES in would not increase the key space etc.

That aside you cannot ignore backwards compatability it’s one of the most serious threats to security there is and that we will face for the rest of our life times and possibly that of our children as well (read below as to why I think that).

@ T Chan,

Microsoft’s backwards-compatibility requirements means they would need to write MS CHAP v3 which is both embarrassing and not immediately useful, since MS-CHAP v1 would still need to be supported (and continued to be need to be supported until Vista)

This need for “backwards-compatibility” and the ‘attendent protocol fallback’ is not just MS’s failing but endemic in the industry and it has a couple of very serious downsides.

The first is for some reason “the industry” has decided that ‘users should not worry their pretty little heads’ over it, thus most applications give the user no warning the protocol being used is not the strongest.

The second is that the way the protocol fallback is usually negotiated at session initiation, it is usually compleatly insecure and open to a Man in The Middle Attack forcing the most insecure protocol on both ends.

I suspect that backwards compatability on this protocol failing will persist for a good deal longer than 2020, remember there are still NT 3.51 machines in use in “embedded” systems in industrial and telco equipment with design in life of +25years. That’s actually longer than it took DES to go from new to broken.

However the real problem is the way people design protocols they generaly do it in a lazy way without considering how the protocol will evolve when the parts inevitably and unavoidably become broken as they always will. If they actually took the time to create a framwork protocol with parts designed to be replaced (ie designed for maintanence) then life would in the longterm become considerably easier for all. But I predict that the “short term viewpoint” of “bodge it out the door double quick time” will prevail for the next generation or two.

As frequent readers know I bang on about this quite often especially with the likes of “smart grids”, “implantable medical electronics” and infrastructure (utilities etc) and industrial equipment where “Design in lives” would be upwards of five years and could easily exceed a third of a century. And due to minimisation of costs most systems will be put into service right at the end of the design life so could still be in service in more than two thirds of a century (think about the *nix signed 32 bit “time” issue as an example).

Andrew • August 31, 2012 6:25 PM

Hi All,

First, @AlanS thanks for reading my blog post and linking to it on Bruce’s prestigious blog 🙂 I’m an avid reader here as well.

@JulesB, I’m curious why you think my blog post is “almost a parody of itself?”

@sebastian, I assure you that I can “walk the talk” when it comes to Wi-Fi security. The email distribution comment was given as an example of a simple method of profile distribution for organizations that don’t have a more automated method in place, especially for BYOD or mobile device users. A more thorough approach would be a Wi-Fi network with a captive web portal redirecting to an MDM enrollment page (and direct integration with MDM by the network to enforce access controls based on the device status). I believe that I mentioned that as well in the post. But many small and mid-market organizations need simple options as well, so I try to be inclusive.

Anyways, thanks again for reading my post and for the discussion.

Cheers,
Andrew

ralph tyler • December 30, 2012 2:13 PM

PPTP is not a problem for everyday cloaking activities

In fact, it may be better to use this. If the NSA thinks you are doing something suspicious they can crack your session and find out you are up to nothing that disturbs them.

They aren’t going to bother you if you are using PPTP with BitTorrent to join a swarm sharing, say, a recent DVD screener, are they?

Clive Robinson • December 30, 2012 2:45 PM

@ Ralph,

PPTP is not a problem for everyday cloaking activities

It’s irredeemably broken, and this is.

Would you go driving in wet weather at high speed on bald tires? Would you alow a loved one to get in and drive such a vehicle?

Whilst you might not regard what you are doing as worthy of a reasonable level of security others might think otherwise and that’s where the problems start.

Take the case of a message board or equivalent where all the others use a secure system to access it, you use a PPTP based system and as a result your credentials get stolen, thus an unknown person can connect to the message board as you and thus see what you can or pretend to speak as you.

Either way can lead to problems for you or other users of the board who had assumed that users were usiing a greater level of security.

But it may be worse, many users have problems with passwords, as a result they use the same password or a very slight variatiion of it for all their onlline activities. Thus one set of credentials might be all that’s needed to open all the doors in such a persons online kingdom.

So it’s not safe and the advice given to all should be “Bin MS PPTP immediately”, much like the old advice about “Don’t use dull tools, they will bite you hard”.

Breaking Microsoft's PPTP Protocol

Comments

Leave a comment Cancel reply