Mobile Security Lab

Thanks to the DeepSec team, the presentation of mseclab team “Hijacking Mobile Data Connections 2.0: Automated and Improved”, held in November 2009 in Vienna, has been published at vimeo website.

This presentation explains some techniques, effective still today, to hijack device originated Mobile Data Connections, on any phone equipped with OMA client. Furthermore, automated technique is shown to retrieve victim’s IMSI in order to select the right APN Mobile Operator Configuration; how to perform an SSLSTRIP attack has also been demonstrated.

We’ve just come back from HITB held in Amsterdam; we really had a good time there, and we would like to thank the whole staff for all the effort they put on it .

During our presentation “Hijacking Mobile Data Connections: State of Art” we discussed some relatively simple methods to extend the scope of the attack to iPhones/iPod/iPad and Android-based devices.

Regarding Apple products we suggested, as a countermeasure, to update the iPhone to iOS 4; we didn’t give any details to back up this, basically because iOS 4 had been released just a few days before and, apart from noticing some changes in the way it handles remote reconfiguration, we didn’t have time to perform full tests and report the results. In order to avoid any possible misinterpretation, we would like to point out a few additional details on this topic.

Apple’s iOS 4 features a new constraint when installing a Configuration Profile: if the user already has a Configuration Profile, previously installed, he can download a new one, but he cannot install it because an Error box like the one below is shown.

The only way around this is to manually remove the old one (if it’s not locked) and then proceed with the installation.
On the other hand, if the user has no installed Profile, he can download and install the new one in the usual way.

This mechanism protect all users that already have an installed profile; sadly, however, it does nothing to address the vulnerability of users that don’t have any installed profile.

Additionally it must be considered that this raises another issue, having to do with how phone backups are managed. When the user backups his handset,  configuration profile is stored in the backups itself, and is recovered when he later restores it; this also applies to locked profiles (PayloadRemovalDisallowed=true), that is, profiles that the user cannot modify or remove. In iPhone OS 3.x the user can work around this by installing a new profile and using it instead of the malicious one. In case of iOS 4, on the other hand, this is not possible anymore (for the reason explained above), so the user has no simple way, apart from reflashing the handset (and losing all his backup data) to restore it to a safe condition. The only solution, at this point, relies on the availability of an older backup, performed before the attack was carried out, and thus not including the malicious configuration profile.

Another point that deserves attention, as shown by the screenshots below, is related to the details of the new configuration that the handset shows to the mobile user before he accepts the it.

As opposed to the iPhone OS 3.1 behavior, iOS 4 presents to the user additional information about the Certificate used for signing the mobileconfig file, e.g. “Subject Name”, “Issuer Name”, “Signature Algorithm” (but also other useful information such as the email address which has been used when requesting the certificate itself), before the mobileconfig installation  actually takes place.

By analyzing these information, the user should be able to decide if the configuration source is to be trusted or not. While this provides some useful information, it must be noted that only the first few characters of the strings are displayed.

Hence a smart attacker can forge a long enough common name and email address, to hide the suspect part of the strings.

Furthermore, the security flaws disclosed by Cryptopath blog still works, since a signature-only certificate is valid to sign a configuration profile and Safari root CAs list is used to validate the signature.

So, while iOS gives some degree of additional protection to (probably) most users, we must conclude that there is still an open vulnerability windows, that an attacker can exploit to perform the attack.

We are glad to take part, as speakers, to the first European edition of the “Hack In The Box” security conference, to be held from June 29th to July 2nd in Amsterdam – A big thank to all the HITB staff !
We are going to present our talk “Hijacking Mobile Data Connections: State of the Art”, where we’ll show how it’s possible to hijack “iPhone and Android” data connections. Further information are available at HITB web site.

See you in Amsterdam .

We’ve just come back from DeepSec, and we’re really glad to have attended the conference.
We’d like to thank Michael and the whole DeepSec staff for supporting us (and for their great tips!).
For everybody wishing to see the presentation, it is available here.

See you at next DeepSec conference ( and have a good Schnitzel )

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

Read the rest of this entry »

We’re glad to announce that we’ve been selected as speakers at DeepSec 2009 in Vienna, on November 17-20. We will present several intriguing enhancements of our “Hijacking Mobile Data Connections” attack. We are now working on the talk; its title will be “Hijacking Mobile Data Connections 2.0: Automated and Improved”, and it will include live demos of how the attack looks like from both user’s and attacker’s perspective, together with the latest findings of our research. Hereafter follows the abstract, also been published on DeepSec’s site.

