Today, Apple quietly released an update for their mobile operating system, iOS:
- iOS 4.2.10 for iPhone 4 (CDMA)
- iOS 4.3.5 for iPad, iPod touch (3rd generation), iPhone 4, iPod touch (4th generation), iPhone 3GS
Note: this is a semi-technical article – if you prefer, you can jump straight to the Layperson’s Summary at the end.
Like many users, I don’t connect my iPhone to iTunes that frequently, so it was only coincidence that I was offered this update so soon after its release while I was taking a backup this evening. As always, I took a look at the release notes (linked to above) and realised the wide and serious implications of the single flaw that is fixed in this update. It is fairly unusual for Apple to push out an iOS update containing only a single patch, but despite the quiet, no-fanfare release of this update, I believe it’s actually pretty serious. Also unusually, this vulnerability was patched within 10 days of Apple being notified – clearly they are aware of the significance of the problem.
The problem identified by Gregor Kopf of Recurity Labs (on behalf of BSI) and Paul Kehrer of Trustwave’s SpiderLabs is probably (in security terms) one of the most significant vulnerabilities I can recall being uncovered in iOS. For the technically-minded, it is similar in nature to a finding by Moxie Marlinspike in Internet Explorer in 2002, and relates to the way SSL certificates are checked for validity when opening a secure connection from your iOS device. This does not only affect connections made by the inbuilt Safari browser, but potentially also the e-mail application and any other third-party application that connects to remote SSL services and uses iOS built-in functionality to check their validity – this could include your bank, PayPal, Facebook, Amazon, etc.
Technically, the vulnerability is down to the fact that when verifying the validity of an SSL certificate, iOS only appears to do the basics – it checks that the certificate is signed by a recognised and “trusted” Certificate Authority, or there is at least a recognised Certificate Authority somewhere in the hierarchy of signatures (the certificate chain). What it wasn’t doing until this update, however, was checking that each certificate in the chain was actually allowed to sign the one below it.
I have a few SSL certificates, issued by a “trusted” Certificate Authority (CA), each of which includes properties (set by the CAS) that clearly state the certificates are not to be used to sign other certificates (the precise terminology here may differ depending on the tool you use to view certificate properties):
- Key Usage = Signing / Key Encipherment / Data Encipherment
- Enhanced Key Usage = Server Authentication / Client Authentication
- Basic Constraints = End Entity / is not a Certificate Authority
Reportedly, it is this last property that is not being properly checked by vulnerable iOS installations, although the others relate to the same limitations imposed by the Certificate Authority.
Technically, there is nothing to stop me signing new SSL certificates with other certificates that were not intended for the purpose, but browsers (and other applications checking SSL certificates) should always present a warning to the user when a certificate is being used for unauthorised purposes. iOS, until today, was not making this check, and therefore not warning the user that there was anything suspicious about the connection.
Using any of a number of Open Source tools, I am able to create new (fake) signed certificates for (e.g.) www.paypal.com, www.facebook.com, www.amazon.co.uk, onlinebanking.yourbank.com, etc. Theoretically, I could even create certificates ‘on the fly’ depending on what connections I see on a network, or create a single “wildcard” certificate that appears to cover every domain on the Internet. Now all I need to do in order to exploit the vulnerability reported today is to put together a couple of bits and pieces (laptop, a couple of scripts, wireless cards), wander down to my local coffee shop, bookshop or railway station, run up a fake “open” wireless Access Point with a common name, then wait for someone to connect to it and use an unpatched iOS device to access some SSL-secured Internet service. I can then intercept (and, in fact, modify) their traffic without their device alerting them to the problem. If I was in a really lazy mood, I could even do most of this with existing public tools (e.g. sslsniff and fakeap amongst others).
Of course, it is simple to intercept and modify non-SSL traffic anyway, but most people are already aware of this fact, and so generally check (when using public WiFi or GPRS/3G networks) that they are using SSL whenever they work with important or sensitive information. In fact, since the release of FireSheep, which increased public awareness in this area, many of the more popular online services (e.g. Twitter, Facebook, Google Apps, Yahoo!, etc.) offer users the option of using SSL for everything, and in same cases even enforce it.
[Note: in order to succeed in a proper undetected attack, there are a couple of other things I would need to do to get myself into a "privileged network position", as Apple describe it, but I've omitted that detail here to avoid handing too much information to the bad guys!]
Paul Kehrer is due to present this finding (amongst others) at DefCon 19 in August, in the context of demonstrating a new tool (SSLizzard) designed to help developers identify SSL-related vulnerabilities in mobile applications. I am pleased, however, that Apple were given time to resolve this before the presentation at DefCon, as there are already easy-to-use tools available to detect and exploit this vulnerability – although they would need to be used in conjunction with other techniques to enable fully-undetected interception and modification of traffic, those techniques are also not difficult to deploy.
Most of the industry analysis and commentary so far has been focusing on the fact that iOS users could be attacked while using open WiFi connections, since this is the easiest mechanism for an attacker to use, but it is worth noting that attacks could take place over any network connection over which the SSL traffic runs (including GPRS/3G data connections) – the only difference is that the attacker might need some more sophisticated (and expensive) equipment available to them.
There has also been some hint in the technical media that this vulnerability is unlikely to be exploited in the wild because Windows (or other) users on the same network would see certificate errors in their browser. This is true, if attackers were launching a rather unsophisticated exploit: it is not difficult to detect when an iOS-based device is present on a network, and in some cases it may even be possible to detect the version of iOS it is running. This means an attacker could target specific devices and simply ignore, or “pass through” all other traffic they intercept.
One significant fact also seems to have been given only minor coverage in mainstream reporting on this issue – the vulnerability has very likely been in iOS since it first came on the scene, and yet we have no idea whether anyone with malicious intent ever noticed (and exploited) it before Apple’s fix on 25 July 2011. Think about how long we have had iPhones, iPads, iPod Touches, etc. and how many times we have trusted SSL to protect us from anyone intercepting our traffic, or to confirm that the server we’re connecting to is what it says it is – theoretically, any one of those connections over the years could have been breached without us noticing.
Another concern with the patch, and (due to its very quiet release) the lack of general awareness of the problem – it does not apply to any Apple device that has fallen out of support (i.e. anything older than those listed at the beginning of this article). Users of older devices, or those that have been “jailbroken” and are hence also unsupported, will forever be vulnerable to this issue – this is doubly worrying as there is no simple method by which an iOS user can check the details of SSL certificates in use for websites, applications, etc. – some details can be viewed if you encounter an invalid certificate, but I can’t find anything in standard iOS that allows you to view the properties of “valid” certificates (if there is a way, I’d love it if someone could tell me where it is!).
Patch, patch quickly and cross your fingers that:
- There aren’t any other hidden problems in the iOS crypto layer; and
- Nobody other than Apple and SpiderLabs/Recurity knew about this problem before today!
In summary, there has recently been an update to all Apple mobile devices (iPad, iPhone, iPod Touch) currently under support that fixes a very significant problem with how those devices check the validity of SSL certificates. These certificates are used by your device to verify the authenticity of secure services, such as your bank, PayPal, social networking applications, even your e-mail. SSL certificates are also used to encrypt all traffic to and from those services. When using a secure connection, you would expect to be warned if the SSL certificate is invalid or has changed – prior to this update, you might not have received such a warning in certain circumstances, which means your traffic could be viewed and/or modified by anyone able to access the same network as you. This could happen across a public wireless connection or even your mobile data network without you being aware.
If your device is still supported, you can get the update in the usual way (by connecting to iTunes and accepting the update), but if you use an older device (or, in fact, a “jailbroken” device) there may not be an update available for you, and I am not aware of Apple planning to release one. If you have an unsupported device, I’m afraid your options are limited – just be very cautious when using any service that relies on SSL to protect traffic. I recommend that you only use such services on a network you completely trust.
Filed in: Mobile Device Security Issues and Vulnerabilities, SSL Weaknesses, Vulnerabilities and Exploits
Tags: ios security update, ios security vulnerability, ipad security weakness, iphone security advice, iphone ssl weakness, ipod touch security