MS: Windows Phone 8 Wi-Fi Vulnerable, Cannot Be Patched

Freshly Exhumed writes "Microsoft advises that a cryptographic problem in the PEAP-MS-CHAPv2 protocol used in Windows Phone 8 to provide WPA2 authentication allows a victim's encrypted domain credentials to be collected by an attacker posing as a typical WiFi access point. Redmond further states that this problem cannot be patched, although a set of manually entered configuration changes involving root certificates on all WP8 phones and on WiFi access points will apparently address the issue. WP7.8 phones are likewise vulnerable."

Oh please

[Anonymous Coward]

Every phone which implements CHAPv2 is vulnerable, because that's a broken algorithm. You can't patch it, because then it wouldn't be that algorithm anymore and stop working with other implementations of the algorithm. The right thing to do is to encapsulate it in a securely encrypted tunnel, but to have that, you have to check the certificates. If you don't secure the tunnel, an attacker can MITM you and crack the CHAPv2 inside. Not properly securing tunnels is a problem everywhere.

Re:Why can't it be patched?

[Anonymous Coward]

because the root certificate being installed is for the internal domain and Microsoft doesn't have that certificate.

please note: this is only for PEAP using domain credentials. not standard WPA2-PSK that just about everyone uses.

Re:Why can't it be patched?

[aaron44126]

It says in the article that configuration changes must be made on the WiFi access points as well.

Parent must be spam

[jabberw0k]

Real Slashdot users don't have girlfriends (or boyfriends for that matter).

Re:Why can't it be patched?

[fuzzyfuzzyfungus]

If it can be fixed through manual configuration changes, why can't a patch make those same configuration changes?

The configuration change is enabling server certificate validation. If the network is set up for this, all is well: just like SSL, the server demanding the credentials from the client connecting to the network has a certificate, which the client can verify before attempting to authenticate. Spoofing becomes effectively impossible without access to a suitably signed cert.

However, if the authentication server is not set up to use a certificate, or is set up to use a certificate not signed by one of the CAs in the client's list of trusted authorities, enabling server certificate validation will cause the client to freak out and never attempt to authenticate (since validation will, correctly, fail.)

Re:Oh please

[jrumney]

Every phone which implements CHAPv2 is vulnerable

Other phones don't automatically give out your corporate domain login details using it though.

Re:Oh please

[93 Escort Wagon]

Well, to be fair to the blasters and lambasters:

- This is a protocol developed by Microsoft, and it's fundamentally broken
- Knowing it's fundamentally broken, Microsoft still included it on their phone and enabled its use by default

Where does it say that it cannot be patched?

[Fosterocalypse]

You put it in quotes so I assumed you were quoting one of the two links you put in but neither state that. I know there's a lot of anti-MS people here but stick to the facts please. I understand that the current solution they offer is not a patch but something that the user needs to do manually, but seriously when you quote something use what they actually said. "Recommendation. Apply the suggested action to require a certificate verifying a wireless access point before starting an authentication process. Please see the Suggested Actions section of this advisory for more information." - from: http://technet.microsoft.com/en-us/security/advisory/2876146 [microsoft.com]

Re:Where does it say that it cannot be patched?

[UnknowingFool]

I think technically the flaw cannot be patched, but the vulnerability can be mitigated. Just reading it, it seems to be an inherent problem with the algorithm. Presumably it is analogous to the DNS cache poisoning flaw that Dan Kaminsky [wikipedia.org] discovered in 2008. DNS was patched to make it less vulnerable but the flaw existed in the protocol itself. There was no truly way to fix it without re-writing the protocol. Replacing it with DNSSec was the recommended course of action.