The smartphone-based attack wreaks havoc on Android and iOS smartphones.

If you use an Android or iOS device to connect to a Microsoft Exchange server over WiFi, security researcher Peter Hannay may be able to compromise your account and wreak havoc on your handset.

At the Black Hat security conference in Las Vegas, the researcher at Edith Cowan University's Security Research Institute in Australia described an attack he said works against many Exchange servers operated by smaller businesses. Android and iOS devices that connect to servers secured with a self-signed secure sockets layer certificate will connect to servers even when those certificates have been falsified.

"The primary weakness is in the way that the client devices handle encryption and do certificate handling, so it's a weakness in SSL handling routines of the client devices," Hannay told Ars ahead of his presentation on Thursday. "These clients should be saying that the SSL certificate really doesn't match, none of the details are correct. I won't connect to it."

Hannay has developed an attack that uses a WiFi network to implement a rogue server with a self-signed certificate, rather than one issued by a trusted certificate authority. Vulnerable devices on the same network that try to connect to their regular Exchange server won't reach that intended destination. Instead, it will initiate communications with Hannay's imposter machine.

The use of an SSL certificate to protect an Exchange server is designed to preclude precisely this kind of man-in-the-middle attack. Devices are supposed to connect only if the certificate bears a valid cryptographic key certifying the service is valid. But that's not what always happens, the researcher said.

Android devices that connect to an Exchange server with a self-signed certificate will connect to any server at its designated address, even when its SSL credential has been spoofed or contains invalid data. iOS devices fared only slightly better in Hannay's tests: They issued a warning, but allowed users to connect anyway. Microsoft Windows Phone handsets, by contrast, issued an error and refused to allow the end user to connect.

Once a phone connects to a rogue server used in Hannay's experiments, a script he wrote issues a command to remotely wipe its contents and to restore all factory settings. He said it's also possible to retrieve the login credentials users need to sign in to their accounts. Hannay said a malicious hacker could then use that information to login to the legitimate account.

"It's really simple and that's what's disturbing to me," Hannay said. The whole attack is just 40 lines of python and most of that is just connection handling."

As stated earlier, the attack works only against phones that have connected to an Exchange server secured by a self-signed SSL certificate. Hannay said most organizations with fewer than 50 people use such credentials, rather than paying to have a certificate signed by a recognized certificate authority.

Google and Apple didn't respond to an e-mail seeking comment for this article. A Microsoft representative said members of the company's Exchange team are looking in to the report.

Update

After this article was published, Microsoft officials released a statement that read: "Microsoft has thoroughly investigated the claim and found that this is not a product vulnerability; rather, the issue lies in how Android and iOS devices handle authentication of certain kinds of certificates. No Microsoft product is affected by this technique."

The officials didn't contest Hannay's claim that the technique allows him to spoof Exchange servers, so it's not clear why they say Microsoft products aren't affected. They declined a request by Ars to publicly clarify the statement.

69 Reader Comments

At my company we don't use a self-signed certificate. However, when connecting through public WIFI at hotels, I have seen the invalid cert message come up on my Android phone. Very odd...

The article claims it does not affect those who have signed certificates. But isn't the truth that the signed certificate only protects the user if he refuses to accept non-signed certificates? In other words, if the end user doesn't know better, can't you spoof them, regardless of their Exchange settings?

Only if the phone absolutely refuse to recognize self-signed certs, can you say your users are invulnerable from this attack, or am I wrong?

Microsoft Windows Phone handsets, by contrast, issued an error and refused to allow the end user to connect.

And, @Pinko!, people using a self-signed cert aren't asking to have their devices not bother to verify it. If you're only using the cert for internal use, why not self-sign? The problem here is that some devices seem to just be taking the view that a self-signed cert doesn't need to be validated.

I wonder if failure to do this properly could result in devices not actually being valid ActiveSync clients, and if so what action MS might be able or willing to take?

iOS devices fared only slightly better in Hannay's tests: They issued a warning, but allowed users to connect anyway

I can confirm that.

The only way this is news is that this researcher has managed to make a name for himself by demonstrating the technique. All client/server traffic is vulnerable to MITM attacks. Unless traffic is encrypted and secured with a valid certificate and the client checks the validity of that certificate. When the client device doesn't validate the certificate then the MITM attack is again possible. That's what this guy had done.

