Mobile Security Lab

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

(more…)

Symmetric algorithms are often used for encrypting embedded and mobile firmware images in order to protect code and data confidentiality, AES-CBC being a typical choice.
Firmware files are usually also fully signed, but, in our experience, we met cases where encryption of some regions was the only security measure, relying only on the confidentiality of the key itself.

The lack of integrity protections, that is sometimes regarded as a minor issue in case the encryption key is maintained secret (e.g.: in hardware), may leave open some attack paths that, in some very specific cases, allow an attacker to introduce modification in selectively targeted plaintext regions.

These ideas, even if not necessarily new or applicable in a wide range of cases, are, nonetheless, here presented with the intent of stressing the need for proper integrity protection, even if the encryption key is considered secret.
Scenarios are presented for CBC mode of a generic symmetric encryption algorithm, but they may be applicable also to other modes.

(more…)