So, see you in Vienna…

Read the rest of this entry »

During the same days of our Hijacking attack presentation at BH EU ’09, we read of “a-sort-of” SMS hijacking attack performed on Windows Mobile phones. On the demonstrating video here a binary SMS is sent to a Windows mobile phone, and the browser suddenly pops up, opening an attacker specified URL. That’s the typical behaviour of an handset receiving a Service Load (SL) message, and actually this type of attack had already been discussed (here and here). We feel that this might still be a somewhat underestimated risk in the mobile environment, as Service Loading is supported by many platforms apart from Windows Mobile; but before going deeper into that, let’s explain what Service Loading messages are and what are they for.

Service Loading is a part of the WAP Push protocol suite for OTA (Over The Air) provisioning of mobile handset. It is often cited together with Service Indication: like Service Loading, Service Indication is used to carry URL addresses to the handset in a binary SMS message; but it is rather meant to notify the user of a certain URL in order to be, for instance, added to the bookmarks, and not necessarily to open it at once.

Let’s see the basic structure of a SL message:

As any other WAP protocol element, it uses an XML representation; the actual SL element have only two attributes: an URI (commonly said to be URL) and an action; the latter can be “execute-high”, meaning the content is executed in an user-obtrusive (visible) manner, “execute-low”, meaning the content is executed in a non user-obtrusive (invisible) manner, and “cache”, meaning that the content should simply be put in browser’s cache, not executed neither displayed. The default is execute-low. In order to be sent, this document must be converted to WBXML format (a compressed binary representation), then stuffed in an SMS message according to WSP protocol.

Upon receiving such a message, if the URI is an HTML page, the phone will load and show it with the default web browser; if it is an executable program, it will download and execute it, possibly in a silent way. The risk associated with this feature, especially without user’s awareness, should be obvious also for non tech savvy readers; that’s why most handsets come with some sort of security policy associated with WAP Push messages.

We have conducted a test on two largely used devices, a Nokia N95 and a Sony Ericsson C905, to check how they deal with Service Loading messages.

Read the rest of this entry »

We hadn’t the chance to be at BH USA ’09, but we’ve seen there have been several talks about mobile security; and there seems to be a solid consensus in considering this as the new frontier of security. Mobile devices nowadays support many complex interfaces and protocols: GSM/UMTS network, IP network, Bluetooth, Smart cards…; this doesn’t only mean exposing more surface to attacks than traditional computers, but also that the mix of several small, unrelated security flaws could result in a much bigger one.
Black Hat USA 09 archives list a speech by Jesse Burns, of ISEC Partners, about Android’s security model, while Kevin Mahaffey, John Hering and Anthony Lineberry of Flexillis presented a non device-specific fuzzer for mobile platforms.
But the most impressive work was presented by Charlie Miller and Colin Mulliner; they managed to inject SMS messages past the radio section directly into phone’s processing chain. This technique has been applied to iPhone, Android and Windows Mobile; not having to rely on the network to send messages gets rid of the associated costs, and allows for a fast and thorough test (fuzzing) of SMS processing stack. The results were up to the expectations: actually, both Android and iPhone could be crashed by malformed binary messages, allowing for effective Denial of Service attack, while Windows Mobile is still under scrutiny. The vulnerability on iPhone was also found to potentially allow for remote code execution with full privileges, without any user advice nor any way to stop messages.
While Apple had to quickly release a security update, SMS is confirmed as one of the most investigated attack vectors.
However, other general issues could have a significant impact on mobile security; Moxie Marlinspike’s “More Tricks for Defeating SSL” is an effective attack against (almost any) popular web browsers, but it affects connections from mobile devices as well. As we pointed out, SSL is the last line of defense against the “Hijacking mobile data connection” attack we discovered, so knowing it can be attacked isn’t reassuring at all. We’ve began testing the attack on various mobile platforms, and we will post the result as soon as we can.

In the last days, there has been lots of talking about weak security of Google ‘cloud’ services: after the authentication on encrypted protocol (HTTPS), all data exchange between user and Google servers takes place on plain HTTP, thus allowing for easy attack or eavesdropping. Wired reports that, for this reason, several security experts signed a public petition to ask Google to protect complete user sessions with SSL. From our mobile enviroment perspective, we cannot but to completely agree.