Quote:

Ummmm.... If you use a self signed cert you are asking for this.

Yes and no. This attack is possible with a perfectly valid cert on the Exchange server from Verisign or Thawte or whoever. It's just the social engineering aspect of the attack on the iOS devices: users with a self signed cert would have gotten used to the iOS certificate warning. They had already seen the invalid cert dialog box and clicked "Accept". If that dialog pops up again because they are being redirected to a server in the middle they'd be more likely to click "Accept" again, whereas the user with a valid cert is more likely to get suspicious.

At my company we don't use a self-signed certificate. However, when connecting through public WIFI at hotels, I have seen the invalid cert message come up on my Android phone. Very odd...

The article claims it does not affect those who have signed certificates. But isn't the truth that the signed certificate only protects the user if he refuses to accept non-signed certificates? In other words, if the end user doesn't know better, can't you spoof them, regardless of their Exchange settings?

Only if the phone absolutely refuse to recognize self-signed certs, can you say your users are invulnerable from this attack, or am I wrong?

Hannay said if an Android devices are trying to connect to a server that is protected by a certificate signed by a CA, the handset will display a "comms error" and that there's no way to override it. He made no reference to the option to refuse self-signed certificates. I've contacted him for clarification and will update accordingly.

Has anyone asked Ms. Cowan whether she tried this from a WP7/7.5 handset?

Windows Phones don't connect to Exchange servers with self-signed certs unless the cert is manually added to the device. This was actually a point of annoyance on Microsoft Answers as it turned out a lot of places were running Exchange server with self-signed certs and their shiny new handsets were refusing to connect to the Exchange server.

At my company we don't use a self-signed certificate. However, when connecting through public WIFI at hotels, I have seen the invalid cert message come up on my Android phone. Very odd...

This tends to be caused by host redirection, in which the hotspot's DNS server resolves all unauthenticated requests to a portal IP address where you can log in and activate your session. The idea is that you're most likely opening a web page the first time you're trying to use the Wifi, but your mail client's requests for things like HTTPS-proxied ActiveSync connections get redirected as well. In fact, thanks to network state change notifications in your mobile OS, mail clients are likely to hit the network before you even have a chance to open a web browser and get redirected so you can log in. The result is a warning that the server you're connecting to — the portal server — is not the server you're expecting — the mail server. It's all very annoying, but in truth, it's SSL doing what it's supposed to do.

I've always figured this kind of attack was possible, in exactly this scenario. It wouldn't take much for such a "portal" server to detect an SSL request and a self-signed cert and quickly forge a self-signed cert to replace it, thereby snagging all your traffic in transit. All the necessary interception and redirection is already happening. MITM is really all these portal servers are doing. They're just ostensibly trustworthy. It grinds my gears.

Quote:

Only if the phone absolutely refuse to recognize self-signed certs, can you say your users are invulnerable from this attack, or am I wrong?

Yep, don't use self-signed certs, and this class of attack is thwarted.

This kind of problem, SSL clients not really doing sufficient validity checking, is probably a lot more common in applications than we'd all like. It's extra work to actually care about SSL validity and present a UI to the user if there is trouble, it's extra work to think about these issues at all, it's much easier just to sprinkle some magic SSL sauce on your app, ticket the checkbox and be done.

If you are going to use a cert signed by your own CA which isn't pre-recognized on the client then you should have to load your CA public cert into the device to do validity checking. Some variation of cert pinning should also be standard. It's too bad that apps can use the provided crypto and not automatically handle these issues in a safe and easy manner.

Has anyone asked Ms. Cowan whether she tried this from a WP7/7.5 handset?

Windows Phones don't connect to Exchange servers with self-signed certs unless the cert is manually added to the device. This was actually a point of annoyance on Microsoft Answers as it turned out a lot of places were running Exchange server with self-signed certs and their shiny new handsets were refusing to connect to the Exchange server.

Yesterday's annoyance winds up being today's saving grace. Go figure.

