Mobile Security Lab

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.

Here we are with another sample of our attack technique described in the “Hijacking Mobile Data Connections” post. Today we are going to show you how the attack can have a significantly deeper impact depending on the design of the target handset: specifically, some defects in the provisioning messages processing code, together with a less than optimal User Interface design, lead to a significant advantage for an attacker trying to compromise the device.
In this case no ‘social engineering’ or spoofed messages are required.

As described in our MSL-2009-001 advisory (“Samsung Missing Provisioning Authentication”), we have identified some handsets that don’t perform proper authentication of incoming SMS Provisioning messages. They never display the source of the message; moreover, and much more worrying, they accept both authenticated and unauthenticated provisioning messages without giving to the user any hint of the nature of the message itself. To install the configuration inside it, user simply has to open the incoming message, while no authentication is in effect.

The following video shows how the attack is performed against these devices.

It is important to highlight that both unauthenticated messages and authenticated ones (whether by USERPIN or NETWORKPIN mechanism) are presented to the user in exactly the same way.
This has a deep impact on the security level perceived by the user: a competent one, in fact, could base its judgement of the message authenticity on the fact that it is authenticated by a specific mechanism. In order to produce a correct NETWORKPIN-authenticated message, the sending party has to know the IMSI of the victim, which is usually considered a private information, known only to the user itself and to the operator he belongs to.
The user, seeing that he is not asked to input any PIN, is led to think that the provisioning message is of the NETWORKPIN-authenticated type, and that, being so, it has to come from the operator’s systems; this reinforce, in the user, the belief that he can safely accept the new configuration.

The attack we presented at BlackHat Europe 2009 showed how it could be possible to take complete control of mobile originated data connections, by using a standard Provisioning mechanism, exploiting the ability to deliver configuration messages to handsets and performing social engineering on user by means of spoofing techniques.

Provisioning is a process that allows for remote configuration of Mobile Devices, and is tipically used by Mobile Operators for sending handsets the correct configuration for using data connections (eg: Internet access, MMS…)

Userpin is one of the available security mechanisms for performing the Provisioning process.
When using such mechanism the Mobile Operator sends a text SMS, advising the user that he is going to receive a configuration message, and a PIN code, that will be used for installing the configuration.
The configuration message is then sent as a second SMS. The user needs to insert the received PIN code, and then the configuration will be installed.

Abusing the Provisioning process can be performed in multiple ways. The solution we presented at BlackHat relies on changing the DNS address with the Userpin mechanism, but other options are possible.

Our paper can be downloaded here and slides here

A demo of the attack is now also available in the video below, where two samples of the attack have been performed.

Further information and details are reported in the following.

We will provide additional samples and variations, while covering handsets from more manufacturers, in the next few days.

Read the rest of this entry »

We’re back from Black Hat Europe ’09; as always it’s been an interesting experience.

In the next few days we’ll post here the details of the work we presented there (“Hijacking Mobile Data Connections”), but since a few articles have been published, we feel that stressing a few concepts is needed.

The attack we presented does not rely on a single vulnerability but is the result of the possibility of “abusing” a standard protocol that allows for mobile devices remote reconfiguration.

The problem affects all the devices which sports an OMA Provisioning client and that are used on a network that doesn’t implement effective filtering of provisioning messages coming from untrusted sources; the brand, model and other similar details play a marginal role in all this.

In our opinion, support for OMA provisioning is not a problem ‘per se’, but it is rather the ability to abuse it that should be regarded as the problem.
So, the handsets could be considered more as possible targets of the attack, rather than the root cause of the problem itself. Some improvements on the handset side could help in mitigating the problem, but they could hardly entirely avoid this kind of attack.

The ability to process OMA provisioning messages really depends on several factors: brand, model, firmware version; providing explicit indications on which handset is a possible target could be easily prone to error.
As far as we know a large number of models, from different Manufacturers, support the provisioning client, but, in order to avoid possible misunderstanding, we prefer not to mention brand and models unless specific vulnerabilities in the client are identified.

