Forgot your password?
typodupeerror
Handhelds Security Wireless Networking

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

Posted by timothy
from the is-there-a-workaround-for-the-workaround? dept.
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."
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by metrix007 (200091) on Thursday August 08, 2013 @09:31AM (#44508607)

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

    • by i kan reed (749298) on Thursday August 08, 2013 @09:32AM (#44508619) Homepage Journal

      Because the NSA won't let them?

    • by Anonymous Coward on Thursday August 08, 2013 @09:35AM (#44508659)

      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.

      • by Anonymous Coward on Thursday August 08, 2013 @09:42AM (#44508747)

        watch as your actual-factual answer languishes at 0 while the "funny" comment about the NSA gets +5 Insightful.

        • by Anonymous Coward
          looks like I was wrong.
      • Re: (Score:3, Interesting)

        by 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.

        The scary thing (if i read this correctly) is that someone could theoretically sit outside a business where a lot of WP8 users are, listen for a while to snoop the wireless details (SSID, AP's mac, whatever they want) and then set up a fake hotspot in the parking lot. As phones leave the building's wifi perimeter, they will try to re-auth to the fake hotspot and give away their user's credentials. The user can then turn their wifi gear toward the building, and log in as an insider with probably tons-o-acc

        • by robmv (855035)

          Or treat wireless like an internet connection, require VPN access over it

          • by Anonymous Coward

            Or treat wireless like an internet connection, require VPN access over it

            Too many people (mostly in the corporate world) believe that "defense in depth" means multiple layers of the highest encryption possible, and users who complain about having to authenticate 9 times just to check their email won out and required stored/cached single sign on so that you can breeze through all 9 layers as soon as you unlock your laptop with your domain password. It turns out that all that authentication shot them in the foot. Plus, if any ol person can belly up to your corporate WiFi, that m

          • Or treat wireless like an internet connection, require VPN access over it

            How would a VPN help? This vulnerability affects the authentication with the access point. If you authenticate, get an IP, and try to open a VPN connection, it's too late.

            • by robmv (855035)

              Because you can't access the company network without access to the VPN. Serious enterprise networks do not trust only the wireless encryption, simple as that

              • Because you can't access the company network without access to the VPN. Serious enterprise networks do not trust only the wireless encryption, simple as that

                All of this happens before you even get an IP address.

                I'm going to repeat myself:

                How would a VPN help? This vulnerability affects the authentication with the access point. If you authenticate, get an IP, and try to open a VPN connection, it's too late.

                • Maybe I shoud repeat the GP agan.

                  No, a VPN by itself does not matter, what matters is that you put no resource besides internet accessible to whoever just authenticated into your wireless network. Anything that matters is inside a firewall, that people can traverse using a VPN.

                  It does not make the attack fail, it just protects everything that is important.

                  (And about having to authenticate at the access point, and the VPN, well, both are automatic, it shouldn't be a nuissance.)

                  • by Bert64 (520050)

                    And if both the vpn and the wifi (and devices beyond the vpn too) use the same authentication?
                    Many organisations are set up this way, using windows domain logins for everything, so if you own one layer you have them all.

                  • Maybe I shoud repeat the GP agan.

                    No, a VPN by itself does not matter, what matters is that you put no resource besides internet accessible to whoever just authenticated into your wireless network. Anything that matters is inside a firewall, that people can traverse using a VPN.

                    It does not make the attack fail, it just protects everything that is important.

                    (And about having to authenticate at the access point, and the VPN, well, both are automatic, it shouldn't be a nuissance.)

                    The credentials for the WiFi AP and the VPN are likely the same (domain credentials).

                    Even if they're not, guess what the client does after hitting up that spoofed WiFi AP?
                    Hint: It tries to establish a VPN connection.

                    Even if it is smart enough to require some authentication before trusting the VPN (why would it when it's not smart enough to do that for the AP?), you can see everything the victim sends out (thinking it's on a legit AP), and you can join the legit AP and poke around to get the VPN's details.

                    E

        • by DrXym (126579) on Thursday August 08, 2013 @12:08PM (#44510649)
          Sounds like Microsoft has most to fear on their own campuses since I doubt that there are many other businesses with a high enough concentration of vulnerable phones who would be worth the risk.
        • Re: (Score:3, Interesting)

          by r1348 (2567295)

          Luckily, there's not such thing as a "business where a lot of WP8 users are", except maybe for Microsoft itself, but I wouldn't bet my life on it...

          • Luckily, all of the WP eight users on the planet are under this large radio-proof dome currently so everything should be OK.
        • 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.

          The scary thing (if i read this correctly) is that someone could theoretically sit outside a business where a lot of WP8 users are, listen for a while to snoop the wireless details (SSID, AP's mac, whatever they want) and then set up a fake hotspot in the parking lot. As phones leave the building's wifi perimeter, they will try to re-auth to the fake hotspot and give away their user's credentials. The user can then turn their wifi gear toward the building, and log in as an insider with probably tons-o-access to the internal network and the crown jewels.

          Who cares if it's only a few businesses or that "most people" dont bother with it, the potential for targeted abuse is so huge that I don't see any sane enterprise keeping this turned on. They are better off just handing out "secret" WPA keys to their users than bothering with auth that basically ensures they are vulnerable.

          The only thing you get is the encrypted credentials. Is PEAP-MS-CHAP v2 vulnerable to any practical attacks?

        • by LBt1st (709520)

          "a business where a lot of WP8 users are"

          Good luck finding one of those!

        • by cbhacking (979169)

          Note: "give away their credentials" is a little bit strong. Using custom hardware, CloudCracker can break MS-CHAPv2 in about a day at a reasonable cost, but it's still not feasible to do a massive attack of capturing everybody's creds unless you've got a fair bit of time and money to burn.

          On the other hand, if you capture the *right* person's credentials, then that's all you need anyhow.

    • by aaron44126 (2631375) on Thursday August 08, 2013 @09:47AM (#44508797) Homepage
      It says in the article that configuration changes must be made on the WiFi access points as well.
      • by wmac1 (2478314)

        Perhaps it means to change the configuration on "genuine access points" in a way that clients are not required to set vulnerable settings on their phone.

    • by fuzzyfuzzyfungus (1223518) on Thursday August 08, 2013 @10:04AM (#44508987) Journal

      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.)

      • by Strider- (39683)

        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.

        The fundamental problem you run into however, is that at the point where you need to verify the certificate you don't yet have a network connection. In a PEAP environment, the certificate is presented to the client before layer 3 connectivity has been established. The client obtains the certificate, sees that it has been signed by a valid CA, but it can not actually verify that the certificate is being presented by the right server since, well, there's no network connection yet. It's really one of those

        • The fundamental problem you run into however, is that at the point where you need to verify the certificate you don't yet have a network connection. In a PEAP environment, the certificate is presented to the client before layer 3 connectivity has been established. The client obtains the certificate, sees that it has been signed by a valid CA, but it can not actually verify that the certificate is being presented by the right server since, well, there's no network connection yet. It's really one of those chicken and egg problems, there's no good way to resolve it.

          You resolve it the way all browsers and sane operating systems resolve it. You load/keep a list of trusted root certificates against which the device can validate the server certificate by itself out of band of the wifi communication channel.

          There are even extensions to TLS where OSCP can be performed over TLS such that revocation checking does not require network access.

    • by ISoldat53 (977164)
      Maybe they can find some programers somewhere that can re-write it.
      • Scripting and patching need to operate at an "interesting" security level. What does this tell us about the system security?

        There is no way to validate the script thus there is no way to patch it.

        Perhaps like an Android update an entire new system image could do the job but that is not a patch.

        File this under the definition of "is" (thanks Bill).

    • by sjames (1099)

      Because it only works by pre-sharing a generated certificate between the AP and the client. MS can't make that happen with a patch.

  • So that's why all of the wifi pineapples sold out at DEF CON...
  • Oh please (Score:5, Informative)

    by Anonymous Coward on Thursday August 08, 2013 @09:35AM (#44508653)

    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.

    • by tysonedwards (969693) on Thursday August 08, 2013 @09:41AM (#44508731)
      The fact that we have such lax tunnel security is a travesty.
      I propose that we immediately bring in the TSA to man the entrance to every tunnel, for our children!
    • by Anonymous Coward
      Quiet you, we're trying to bash Microsoft here.

      Knock Knock.

      Who's there?

      Windows Phone 8.

      Windows Phone 8 who?

      Exactly.
    • Re:Oh please (Score:5, Informative)

      by jrumney (197329) on Thursday August 08, 2013 @10:07AM (#44509025) Homepage

      Every phone which implements CHAPv2 is vulnerable

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

    • But lambasting Microsoft and Windows phones is a lot more entertaining than some boring technical and cohesive explanation.

      • Re:Oh please (Score:5, Informative)

        by 93 Escort Wagon (326346) on Thursday August 08, 2013 @10:28AM (#44509295)

        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

        • by am 2k (217885)

          Just like PPTP! I think I can see a pattern there.

        • And all platforms that support EAP support PEAP with MSCHAPv2.

          Any network that does PEAP with MSCHAPv2 using credentials thay are usee dor any other service is vulnerable, unless the clients will require certificates signed by a trusted CS cert.

          Android authenticating via FreeRADIUS to Samba password hashes to allow access to an AP running OpenWRY would be vulnerable by default.

    • I think Al Gore has a lock box full of tubes that has room to store this. Lock boxes are safer than tunnels.

    • On a scale of WEP to AES, how broken is PEAP-MS-CHAP v2?

      • by cbhacking (979169)

        Assuming you don't use certificate validation for the SSL tunnel over which the MS-CHAPv2 communication occurs (which requires configuring each access point manually), then you can spoof the SSL connection (trivially), at which point it's just down to MS-CHAPv2. This algorithm boils down to three DES operations - not 3DES (which has an effective key strength of 112 bits, lower than the weakest AES key but still practically impossible to crack) but three independent and parallelizable DES operations. Each on

  • Wait (Score:4, Insightful)

    by jayhawk88 (160512) <jayhawk88@gmail.com> on Thursday August 08, 2013 @09:35AM (#44508655)

    What's so special about Windows Phone 8/7.8 with regards to this issue? If you're not requiring a cert validating the identity of your radius server/access point/whatever, ANY device is going to be vulnerable to a spoofed SSID kind of attack, right?

    • by wmac1 (2478314)

      Don't take the fun out of it please :) !

    • The problem is that you can't really turn off this behaviour and it does it automatically. Every client (laptop, tablet, phone, other wireless device) that does this fully automatic, may leak Active Directory account data that could be used to actually log on to file servers as well. It's not just MicroSoft that has this problem with PEAP, but that it's apparently not possible (at least not easily) to put some safety measures on the phone so you can mitigate this. I'm sure there will be other PEAP client im
  • by blcamp (211756)

    This is quite the "Oops" on the part of MSFT which, even if this is nothing more than anti-MS FUD, can ill-afford this kind of bad press with a platform which has less than 4% of market share.

    • by ackthpt (218170)

      This is quite the "Oops" on the part of MSFT which, even if this is nothing more than anti-MS FUD, can ill-afford this kind of bad press with a platform which has less than 4% of market share.

      Probably the result of an office memo, which came down from the top, worded something like this: More animations, more inexplicable navigation, don't worry about security or adhering to the APIs, we can fix that later .. or not.

    • by 1s44c (552956)

      This is quite the "Oops" on the part of MSFT which, even if this is nothing more than anti-MS FUD, can ill-afford this kind of bad press with a platform which has less than 4% of market share.

      The Microsoft mantra has always been that they only get cracked because they have most of the market share. Here they have 4% of the market share and they are still getting cracked.

      Maybe the things MS make are just no good?

  • by Trailer Trash (60756) on Thursday August 08, 2013 @09:42AM (#44508737) Homepage

    They ought to just call the guy who bought one and explain it to him.

  • Never met a Zune user, either.
    • by DogDude (805747)
      Hello! Nice to meet you. My girlfriend has one, too.
      • Parent must be spam (Score:3, Informative)

        by jabberw0k (62554)
        Real Slashdot users don't have girlfriends (or boyfriends for that matter).
      • So it's 1984, and I'm in a high school math class where I have to write a very simple calendar program on a Sperry computer, never knowing that years later the guy that did the same thing on the Zune would have got a zero and be held up as an epic failure to programmers today. How the fuck do you forget leap years? How the fuck do you mess things up so badly that your device will not even turn on on some days due to that calendar bug? How bad is the quality control to miss such a thing that was a high sc
        • So it's 1984, and I'm in a high school math class where I have to write a very simple calendar program on a Sperry computer

          And you've inadvertently created the trans-temporal internet protocol? Kudos!

          • by dbIII (701233)
            Thanks for demonstrating to the kids of today the "this is your brain on drugs" thing from way back then.
        • by gstoddart (321705)

          How the fuck do you forget leap years?

          Gross incompetence, and a total lack of awareness of the Gergorian calendar.

        • by oji-sama (1151023)

          How the fuck do you forget leap years?

          The same way you forget the month December from calendar I guess. It is strange, though.

        • by Teun (17872)
          Because the guy was cheap?
          And/or he grew up with and is accustomed to a Moon cycle based calender?

          Still doesn't explain how it (in a market leading company) got past peer review...

        • by cbhacking (979169)

          First point: it didn't "forget" leap years, there was just a logic error in the special-case code that handled them. Forgot to test, perhaps, but not actually forgot.
          Second point: Microsoft didn't write that code. It was part of the clock module that was built into the hardware that they used. Again, perhaps they should have tested it themselves, but the clock module's code quality itself wasn't Microsoft's fault.

          • by dbIII (701233)

            Microsoft didn't write that code

            Their product, their responsibility no matter who they contracted it out to, thus it was Microsoft's fault.

    • by Horshu (2754893)
      Another variant of the old "I don't know anyone who voted for Nixon" line.
  • Every year there is a story on slashdot where the perfect response is 'Use Windows, get screwed.' It seems things have not changed much in the last 15 years.

    • by QilessQi (2044624)

      Some folks argue that the stories (or, rather, the presentation and discussion of them) are unfairly slanted against Microsoft. For me, it comes down to this:

      When a company has a warchest in excess of 500 billion US dollars, as well as immense market penetration in a variety of domains -- desktop operating systems, web browser, word processing software, spreadsheet software, etc. -- it is expected to have its act together.

      • Some folks argue that the stories (or, rather, the presentation and discussion of them) are unfairly slanted against Microsoft. For me, it comes down to this:

        When a company has a warchest in excess of 500 billion US dollars, as well as immense market penetration in a variety of domains -- desktop operating systems, web browser, word processing software, spreadsheet software, etc. -- it is expected to have its act together.

        (CompanyX AND 500 billion dollars) != "its act together"

        For example:

        Windows ME

        Windows Vista

        Zune

        Games for Windows Live/Steam DRM

        Surface RT

        Xbox One and their DRM strategy (until it was revoked)

        • by QilessQi (2044624)

          Oh, I agree ... Microsoft doesn't have its act together. My point was that given its war chest and the demands of its current user base, it should. There's simply no excuse.

          I think that's why some of us on /. come down harder on Microsoft then on smaller companies. Sure, all software shops produce buggy code from time to time. And many vendors ship products that they hope will be game changers but that, ultimately, people aren't interested in. But most of these companies don't have a zillion dollars t

      • Just a nitpick, you're a wee bit off there with $500B. Actual cash on balance sheet is $76B. Market cap is approximately $273B.

  • Redmond further states that this problem cannot be patched

    One more nail in the coffin of a product which has been dying since it was released.

    Come on guys, just how bad of a job are you doing these days?

  • by Fosterocalypse (2650263) on Thursday August 08, 2013 @10:41AM (#44509461)
    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]
    • by UnknowingFool (672806) on Thursday August 08, 2013 @11:07AM (#44509785)
      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.
      • by WaffleMonster (969671) on Thursday August 08, 2013 @01:13PM (#44511475)

        I think technically the flaw cannot be patched, but the vulnerability can be mitigated. reading it, it seems to be an inherent problem with the algorithm.

        This is not the case here. It is a flaw in the MS implementation of a technology rather than the technology itself. A flaw by the way does not exist in other versions in Microsofts own products if they are configured properly.

        Presumably it is analogous to the DNS cache poisoning flaw that Dan Kaminsky 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.

        There was no way to fix SYN attacks against TCP without replacing it either...oh wait yes there was cookies were added to mitigate the problem and today are widely deployed. The same solution for DNS continues to sit on a shelf and collect dust for no sane reason.

        http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03 [ietf.org]

        Replacing it with DNSSec was the recommended course of action.

        April 1st must come late this year cuz DNSSec is glued on top of DNS and has all the same insane transport issues that we continue to allow DNS to have. Only now now with significantly higher computational cost and DDOS amplification factors which just might give SNMP with public community strings a run for its money.

        • There was no way to fix SYN attacks against TCP without replacing it either...oh wait yes there was cookies were added to mitigate the problem and today are widely deployed. The same solution for DNS continues to sit on a shelf and collect dust for no sane reason.

          The inherent problem [networkworld.com] is that DNS uses a 16-bit number for the query id as a means to authenticate the response. Changing DNS to use a larger number would require a major re-architecture of the protocol. The short-term patch was to pair the id with a 16-bit port number to increase the possible combinations. But that was only a short-term solution.

          April 1st must come late this year cuz DNSSec is glued on top of DNS and has all the same insane transport issues that we continue to allow DNS to have. Only now now with significantly higher computational cost and DDOS amplification factors which just might give SNMP with public community strings a run for its money.

          Um what? If I said WPA is vulnerable, replace it with WPA2, would your response be "Wait, WPA2 is glued on top of WPA!" Also I didn't recommend DNSSec. Dan Kami

          • The inherent problem is that DNS uses a 16-bit number for the query id as a means to authenticate the response.

            Correlating responses aint the only problem deploying cookies would solve. Amplification of bogus requests is a huge issue large scale deployment of DNSSEC will have made much worse.

            Changing DNS to use a larger number would require a major re-architecture of the protocol.

            I bet you didn't click on the ID link describing how to fix it did you? But yea major re-architecture..blah blah blah..

            Um what? If I said WPA is vulnerable, replace it with WPA2, would your response be "Wait, WPA2 is glued on top of WPA!"

            WPA analogue does not work. It is more like SSL v3 vs TLS v1.

            Also I didn't recommend DNSSec. Dan Kaminsky and others did: "DNSSec has been proposed as the way to bring cryptographic assurance to results provided by DNS, and Kaminsky has spoken in favor of it."

            Don't care about popularity contests or who said what.

            The reality is DNSSEC is glued atop DNS and it does inherit all of the same transport problems

            • I bet you didn't click on the ID link describing how to fix it did you?

              I did and, first of all, your link describes a proposed standard 5 years ago. I do not see that it has been accepted as a standard to IETF. Second in Eastlake's presentation [ietf.org] he notes: "Provides weak authentication of queries and responses. Can be viewed as a weak version of TSIG. No protection against “on-path” attackers, that is, no protection against anyone who can see the plain text queries and responses"

              I read that as it probably would work if adopted but it is only slightly more secure

  • Reeks of a data funnel for the NSA
  • by WaffleMonster (969671) on Thursday August 08, 2013 @11:59AM (#44510529)

    I personally contacted MS security people about this years ago before WP8 was released and they told me they would look into this and get back to me guess what I tried to follow up and they never did.

    To be very clear the problem is complete lack of necessary levers and knobs to validate the TLS certificate and common name of certificate in WP7-8. Without these options TLS is trivially MITMd this leaves only MS-CHAPv2 which has known to have been completely and publically broke for years.

    What is worse they don't even try there is not even a leap of faith latch as there is in other mobile platforms whereby if the cert changes it at least tells you it is different... The system never warns you or anything.

    To be even more clear this is not a problem that Microsoft just stumbled on... They knew full goddamn well what the implications of leaving those levers and knobs out of WP7 were... They knew about them circa 2002-2003 when their wireless supplicant was released for XP. They just didn't give a shit.

Life is difficult because it is non-linear.

Working...