Mobile Security Lab has discovered another remote DoS attack on mobile devices. This one is particulary interesting, because one can in theory send a single UDP packet to freeze or reboot many mobiles at once.
Affected SonyEricsson devices are:
- W910i
- W660i
- K618i
- K610i
- Z610i
- K810i
- K660i
- W880i
- K530i
Other devices based on the same (or earlier) platform are likely to be vulnerable.
More recent devices may be not vulnerable.
A malformed WAP Push packet is able to remotely reboot the handset and, in some cases, completely hang it.
In case the handset hangs, battery removal is needed in order to restore normal functionalities.
By sending multiple malformed packet via SMS, an attacker may be able to reboot the handset multiple times, effectively performing an extended denial of service.
The attack can also be performed over an IP bearer using UDP port 2948.
In this case a single malformed broadcast packet can be used to attack and disable a large number of devices, leading to a much heavier impact.
There are not know any solutions and workarounds for this DoS attack. The issue has been reported to SonyEricsson.
Mobile Security Lab is aware that the problem has been identified: some models, more recent than the ones listed in this advisory, have been found not to be vulnerable.
Technical Details
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 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: 0×0a
Content Length: 0×1
In the remaining part of the packet there are only 0xa bytes, and no byte as referenced by the 0×1 of the Content Length. This is enough for triggering the vulnerability; changing the Content Length to 0×0 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 0×1c bytes long, while there
are just 0×1b remaining bytes in the header. Changing the Header-Length to the correct value of 0×1b 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.
Source: Mobile Security Lab
