Battery-Draining Attack
One attack that builds off
using MMS notifications is a battery-draining attack. The goal of a
battery draining attack is to drain the battery of a victim’s phone
without their knowledge in a manner that is far more rapid than normal
usage, thereby knocking the victim’s, phone offline. This attack exists
due to the nature of how mobile phones are optimized to use their
internal radio the absolute minimal amount. When a customer is looking
at purchasing a new mobile phone, they are often presented with two
numbers that represent battery lifetime. The first number is “standby”
time, which is typically on the order of several days. The second number
is “talk” time, which is a much lower number, usually measured in just a
few hours. This is because modern mobile phones are highly optimized to
keep their internal radio powered down and avoid sending data whenever
possible because this rapidly drains the battery. A battery-draining
attack takes advantage of this fact by forcing the radio in the mobile
phone to stay on indefinitely until the battery has been exhausted. The
key to this attack is performing it stealthily in a way that requires no
victim interaction, so that the victim is completely unaware that the
attack is being performed.
One of the easiest ways to
perform this attack is by abusing the MMS notification functionality. To
perform an attack via this method, an attacker crafts an MMS
notification message that points to an attack server they control. In
the case of a battery-draining attack, the bandwidth needed to perform
the attack is negligible, which allows an attacker to use even a home
DSL line to perform the attack. Once the MMS notification message has
been constructed pointing to their hostile server, the
attack sends the message to the victim. The victim’s phone receives the
message and automatically connects to the attack server to receive what
it assumes will be a legitimate MMS message. Instead of returning a
valid image file or video as part of a normal MMS, the attacker has
instead configured their server to keep the victim’s phone connected to
the server indefinitely. The attacker can perform this in a number of
ways, although the easiest method is by “pinging” the victim’s phone
with UDP packets. In this method, the attacker waits for the victim’s
phone to connect and then obtains the victim’s IP address. The attacker
then slowly sends UDP packets to the victim’s IP address, which forces
the victim’s phone to stay online and keep the radio powered on. The
amount of resources needed for this attack is usually quite low because
mobile phones have a timeout value for how long they will stay connected
to the Internet without receiving data. For example, if the victim’s
mobile phone is set to disconnect if no data is received after 10
seconds, then the attacker only needs to send one UDP packet every nine
seconds to force the victim’s phone to stay connected. The amount of
resources an attacker needs to be able to send a single UDP packet every
nine seconds is so trivial that it means an attacker with a single
computer on a home DSL line could likely simultaneously attack an
extremely large number of mobile phones. Figure 5 illustrates the concept of this attack.
For real-world
results of this testing, UC Davis computer security researchers
performed this attack against several mobile phones. In their research,
they found that they were able to drain the battery life of a target
mobile phone up to 22.3 times faster than by normal usage. For details
of their research, view “Exploiting MMS Vulnerabilities to Stealthily
Exhaust Mobile Phone’s Battery” at www.cs.ucdavis.edu/~hchen/paper/securecomm06.pdf.
Silent Billing Attack
Another
attack that builds off the nature of MMS messages is the silent billing
attack. This attack primarily targets mobile customers with prepaid
mobile phones that depend on having a credit balance in their account.
The goal of a silent billing attack is to silently drain the victims
credit so that they are knocked offline and unable to perform further
actions such as making or receiving calls.
To understand how this
attack works, first one must think back to the discussion of how MMS
messages function. Unlike text SMS messages, MMS messages have more
overhead and involve several background messages to set up and confirm
that an MMS has been successfully delivered. Because these background
messages are only a small part of the process of an MMS message, mobile
phones are programmed to not display messages of these types to the
user. Instead, they are processed in the background as part of an MMS
message, and if they refer to an invalid MMS message they are simply
(from a user’s perspective) silently ignored. The silent billing attack
takes advantage of two key facts about these types of messages: First,
that these messages are silently ignored and not displayed to users.
Second, that these messages are still perfectly valid messages from the
billing perspective of the carrier’s network. Therefore, an attacker can
abuse these messages when they wish to deplete the balance of a victim
who has a prepaid mobile phone account, unbeknownst to the victim. By
bombarding the victim’s phone with any of the background messages not
displayed to the victim/user (for example, a Send Confirmation), the
attacker is able to rapidly wipe out the credit balance on the victim’s
account. The victim will not be aware that this attack has taken place
because their phone didn’t display any of the incoming messages. Thus,
once the attack has been completed, the victim is unaware that their
account is now empty and they will no longer receive legitimate incoming
calls or text messages, in addition to being denied when attempting to
place an outbound call or send a text message.
When compared with the
other attacks in this article, the silent billing attack is hardly the
most severe. However, it is included here because it serves to
illustrate the point that not all attacks against mobile phones via SMS
will be about exploiting code-level flaws in implementations. Rather,
there are a wide range of ways to abuse legitimate functionality inside
the SMS specifications that can cause real and potentially serious
issues for SMS users.
OTA Settings Attack
Over The Air (OTA) settings
involve the ability of a carrier to push new settings to a customer’s
mobile phone on their network. Support for OTA settings varies widely
from mobile phone to mobile phone and from manufacturer to manufacturer;
however, mobile phones from Nokia, Sony Ericsson, and Motorola
typically contain at least some support for OTA settings, whereas other
phones may not. Like SMS itself, the term OTA settings
is actually a catchall that can refer to a number of different items.
Everything from pushing new browser settings, to pushing firmware
updates, to provisioning mobile phones for use on the carrier’s network
has been referred to as “OTA settings.” Detailing all potential OTA
settings attacks could easily fill an entire book; therefore, in this
section we will focus on one common usage of OTA settings. Once this
example is understood, its principles can be applied to attacking any
other form of OTA settings.
The attack we discuss here
involves pushing new WAP browser settings to a target mobile phone. The
goal of this attack is to install new settings into the browser
configuration of the target mobile phone. If the attack is successful,
the victim’s browser will then route all traffic through a proxy that
the attacker controls. The attacker is then able to sniff the connection
to obtain personal information about the victim, as well as to perform
man-in-the-middle attacks against the victim’s traffic. Luckily for an
attacker, constructing a message to perform an attack such as this is
fairly straightforward. This is due to the fact that WAP browser
settings are typically represented in an easy-to-understand XML format.
For example, the following is the XML representation of a normal WAP
browser settings message that a carrier could send to a customer’s
mobile phone:
<CHARACTERISTIC-LIST>
<CHARACTERISTIC TYPE="ADDRESS">
<PARM NAME="BEARER" VALUE="GSM/CSD"/>
<PARM NAME="PROXY" VALUE="123.123.123.123"/>
<PARM NAME="CSD_DIALSTRING" VALUE="+4583572"/>
<PARM NAME="PPP_AUTHTYPE" VALUE="PAP"/>
<PARM NAME="PPP_AUTHNAME" VALUE="wapuser"/>
<PARM NAME="PPP_AUTHSERCRET" VALUE="wappassword"/>
</CHARACTERISTIC>
</CHARACTERISTIC-LIST>
In this message, the carrier
has sent several settings to the customer’s mobile phone. These settings
tell the mobile phone’s browser to use the carrier’s WAP proxy located
at IP address 123.123.123.123 and to log into this proxy using the
username “wapuser” and password “wappassword” as well as to use PAP as
the authentication type. Once a message such as this has been
constructed, it is sent from the carrier’s network to the user, as shown
in Figure 6.
However, as with
the attacks discussed previously, there is often nothing blocking an
attacker from being able to construct their own message of this type and
sending it through the carrier’s network. For example, consider the
following attacker-constructed message:
<CHARACTERISTIC-LIST>
<CHARACTERISTIC TYPE="ADDRESS">
<PARM NAME="BEARER" VALUE="GSM/CSD"/>
<PARM NAME="PROXY" VALUE="111.111.111.111"/>
</CHARACTERISTIC>
</CHARACTERISTIC-LIST>
It should be noted that the
attacker’s message is even easier to construct than the legitimate
carrier-generated message. This is due to the fact that the attacker
does not worry about having the victim authenticate to the attacker’s
proxy server. The attacker doesn’t want any problems with authentication
to block the victim from sending their traffic through the attacker’s
proxy, so they leave the authentication options out of the settings. The
attacker then sends their hostile settings to the user through the
carrier’s network, as shown in Figure 7.
A common assumption may be
that this attack is not likely to be successful in the real world
because a target of the attack would simply see a message from a
friend’s number or a number they didn’t recognize displaying something
along the lines of new settings being received. However, often in
practice the victim has almost no contextual information with which to
make an informed decision about whether or not the incoming settings are
legitimate or the source of these settings. For example, consider the
screen shown in Figure 8,
which demonstrates the notification displayed to the user of a Sony
Ericsson W810i mobile phone when it receives new hostile settings from
an attacker.
The main issue that
should become immediately apparent is, how does a user know whether this
is a legitimate settings update from their carrier or hostile settings
being sent from an attacker? No source number of the message is shown,
and no indication of what settings will be changed is shown. What if
this message had been combined with a social-engineering attack that
preceded the new settings dialog with a message saying, “This is a free
message from your carrier. We’re rolling out new settings to our
customers to enhance their mobile experience. Please accept these new
settings when they appear on your phone in the next several minutes.” In
this case, even generally security conscious users would likely install
the new hostile settings.
This section has
demonstrated just one of many possible attacks using OTA settings.
However, the lessons learned from this attack can easily be applied by
an attacker to performing any other attack using OTA settings. Finally,
this section has demonstrated just how easy this attack may be to
perform when a target mobile phone displays little or no information
that would allow a user to make an informed decision on the legitimacy
of the incoming OTA settings.
Attacking Protocol Implementations
As implied by this section’s
title, unlike the previous sections, this one does not cover a specific
attack. Rather, this section describes the methodology of how to go
about attacking SMS implementations.
Before attack methodologies can
be discussed, it is important to understand the significant challenges
that restrict and complicate testing for SMS security issues in mobile
devices. Specifically, when testing SMS implementations for security
issues, the primary hurdle to overcome is reliance on the carrier
network. Imagine a scenario in which a tester wishes to fuzz a certain
MMS message type where there are 50,000 possible test cases (which is
not a particularly high number of test cases for a fuzzer). If each one
of these test cases needs to be sent through the carrier’s network as an
actual SMS, the amount of time this will take the tester is
unrealistically high, to say nothing of the cost. Instead, the goal of
anyone wishing to test the security of SMS implementations is to remove
the carrier’s network from the equation. One way to do this is to turn
the test environment into one that closely resembles testing a TCP/IP
network service over an intranet. For example, when testing a newly
developed HTTP server for bugs, a tester would rather set up a small
dedicated LAN to conduct testing rather than testing the HTTP server
over the public Internet.
The easiest way to remove the
carrier’s network from the testing process is to take advantage of the
Wi-Fi support modern mobile phones have. If a tester can place a mobile
phone on a Wi-Fi network and deliver SMS messages to the device over
this connection instead of over the carrier’s GSM/CDMA network, the
testing experience can be greatly improved. For example, the Windows
Mobile 5 platform offers this support by default. When Windows Mobile 5
is placed on a Wi-Fi network, it will listen on UDP port 2948 for
incoming SMS WAP messages. This allows significant SMS functionality to
be tested on the Windows Mobile 5 platform while circumventing the
carrier’s network for greater testing speed and less cost.
An additional way to
overcome this hurdle is to use an emulator instead of an actual mobile
device. At the time of writing, the best mobile phone emulator to work
with is without a doubt the Android emulator, which allows the tester,
via use of the sms pdu command, to specify a PDU on the command line
that the emulated phone will then treat as if it had just been received
from the carrier’s network. This allows the tester to exercise all areas
of SMS functionality. The goal of a tester on any platform should be to
remove the carrier’s network from the testing equation, whether via
Wi-Fi-like Windows Mobile 5 or an emulator such as Android. Although we
will not go further in depth on this topic (because it is different for
each version of each platform out there), the point of mentioning these
challenges is twofold. First, it makes the tester aware of the
significant hurdle using the carrier’s network adds to testing. Second,
it makes the tester aware that often their target platform will have
some functionality either built into the device or in the developer
emulator that allows
this hurdle to be overcome. Testers should seek this functionality out
and use it to greatly improve their testing experience.
Once these limitations have
been overcome, there remains the question of how to go about actually
testing a targeted SMS implementation. Although “dumb” fuzzing such as
generating PDUs filled with garbage data may find a bug or two, the
complex structure of an SMS PDU often requires an intelligent approach
to finding issues. To help the tester understand what sort of
intelligent test cases to come up with, this section discusses two types
of SMS messages as case studies that will show testers how to approach
testing.
The first type of SMS
discussed is attacking concatenated message functionality. The SMS
concatenated message functionality is used when a user wants to send a
message that contains more characters than can be fit in a single SMS
PDU. The message is then split across multiple SMS PDUs, which are each
sent to the recipient. A User Data Header is inserted into the PDU that
tells the receiving mobile phone that this message is a multipart
message that will need to be concatenated together before being
displayed to the user. Additionally, the User Data Header for a
concatenated message informs the recipient mobile phone how many
segments the multipart message is split into as well as what segment
number the current message is. As a tester reading about this
functionality, it certainly sounds like there are a number of different
attacks an attacker may try against this functionality. Because mobile
devices typically have extremely limited memory, the simplest attack a
tester may wish to try is simply sending the theoretical maximum number
of segments that a concatenated multipart message can contain. The
tester’s rationale for this attack is that the developer of the SMS
implementation in use may make an assumption that the largest
concatenated message a user will ever legitimately send would contain 10
or even 100 segments, but not the full theoretical maximum of 255. The
developer would then define a message buffer that only contains enough
space to contain the “realistic” maximum number of messages, such as 10
or 100. Therefore, by constructing an “unreasonably” large (but still
technically valid) message, the tester may find a vulnerability in the
target SMS implementation when it tries to reassemble multipart
concatenated messages with a greater number of message segments than the
developer anticipated.
The second type of SMS discussed
is one of the many background MMS messages that occur during the
involved process of one mobile subscriber sending rich content (such as a
picture) over MMS to another subscriber. The MMS message type that has
been chosen for this study is the MMS delivery report. The delivery
report is a message sent from the carrier’s MMS server to the mobile
phone of the subscriber who originated the MMS in order to confirm that
the message has been successfully delivered. The delivery report message
contains five different fields: MMS
Version, Message ID, To, Date, and Status. As discussed in the SMS
concatenation example, the tester should look for fields where the SMS
implementation developer may have made assumptions about the likely use
case. In the case of the MMS delivery report, the first such field that
springs to mind is the To field. The reasoning for this is that a
developer could quite easily assume that the To field will only ever
contain a telephone number, and therefore the maximum size it will ever
need to be is the length of a large international number. However, there
is nothing stopping a tester or attacker from putting in an
extraordinarily large number or string in this field. The only
requirement for this field actually stated in the MMS specification is
that it be a NULL-terminated string. Therefore, it would be possible for
a tester to create a string much larger than any international
telephone number and place it in the To field. When testing MMS
implementations, the tester should look for a field such as To due to
the assumption that can easily be made about the field (limited to the
size of an international phone number) which in reality differs from the
actual definition of the field (unlimited size string).
Unlike previous sections,
which discussed specific known attacks against SMS and MMS
implementations, the goal of this section has been to teach those
testing implementations about the challenges they face and the
methodology that can be used during testing. It is hoped that by
applying these approaches, testers will be able to find and remove
issues from SMS implementations being shipped in current and future
mobile devices.
