Tricks for Defeating SSL: effectiveness test on mobile phones
SSL is the de-facto standard for securing communications between a user and a server against third parties. If someone is able to intercept, hijack, or have access in any other way to our network traffic, SSL provides an effective line of defense against eavesdropping.
Basically, all the devices have to do is check that the certificate protecting the connection to site “foo” carries a label (the CommonName Field) stating it belongs to site “foo”, and warn the user if it does not, something that is actually more complicated than it seems. At Black Hat USA 09, during the talk “More Tricks for Defeating SSL” given by Moxie Marlinspike, the “Null Prefix” attack was presented; the security researcher leveraged the fact that the string containing the domain name is represented using ASN.1 encoding as:
[domain_name length] domain_name
while many programs (browers, mail clients, and those used internally by CA’s) use the ‘C’ standard (null terminated-string) instead:
domain_name[\0]
So he generated Certificate Requests for domain names containing a null character (\0 or \x00), for example “paypal.com\0.thoughtcrime.org”, and managed to get them signed by an official Certification Authority; several CAs verified that the request came from “thoughtcrime.org”, while the applications thought the certificate belonged to paypal.com.
The researcher discovered that the applications built with Mozilla NSS Library ( Network Security Services that support SSL/TLS standards) are vulnerable to wildcard certificates generated in the same way. From a certificate request for *\0.thoughtcrime.org, it is possible to obtain a certificate valid for every domain!
Another attack variation consists of generating a certificate for “sitekey.ba\0nkofamerica.com”: the sitekey.ba domain is used for requesting validation but the resulting certificate is valid for the domain “sitekey.bankofamerica.com” for SSL implementations that simply strip the “\0” character.
The attack was fundamentally meant for desktop environments; we immediately wondered how it applies to mobile environments; so we’ve spent some time to test the attacks against some mobile devices. We’ve reported the results of our tests in the following table:
Test Results
Fortunately, we have found that most devices are not vulnerable to the attack, with the notable exception of Windows Mobile and a caveat for Blackberry.
Specifically, we tested whether the devices accepted a “simple” certificate (paypal.com\0.mseclab.com), a “wildcard” certificate (*\0.mseclab.com)and an “alternate” certificate (“sitekey.ba\0nkofamerica.com”).
Figure 1 - Smartphones not vulnerable
We verified that an Apple iPhone 3G, a HTC G1 and a Nokia 5800 cannot be fooled by any of the three types of certificates. Any connection to sites using these certificates is blocked and a warning message is displayed to the user (Figure 1).
Figure 2 - BlackBerry Bold Warning Message and Details
RIM’s Blackberry Bold identifies fake certificates and displays a warning too, but, for “alternate” certificates, the error messages look extremely odd (Figure 2) – something like “the certificate should belong to site foo, but instead it belongs to foo”. This could be deceiving for the user, making him think that there is some strange glitch and tempting him to ignore the warning. We contacted RIM’s security response team and they promptly handled the issue: a new software release has been delivered to the carriers and will be soon available to customers.
For further information, the advisory page from RIM will be shortly available at http://blackberry.com/btsc/KB19552.
Figure 3 - Windows Mobile Certificate Error
Windows Mobile 6 is not vulnerable to “wildcard” and “alternate” form, but it is to “simple” ones. When a user tries to connect to an https site with an invalid certificate, usually a warning message (Figure 3) is shown.
Figure 4 - No Warning Message
On the other hand, when dealing with a “simple” certificate, no warning is displayed at all (Figure 4); this means that any encrypted traffic exchanged with that specific site could be intercepted without any warning to the user. This is probably due to the crypto-API code of Windows Mobile being the same as Desktop Windows and we know of Desktop Windows’ vulnerability from Marlinspike’s original attack presentation. Fortunately, the ”Null-prefix” attack is not (yet) applicable to our data connection hijacking attack on Windows Mobile because it doesn’t accept all configuration messages. We have tried to send a standard provisioning message that is correctly received by the handset but identified as incorrect one.
We have contacted Microsoft’s Security Response Center, and they’ve told us they are aware of the problem and they’re “investigating and working to define the best plan of action”.
There are some circumstances however that lessen the impact of the attack for the general public:
- All Certificate Authorities emitting SSL certificates seem to have patched their services to reject domains containing null characters (possibly this happened after the attack presentation); so it should no longer be possible to obtain such a “valid” certificate.
- However there could be an unknown number of certificates in existence issued before the patching. These certificates will expire over time and there will no way to renew them – normally the lifespan of a certificate is one year. The attackers will have to hurry up…
- Given this, even if it is unknown, the number of domains that could be attacked is limited; at present there is no way to attack /any/ given domain – although we agree this is not completely reassuring nontheless…
It should be otherwise noted that, while any Certification Authority should already have checked the list of its issued certificates for fake domains and issued Certificate Revocations for them, Marlinspike pointed out that anyone who controls the network traffic from a device can easily defeat the CRL mechanism.
In conclusion, while the advice for everyone still remains to watch out for any warning when connecting to SSL- or HTTPS-protected sites, Windows Mobile users should be extra careful when accessing sensitive information until some security patch is released.