Lazy and Cheap comes to mind for an email server with a self signed cert exposing an endpoint to the outside world. Phones are the outside world and not on your network. Why risk anything with email in this regard when email leaks have burned companies over and over again. For a public facing email server, spend the $199 a year and get the Exchange Cert from a vendor. At least you won't socially condition all your users to allow man in the middle attacks. Small price to pay if you ask me.

The other cheap option is to use certificates issued from a private CA, with the CA cert installed into the phones. This way the phones don't have to be set to ignore certificate errors, and will complain if the certificate gets changed.

Has anyone asked Ms. Cowan whether she tried this from a WP7/7.5 handset?

Windows Phones don't connect to Exchange servers with self-signed certs unless the cert is manually added to the device. This was actually a point of annoyance on Microsoft Answers as it turned out a lot of places were running Exchange server with self-signed certs and their shiny new handsets were refusing to connect to the Exchange server.

Weird. I thought even WM required the cert be manually put onto the device as well, though I haven't dealt with that since WM5.

Could never get it to work well with that POS Treo 700w.

But here is my question: Without the actual self signed cert on the phone, imported (seems there is that option on 4.0), how else would it know it is invalid? I ran through the setup of an exchange acc on android. I wonder if unchecking "accept all ssl certificates" does anything?

Hasn't this been common knowledge for a very long time? Self signed SSL certs are are terrible idea for anything internet facing unless you're at least using certificate pinning (which given various CA compromises is something the industry should be doing anyway).

The "refuse invalid SSL certs with no override" is pretty much the only workable solution to users just ignoring warnings as well.

The other cheap option is to use certificates issued from a private CA, with the CA cert installed into the phones.

There's seriously people using self-signed certs instead of this?

If you're running Exchange, you're running at least Windows Server Standard and Active Directory. And that gives you, at least, the most hobbled level of Windows PKI. You can generate web server certificates on this platform.

At my company we don't use a self-signed certificate. However, when connecting through public WIFI at hotels, I have seen the invalid cert message come up on my Android phone. Very odd...

This tends to be caused by host redirection, in which the hotspot's DNS server resolves all unauthenticated requests to a portal IP address where you can log in and activate your session. The idea is that you're most likely opening a web page the first time you're trying to use the Wifi, but your mail client's requests for things like HTTPS-proxied ActiveSync connections get redirected as well. In fact, thanks to network state change notifications in your mobile OS, mail clients are likely to hit the network before you even have a chance to open a web browser and get redirected so you can log in. The result is a warning that the server you're connecting to — the portal server — is not the server you're expecting — the mail server. It's all very annoying, but in truth, it's SSL doing what it's supposed to do.

Right, I understand all that, but what bothers me is the fact that, even though I don't use self-signed certs, my Android is allowing me to say "ok" to the invalid cert. If I were oblivious, I might say "ok," and get hacked.

My question earlier was, even though I put a domain verified cert on my Exchange server, couldn't a user accidentally agree to use an invalid cert on Android, and get hacked? The fact that I did the "right" thing on the server wouldn't protect my user, in that case.

Granted, the user would see a warning they hadn't seen before, and that alone would protect them more than if I had disabled warnings of self signed certs.

There are some exploits that I do not understand how they can happen. I mean, Google recently disclosed a hack how to evade the sandbox which included a whole lot of steps and very detailed knowledge of how Chrome, the sandbox and everything worked. This may be really hard to prevent. But this one is like having a locked door and a key to open it, but still allowing everybody to enter with just any other key.

It's the same as me putting myself down as a reference for a job application, the company accepting me, and then wondering what went wrong.

The difference is that, in theory, you should compare (manually) the certificate hash with a known good value and then save the result for future use. Once you've done that, the theory is that the client device should (silently) accept the certificate you validated and promt you again if it changes: the user is then notified of the possible problem.