In summary: support of the OMA provisioning client, as specified in standard, along with the possibility to receive provisioning messages from untrusted sources, should be the main criteria for evaluating a risk scenario.

Stay tuned for the rest of the story.

MSL-2008-001 vulnerability raised a significant attention; we have now decided to disclose its technical details. We decided to proceed with the disclosure in order to stimulate public analysis and contribution, hoping to increase awareness about this issue and ultimately help protection against it.

The following description is based on our tests and our inference of what happens inside the device.
Unfortunately, researching vulnerabilities on such devices is a long and painful work, because of the lack of documentation, testing tools and debuggers, so we cannot ultimately state what happens at the code level.

All evidences are towards a vulnerability occurring in the parsing of WAP Push header; the code devoted to such parsing appears to be used for processing packets received both on SMS and IP.

We strongly believe that the specific issue resides in the improper handling of incorrect size fields inside the WAP Push headers.

WAP is actually a large framework, into which WSP is in charge of content delivery. A reference document describing WSP protocol can be found here:

http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-230-wsp-20010705-a.pdf

WSP makes extensive use of size fields; our tests have tracked a few fields that, if incorrectly specified, will lead the vulnerable handsets to an error condition, such as rebooting or system freezing. More specifically, the vulnerability will be triggered if, in such fields, the specified length is larger than the actual amount of bytes.

Since WAP content can be carried both over SMS and IP protocol, we will make use of the latter to show an example; this enables us to use Wireshark to better explain the data structures.

The following pictures show the capture of 2 sample IP packets that, when sent to the handset, will make it reboot; they have been opened with Wireshark, even though they are marked (obviously) as ‘malformed’.
The lower pane shows the hexadecimal representation of WAP payload.

Fig 1 – MSL-2008-001-1

Figure 1 shows one of the first formats we researched: this is a WAP Push message carrying a “multipart” Content-Type payload. According to the specifications, the 2 bytes circled in the screenshot refer to the multipart payload headers:
Header Length: 0x0a
Content Length: 0x1

In the remaining part of the  packet there are only 0xa bytes, and no byte is referenced by the 0x1 of the Content Length. This is enough for triggering the vulnerability; changing the Content Length to 0x0 would fix the header and the payload would be normally processed by the handset without any consequence.

Let’s see another example:

Fig 2 – MSL-2008-001-2

This sample does not use any multipart content, it just consists of the WAP Push packet header, without any payload. The specified Header Length (3rd byte) is 0x1c bytes long, while there
are just 0x1b remaining bytes in the header. Changing the Header-Length to the correct value of 0x1b would fix the header resulting in an inoffensive WAP Push packet.

These malformed WAP Push packets are to be sent over UDP, but the very same payload can be embedded in a properly formatted SMS.

We are not sure that all the possible attack vectors have been identified; and the two samples, even if they yield the same effect, may actually be due to different code execution flows.

Besides, it seems that the vulnerability occurs quite early in the processing of the WAP packet, because the UI settings are not able to influence in any way the processing of such packets.
The vulnerability occurs long before anything is displayed on the UI, and the received SMS is not even saved in the Inbox.

The ‘closed’ OS and the characteristics of this vulnerability suggest us that a protection on the network side could be a viable alternative to that on the handset side, but other options may apply too.

Well, it seems it happened.
Our paper ‘Hijacking Mobile Data Connections’ has been selected for the BlackHat Europe 2009 conference, that will take place in Amsterdam – April 14-17.
For those who don’t know this conference (you really should), according to BH site, it’s “The World’s Premiere Technical Security Conference”.
We are happy that two members of Mobile Security Lab will be speaking at this event, with novel material we recently researched.
For additional information on the speech just read the speakers’ page on BH site, by following this link.
Stay tuned for more interesting things, this post will be updated with the schedule assigned to our speech.

See you in Amsterdam!!