Windows Phone dodges Black Hat 2012 certificate vulnerability bullet - other smartphones not so lucky...

A recent paper presented at Black hat 2012 by Peter Hannay has demonstrated a vulnerability in how iOS and Android deal with certificates whilst operating with an Exchange Server. The good news in this report is that Peter was unable to trick Windows Phone 7.5 devices using the same methods.

Using a man in the middle attack combined with a generic fake certificate, they were able to gain some traction in sending a command to iOS and Android devices to commence a device wipe. When devices are connected via Active Sync they commit to accepting certain responsibilities, one of the most important and sensitive of which is the wipe command. They tested off two sets of Exchange 2010 servers. One running with a self-signed certificate, a very common configuration for small business and another using a certificate from a trusted certificate signing authority.

Android devices accepted the fake certificate and wiped with no user interaction or warning on the Exchange server that was operating using a self-signed certificate. The Android device would not wipe whilst connected to the trusted certificate-holding server.

On both the self-signed and trusted certificate servers, iOS rolled over and wiped the device in both instances, only displaying a new certificate warning white flag whilst doing so. In both cases, a normal user would likely accept the certificate warning. You know, users do that kind of thing to get on with their lives.

Windows Phone on the other hand would not accept the new certificate in either case and would need to have one manually installed for such an attack to be possible. Hopefully these papers will lead to a strengthening of security on Android and iOS devices. In the meantime, we hope that more companies would wake up to the benefits of Windows Phones. Whilst we certainly do not wish to see any ill come of this, we can at least gloat about our platform being a little more savvy when it comes to accepting gifts from strangers over Wi-Fi pineapples?

Want to read more about Wi-Fi Pineapples? Need a place to vent some steam at the injustice of certificate signing authorities? The comments are open for business; we look forward to your contribution!

Source: Blackhat 2012; via WP Sauce

  • Is that a huge monitor you're holding the phone in front of?
  • The Apples, Androids and most of the press will blame it all on Exchange.
  • Would be funny if that happened, considering the tester used the same methods on all platforms.
  • Amazing... Do you have any link of press morons blaming exchange?
  • I was suspecting
  • Android has its goods but accepting a fake certificate is something I expected as I seen many fake apps/pirate markets work with no problems, on the other hand shame on iOS.
  • heh, well I say let's get to wiping those Androids!  That's one way to get rid of that scourge!
  • That's a terrible idea.
  • Har har... I'll assume this was meant to be funny. It wasn't.
  • I don't think was necessary.
  • i'll join you :D
  • Go ahead, wipe my Galaxy Nexus. I'll just sign in and get everything back again anyway!!!
  • I only ever thought this resulted in ActiveSync headache in a lab setting. Not so! Looks like it is good.
  • Another reason to love Windows Phone.
  • they should call windows phone 
    Secure windows phone castle 
  • Good to hear. Can't wait have a wp in my hands
  • It would be interesting to try this on Jelly Bean. I'm not the tester though :D
  • It worked on Froyo and then again on Honeycomb. If it when from 2.3 to 4.0 which is a couple years of OS dev, what makes you think 4.1 would be much different? 4.1 is an upgrade to 4.0 equivalent to WP 7.5 upgraded to 7.8. Its still the same kernel, just new features with a new look and feel. I bet it still works on jelly bean too, just a guess though.
  • I have a problem about this... At work I have an Exchange Server with certificate self-signed and Windows Phone doesn't allow me to access to my server? How can I do? Thank you!
  • A third-party full certificate from GoDaddy for Exchange (multi-domain) is like $80/year. Small business or not, do it right and sign it properly. It makes life so much easier for your users, and it guarantees you're protected for Android and Windows Phone.
  • Hey there. You have to manually install the certificate. I had to do the same thing with the company I work for. In my case, a link to the certificate is available online. I just clicked, downloaded and installed. Your IT dept. should be able to provide you a similar link. Good luck!
  • Email yourself the certificate (gmail, hotmail etc) and install on your phone
  • That's what I like to hear
  • People get what they pay for I guess
  • Windows Phones are a lot cheaper than iPhones
  • Siri: You got an email from the Prince of Nigeria. He says if you wipe your phone, he'll deposit $1,000,000.00 into your bank account. I went ahead and did that for you. Goodbye.
  • haha--- good one
  • funny, after i recieved my WP i kinda freaked out about how i have to install a cert and everything. Now, i know why :P
  • Professionals everywhere: BlackBerry is not the only secure system. And Microsoft has a few other advantages and tools like this Office thing that might be handy....
  • This can't be true.
  • It's true as it's a pain to install a self-signed cert when you want to!
  • I assume that SSL is not enough so what can I do to make my Galaxy Nexus more secure thus less vulnerable to a possible attack like this?
  • I'm a Windows Phone / Microsoft fan. I own a Nokia Lumia 800. I work as an IT admin and there is nothing but Windows on the network (barring 3 Linux appliances). Exchange 2010, Win Serv 2010 R2. Right, that's out of the way. For this "hack" to work, the attacker has to:- A) Poison a DNS server to direct web requests to the fake Exchange Server.
    B) Go through the hassle of setting up a fake certificate or more elaborately, trick a certificate authority into issuing them with a cert they shouldn't have.
    C) Guess the target company's internal domain name (assuming they're using domain\username format of authentication)
    D) Guess the username of each user(could be determined via security logs / firewall activity I suppose)
    E) Most hilariously, guess the passwords of the victims, because unless both ends agree on the credentials used, no connection can occur. Please, someone point out a method of extracting a password from an authentication attempt, otherwise this is non-news.
  • Andriod fanboys are invading.  Time to wipe them. But really as average user, this means crap to me. Lol.