Application Attacks
At a different level than protocol
attacks are application-level attacks. In the previous section, attacks
against SMS and other lower-level messages were discussed. In contrast,
this section discusses applications that use SMS as a delivery
mechanism. This would be similar to attacking a PC’s browser while
leaving the TCP/IP stack alone because it is just a delivery mechanism.
As opposed to the protocol
attacks being mostly version agnostic, these types of attacks are very
specific to software versions running on phones. Additionally, specific
development and debugging tools are needed to develop exploits. Although
these attacks may sound far harder to perform than protocol attacks,
there is one factor that greatly assists an attacker: Application
attacks are similar to their full operating system counterparts.
Therefore, the skills involved with attacking operating systems that
have become fairly commoditized in recent years directly apply to this
area of attacking mobile phones.
It
is helpful to examine past vulnerabilities when one is looking for new
vulnerabilities. Current application vulnerabilities tend to fall into
browser, MMS client, or image categories. Although browser
vulnerabilities are not directly related to messaging, they may be
accessible through messaging. Browser attacks are well understood in
security research, and many tools to aid bug discovery are available.
Image vulnerabilities are also not directly related to messaging, but
various image types can be delivered to a phone over MMS. Image attacks
have become popular on embedded platforms from phones to portable video
gaming systems.
This
section lists some interesting vulnerabilities on various phone
platforms. The goal of this is to give you a brief overview of selected
vulnerabilities in order to introduce you to the sort of vulnerabilities
that may be triggered at the application level via SMS. The
vulnerabilities covered are:
iPhone Safari
Windows Mobile MMS
Motorola RAZR JPEG
iPhone Safari
The first vulnerability that
will be discussed affects the Safari browser. The iPhone does not support MMS natively. However, third-party
MMS clients are available for jailbroken phones—the most popular of
which is SwirlyMMS. Apple has announced a native MMS client in the
upcoming 3.0 firmware release.
Technical details of this vulnerability were released at BlackHat 2007 by Charlie Miller of ISE (http://securityevaluators.com/iphone/bh07.pdf)
The attack results in a heap overflow after viewing a malicious page
within mobile Safari, which allows an attacker to execute arbitrary code
on the iPhone. The vulnerability is within the Perl Compatible Regular
Expression (PCRE) library used by Safari. The significance of this
attack is that both the full desktop OS version of Safari and the mobile
version extensively share code. As such, this allows an attacker
looking to exploit the iPhone platform via Safari to search for
vulnerabilities on a Mac OS desktop with full debugging tools and then
directly apply their research to the iPhone platform. This is an ideal
environment for an attacker looking to exploit application flaws via SMS
because it cuts all the restrictions of the mobile device out of the
bug-hunting loop.
Windows Mobile MMS
At the SyScan conference in 2007, Collin Mulliner disclosed an MMS vulnerability affecting various Windows Mobile/CE devices (www.mulliner.org/pocketpc/feed/CollinMulliner_syscan07_pocketpcmms.pdf). The vulnerability was discovered in a
third-party MMS product by Arcsoft, which creates the MMS client that
works within the standard messaging client tmail.exe on Windows Mobile.
The vulnerability allows remote execution of arbitrary code through a
buffer overflow.
This vulnerability
is located in the parsing of the Synchronized Multimedia Integration
Language (SMIL). SMIL is an XML markup language commonly used by MMS
messages to represent the multimedia components of a message that looks
similar to HTML. In many ways the SMIL parser is analogous to the HTML
parser in a browser. In Mulliner’s exploit, he discovered that a
fixed-length stack buffer can be overflowed while parsing large
parameters to the “region” and “text” tags in an MMS message.
The vulnerability
is significant because it was discovered by fuzzing the MMS client using
an environment not previously documented. The environment used the
Kannel open-source SMSC along with Apache and a modified MMS library to
perform the fuzzing. It then took advantage of Windows Mobile 5’s
ability to receive SMS and WAP messages over a Wi-Fi network to automate
testing.
Motorola RAZR JPG Overflow
In 2008, the TippingPoint Zero
Day Initiative (ZDI) disclosed a vulnerability (ZDI-08-033) in Motorola
RAZR phones related to the processing of JPG files. The vulnerability
they disclosed was due to a problem in the way the RAZR parsed
thumbprints in the JPG EXIF header. This allowed for a malicious JPG
image, when viewed on the phone, to execute arbitrary code.
This vulnerability
demonstrates the real-world impact of using MMS notification messages to
open an attack surface on mobile phones. By using an issue in a
graphics library that is prone to vulnerabilities and pairing it with
abusing SMS protocols, an attacker is able to successfully compromise a
victim’s mobile phone.
In application attacks, as
with testing SMS implementations, the goal is always to make the testing
environment as efficient as possible. Toward that end, the tester
should always try to remove bottlenecks such as the carrier’s network or
even the mobile device itself. The common theme of the application
attacks described in this section is that each attack has been
discovered by following this methodology—whether it involves attacking a
desktop browser or a standard image library.
Walkthroughs
This section walks you
through some common tasks required when testing SMS security, such as
sending a raw PDU from a mobile phone via a PC, as well as converting
XML to WBXML for use in OTA and MMS attacks.
Sending PDUs
The
easiest method to send test PDUs from a mobile phone is through the use
of AT commands. The AT commands used by mobile phones are extremely
similar to the AT commands that were developed for Hayes dial-up modems.
They are used by cell phones to programmatically control many functions
having to do with the phone’s radio. In order to send SMS messages
through a phone, the following is needed:
The serial connection to the
phone can be established in a number of ways. Originally the most common
method involved a serial cable between the computer and a specialized
connector to the phone. The cables were proprietary to each phone.
Although proprietary cables are not necessary, each phone uses different
connection methods. The connection options can be specialized cables,
USB cables, IR, and Bluetooth. With so many different options, it is
best to acquire manufacturer data on serial connections or to search
online.
After the serial connection
has been physically established via a cable or a wireless connection
such as Bluetooth, a terminal program is needed. For Windows users,
HyperTerminal was the de facto choice. However, Microsoft stopped
including HyperTerminal with the release of Windows Vista. Therefore,
this section will conduct the walkthrough using Putty—a popular free SSH
client that can also do serial connections over COM ports (www.chiark.greenend.org.uk/~sgtatham/putty/download.html). For Linux/Unix users, Minicom is a popular and widely available terminal program that can also be used.
The terminal program
needs to be configured in order to operate with the phone. The following
are options that work with most phones. Sometimes the speed may need to
be adjusted.
COM Port Set this to the COM port for the phone. The port will depend on how the phone is connected.
Speed (Bits Per Second)
Valid values include 115200, 57600, 19200, and 9600. The speed value
itself won’t make anything faster. The bottleneck is not communication
between the terminal and phone. The phone’s radio determines SMS
throughput.
Data Bits 8
Parity None
Stop Bits 1
Flow Control Hardware
After the phone is connected,
the phone is ready to receive AT commands. The following AT command
initializes the phone’s modem and verifies the connection setup. In this
walkthrough, all user input commands appear in bold and phone responses
appear in italics. Type AT in the terminal. Upon success, an OK should be returned, as shown here:
AT
OK
Next, a basic text message
can be sent. This requires a multiline command. The first line contains
the command and the destination phone number as a parameter, followed by
a carriage return. The example lists the destination number as
555-555-1212. Be sure to replace this with a valid number. The following
line contains the payload of the text message followed by the key
combination CTRL-Z.
AT+CMGS=“5555551212”
>Test message. <CTRL-Z>
OK
An OK means that the phone’s
modem accepted the message and sent it out. In order to send more
advanced messages, a different AT command is needed to enable PDU mode.
PDU mode allows for binary payloads. The following
example sends a PDU SMS to 1-555-555-1212. The first line tells the
modem to use PDU mode. Although it is possible that a phone does not
support PDU mode, in practice it is very rare. The second line is an AT
command that was used earlier, albeit slightly different. When used in
PDU mode, the first parameter is the number of octets to expect. The two
zeros at the beginning of the payload do not count toward this total.
The third line is the actual payload followed by CRTL-Z.
AT+CMGF=0
OK
AT+CMGS=23
>0011000B915155551512F20000AA0AE8329BFD4697D9EC37<CTRL-Z>
OK
That is all that is
required to a send an SMS PDU. There are many more AT commands, but they
aren’t required to send messages. Several
useful online resources discuss SMS-related AT commands in depth, including the following:
Converting XML to WBXML
In order to send the
XML-encoded examples, you first need to convert
them to WBXML. WBXML is a binary representation of XML that is used by
SMS messages in order to keep messages small. The standard is available
from the W3C at www.w3.org/TR/wbxml/.
Simple XML can be converted by hand to WBXML, but it quickly becomes
too tedious when used with large-scale testing. Instead, automated tools
can be relied upon to do the necessary conversions for testers. The
libwbxml package (available at http://libwbxml.aymerick.com/) is a WBXML library. It builds on Windows, Unix, and Symbian. Two tools are included in the library to perform conversions:
The library has been
reported to be missing some types relating to provisioning. A
user-released patch is available for version 0.9.2, but may not fix all
issues: http://wiki.forum.nokia.com/index.php/Image:Wbxml_tables.c_frodek.patch.txt.
