Mobile Security Lab

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.

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.

WAP Push service can be used for delivering unsolicited data to the handset, and is typically used by Operators for providing advanced services (eg: e-mail, MMS).

The MSL-2008-001 advisory reports a Denial of Service vulnerability discovered in several SonyEricsson handsets, that allows an attacker to remotely reboot a vulnerable handset by sending a malformed WAP Push message.
Both SMS messages and UDP datagrams can be used as a transport mechanism for delivering WAP Push messages.
The vulnerability can be remotely triggered both via SMS and UDP; in the latter case the malformed message need to be sent to port 2948, that has been found open on all the handsets listed in the advisory.

The risks associated to an “UDP-based” attack scenario are not negligible in case the Operator allows reachability of the handset IP address, without doing proper filtering.
An attacker may be able to remotely reboot the handset by simply sending a carefully crafted IP datagram to the handset IP address.

Additionally:
– the handsets accept IP packets directed to a broadcast address. If broadcast packets are allowed in the network, a single UDP datagram may be sufficient for rebooting all the handsets in the target subnet.
– UDP protocol is connectionless and a single datagram is sufficient for triggering the vulnerability. Under these conditions source IP spoofing is possible, increasing the difficulties of implementing proper firewall policies and attackers tracking.

In the “SMS-based” attack scenario, an SMS, carrying the malformed WAP Push message, is able to trigger the vulnerability.
The SMS buffering performed by the Operator network brings, as a side effect, the possibility for an attacker to perform an extended Denial of Service attack against a single target.
In facts, if multiple SMS are sent to the victim, the first one will reboot the handset making it unavailable for receiving further messages.
The other messages will queue on the network side and delivery will be attempted as soon as the handset re-attaches to the network, leading to continous rebooting.
This may allow an attacker to effectively disable the use of the handset for an extended period of time.

(more…)

“You are browsing with your shiny smartphone while being connected to a wireless LAN.
Suddenly you receive a single SMS carrying a new contact information.
You don’t even have the time to check it, that your SMS inbox starts filling with unwanted messages and you don’t seem to be able to stop it…”

This is a possible scenario that may happen if you are victim of a vCard Denial of Service, described here.

The attack can be carried on, possibly in a more effective way, when a data connection is active with a Mobile Operator that assigns a public IP address, reachable over the Internet, and does not provide any filtering of incoming packets.
In this case the attack can become a truly remote Denial of Service, that can be performed over the Internet, at no cost for an attacker.
Additionally, the protocol used (UDP) allows for easy IP source address spoofing, making more difficult the tracking of an attacker or the implementation of proper firewall policies.

The following video provides a short insight of what may happens to an handset when is targeted by such an attack.
(more…)