The abusing of the OMA provisioning mechanism, supported by a great extent of modern mobile devices, as we pointed out, demonstrates beyond any doubt how concrete the risk is. Ironically, while provisioning protocol makes abusing mobile devices configuration so easy, many sites do use secure (SSL) protocols, but not when accessed by mobile devices; probably because, given their reduced computational power, these are considered unfit to cope with encryption in an effective way.

Continuing our exploration of what the consequences of Data Session Hijacking could be, we went a step further. In Proxy Fun we reported that hijacking by means of remote proxy configuration only affects HTTP traffic (and HTTPS as well), that could be considered as a limitation but, by contrast, allows for some HTTP-specific hijacking techniques more easily than a remote DNS configuration.
Actually, the original attack we presented at BH Europe 2009, based on DNS configuration, was still unable to intercept and handle HTTPS connections, thus still being ineffective with sites that used this protocol for authentication.
Proxy configuration makes hijacking effective on a new mobile site category: those (email providers, social network, e-commerce) that use HTTPS protocol for logging in, and then switch to HTTP protocol for the rest of the session. Exactly like Google – that, by the way, is still more secure than several services that make no use of SSL whatsoever; we have found several ones.

So, hijacking by means of a proxy configuration means passing HTTPS authentication without interception by CONNECT method, then getting the session cookie (called GX for Gmail) from subsequent HTTP requests and using it to hijack the user session – a technique called “sidejacking”. You don’t have to think that only exchanged data is at risk; the attacker gets authenticated to the server and can operate on the server as if he was the user. An attacker, for example, could write, send and delete mails on behalf of the victim user or delete the user’s documents.

Sidejacking, or using the victim session cookies to impersonate him, was demonstrated by the founders of Errata Security at BlackHat Usa 2007. Also an evolution of this technique has been proposed, called forced sidejacking, that makes use of ‘HTTP 302 Temporarily moved’ web pages for collecting victim cookies.

In the following video we show how remotely configuring an LG KM900, in order to force it to go through an evil proxy server, looks like; then the attacker easily grabs the GX cookie released within a Gmail mobile session and uses it in his browser to hijack the mobile session.

In the previous post Hijacking Mobile Data Connections , we pointed out how an attacker could gain full control on mobile data connections originated by mobile phone.

This could be achieved by reconfiguring the DNS address on victim’s mobile phone with one controlled by the attacker, by means of OMA provisioning SMS. However, during our tests some mobile phones resisted to this attack, due to the fact that, despite supporting OMA provisioning, they don’t honour configuration requests of DNS address, neither locally nor remotely.

But, as we said, OMA provisioning allows for setting other parameters than DNS; among them there are the proxy settings.

In mobile world, a proxy isn’t different from any other environment: it is a software component that is located between a client, in this case a mobile phone, and a server on Internet; any standard HTTP proxy can be used for an HTTP mobile client.

In our experiences we have noticed that the proxy settings are widely used by several operator services, mainly for delivering MMS messages.

On the other side, an attacker could use proxy configuration to hijack the victim traffic, HTTP and HTTPS, and redirect it towards an IP address under his control. Still the victim, after having installed the rogue configuration, will be unaware that a third party, the attacker, is eavesdropping the data traffic.

Hijacking by means of a proxy configuration has some differences with respect to DNS configuration, apart from being supported by a few more phones:

• Proxy component is enough to redirect user’s data traffic.
• The proxy port could be set to a different value, other than the standard TCP/80. This could be useful for the attacker to overcome some firewall restriction.
• While the operator could block DNS traffic to outside of its network, in order to mitigate attacks to DNS settings, it may be difficult to restrict access to HTTP proxies over Internet;

The limitation, of course, is that only HTTP-based services could be hijacked; this excludes email and most dedicated clients.

To be more technical, let’s shows a simple proxy configuration:

The complete proxy XML configuration file can be downloaded here.

A generic explanation of an XML configuration file has been provided in our paper downloadable from here.

In order to provide new proxy configuration it is necessary to use the two characteristic, PXPHYSICAL and PXLOGICAL as described in provided in Provisioning Content Specification.

PXLOGICAL characteristic is used to introduce a new proxy configuration inside the current XML configuration.

PXPHISICAL characteristic, defined inside PXLOGICAL characteristic, specifies the proxy server information needed to use it: proxy address, port number and other proxy related parameters, if needed.

The following two pictures show the proxy configuration on LGKM900 where it is not possible to configure a DNS address.

A suitable program must now be used to compile this configuration in a binary SMS message; then, the message can be delivered to the victim by sending AT commands to a mobile phone attached to the PC.