Of course, that can only work when users have some level of technical know-how and can resist the urge to click "accept certificate" in case of unexpected prompt. As long as the client behaves properly (save your initial choice for the specific certificate and only prompt you if it changes), it can be quite safe (that's how most SSH connections are done and registered)

Good thing this is cheap and easy to fix. A ssl cert is only around $90 a year..

SSL certs for exchange are a bit more complex because you usually require SANs on them and Ca charge (a lot) more for these.

You don't. The only time you need to use SubjectAlternateName is when you present multiple services on multiple domains from the one sever/IP. So, when might this be an issue?

(1) If you expose your Exchange Client Access Server to the Internet directly and this is the same server that you use internally. This is a bad idea anyway. But you can always create a second set of IIS Virtual Directories for the Exchange web services and thus use a different certificate for them.(2) You publish multiple services from multiple backend servers using Threat Management Gateway or Squid (or some other reverse proxy; good luck getting them to deal reliably with Microsoft's abuse of HTTP though).

In case (2) a wildcard certificate is still open to you (from ~$150). Microsoft recommends against wildcard certs because - and only because - *Windows Mobile 5* can't handle them. WiMo 6 and everything else has no problem.

The situation where you want a SAN certificate is when you have multiple public facing servers and multiple domains. Then you have less administrative burden of dealing with a multitude of public CA certificates. It's unfortunate the Microsoft literature for Exchange 2007 (during which time WiMo 5 was still present) seems to be gospel on the matter.

So if I connect to an Exchange server (valid or not) I'm forced to give whoever is running said server the power to wipe my phone?

Yup. You're bound by Exchange ActiveSync. So don't connect your personal device to it unless you can acknowledge someone else has the power.

This sounds awfully fucked up. Why does a groupware server need to delete soundhound, gmail, or any other application?

Lost or compromised device. Perhaps this will change in the future now that iPhone and Windows Phone can have remote wipes initiated by the user. Windows 8 is the first "EAS" client I've seen that doesn't wipe the device, it just removes the EAS account when a remote wipe is sent.

sprockkets wrote:

Entegy wrote:

adminfoo wrote:

Has anyone asked Ms. Cowan whether she tried this from a WP7/7.5 handset?

Windows Phones don't connect to Exchange servers with self-signed certs unless the cert is manually added to the device. This was actually a point of annoyance on Microsoft Answers as it turned out a lot of places were running Exchange server with self-signed certs and their shiny new handsets were refusing to connect to the Exchange server.

But here is my question: Without the actual self signed cert on the phone, imported (seems there is that option on 4.0), how else would it know it is invalid? I ran through the setup of an exchange acc on android. I wonder if unchecking "accept all ssl certificates" does anything?

Like any device, it has a list of trusted authorities in which to accept certs from. Yourself is not a trusted authority.

Any Exchange server admins able to comment on how much control you actually have over personal devices connected?

This is just a curiosity question. I know if I'm running stock android, pin lock is forced for example but with a custom rom its not.

And is the wipe actually app specific, or just a general device wipe? (ie can you actually see apps and or data on my phone?)

Using just Exchange, I cannot see your personal data on the phone. But I will see your phone number. I can wipe your entire device and see when you've last synced. I can keep wiping your device if you restore a backup until you remove the account from your phone when you have no network connection. Depending on EAS implementation, I can control certain hardware and software features such as camera and browser access.

And custom ROMs are the reason I don't allow Android devices. If I cannot reliably depend on the same feature to work consistently across devices, it's a no-go.

So, is there a feasible way to configure the iPhone to reject self-signed certificates for ActiveSync? We have a legit Verisign Certificate for our Exchange server. I'd rather have the iOS devices straight up refuse to connect, instead of showing a warning message that the user can override.

Android is also a nightmare of non-standard implementations. Google publish specs on exactly what a plain Android build will do but then vendors can (and do) change it. This does include some naughty things, like the device claiming it can do something it can't in order to pass a policy restriction and be allowed to connect. On top of that, there are scripts for rooted devices which lets them connect to restrictive policies (required 10 character alphanumeric device password, for instance) but ignore the restrictions. This is, IMO, one of the other weak points of the whole ActiveSync protocol - it relies on the device telling you what it supports and you have to believe it.

This is slightly better with Exchange 2010 with the black/whitelisting of devices, or quarantining those it doesn't know about, but ultimately you either need 3rd party MDM or issuing (and requiring) client certificates to control exactly what connects.

Back to the original issue - for iPhone-using orgs like ours, all I really want is a Configurator profile setting to say "don't allow untrusted certs" so that a user won't be asked whether they want to bypass it in the scenario mentioned.