See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/228900500

SMS of Death: from analyzing to attacking mobile phones on a large scale

Article · January 2011

CITATIONS READS
48 2,115

3 authors, including:

Jean-Pierre Seifert
Technische Universität Berlin
131 PUBLICATIONS   2,202 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Optical attacks View project

All content following this page was uploaded by Jean-Pierre Seifert on 28 January 2017.

The user has requested enhancement of the downloaded file.

 SMS of Death: from analyzing to attacking mobile phones on a large scale

Collin Mulliner, Nico Golde and Jean-Pierre Seifert

Security in Telecommunications
Technische Universität Berlin and Deutsche Telekom Laboratories
{collin,nico,jpseifert}@sec.t-labs.tu-berlin.de

Abstract are highly embedded systems that are closed to develop-

ers. This results in billions (there are about 4.6 billion
Mobile communication is an essential part of our
mobile phone subscribers [43, 16]) of potentially vulner-
daily lives. Therefore, it needs to be secure and reliable.
able mobile devices out in the field, just waiting to be
In this paper, we study the security of feature phones,
taken advantage of by a knowledgeable attacker.
the most common type of mobile phone in the world.
In this paper, we investigate the security of feature
We built a framework to analyze the security of SMS
phones and the possibility for large scale attacks based on
clients of feature phones. The framework is based on
discovered vulnerabilities in these devices. We present a
a small GSM base station, which is readily available
novel approach to the vulnerability analysis of feature
on the market. Through our analysis we discovered
phones, more specifically for their SMS client imple-
vulnerabilities in the feature phone platforms of all
mentations. SMS is interesting because it is the feature
major manufacturers. Using these vulnerabilities we
that exists on every mobile phone. Furthermore, security
designed attacks against end-users as well as mobile
issues related to SMS messaging can be exploited from
operators. The threat is serious since the attacks can
almost anywhere in the world, and, thus present the ideal
be used to prohibit communication on a large scale
attack vector against such devices. To the best of our
and can be carried out from anywhere in the world.
knowledge, no attempt has been made before to analyze
Through further analysis we determined that such
or test feature phones for security vulnerabilities.
attacks are amplified by certain configurations of the
mobile network. We conclude our research by providing Analyzing feature phones is difficult for several rea-
a set of countermeasures. sons. First of all, feature phones are completely closed
devices that do not allow for development of native appli-
cations and do not provide debugging tools. Moreover,
analyzing the part of the phone that interacts with the
1 Introduction mobile phone network is hard since the mobile phone
network between us and the target device is essentially
In recent years a lot of effort has been put into analyz- a black box. As a consequence, analysis becomes time
ing and attacking smartphones [18, 20, 24, 21, 22, 23, consuming, unreliable, and costly.
46, 45], neglecting the so-called feature phones. Feature We address these problems by building our own GSM
phones, mobile phones that have advanced capabilities network using equipment that can be bought on the mar-
besides voice calling and text messaging, but are not con- ket. We use this network not only for sending SMS mes-
sidered smartphones, make up the largest percentage of sages to the phones we analyze, but also as an advanced
mobile devices currently deployed on mobile networks monitoring system. The monitoring system replaces our
around the world. In comparison, smartphones only ac- need for debuggers and other tools that are normally re-
count for about 16% of all mobile phones [43]. The lack quired for thorough vulnerability analysis, but do not ex-
of security research into the far more popular feature ist for feature phones.
phones is explained by the fact that smartphones share Vulnerability analysis was conducted using fuzzing.
much commonality with desktop computers, and, there- We chose fuzzing as the testing technique because we
fore are easier to analyze. Researches are able to use the did not have access to source code and reverse engineer-
same or similar tools that they are already familiar with ing a large number of devices is not feasible. Addition-
on desktop computers. Feature phones on the other hand ally, fuzzing proved to be very efficient since this allowed
us to analyze a large amount of mobile handsets with the communication. In Section 6 we present methods for de-
same set of tests. tecting and preventing the attacks we designed. In Sec-
So far, we have found numerous vulnerabilities in fea- tion 7 we briefly conclude.
ture phones sold by the six market leading mobile phone
manufacturers. The vulnerabilities are security critical
2 Related Work
as they can remotely crash and reboot the entire target
phone. In the process the mobile phone is disconnected Related work is separated into four parts. First, smart-
from the mobile network, interrupting any active calls phone vulnerability analysis. Second, mobile and feature
and data connections. Such bugs and attacks have ex- phone bugs, which were all found purely by accident.
isted before on the Internet, known as Ping-of-Death [6]. Third, studies on attacks against mobile phone networks.
We believe this represents a serious threat to mobile tele- Fourth, Denial-of-Service (DoS) attacks since we are go-
phony world wide. ing to present a large scale mobile phone DoS attack in
To complete our research we further analyzed the this paper.
effect of such attacks on the mobile phone core network. The authors of [24] built a framework for security
This resulted in two interesting findings. First, the analysis of Multimedia Messaging Service (MMS) im-
mobile phone network can be abused to amplify our plementations on Windows Mobile based smartphones.
Denial-of-Service attacks. Second, by attacking mobile Similar research in [23] conducted vulnerability analy-
phones one can attack the mobile phone network itself. sis of Short Message Service (SMS) implementations of
smartphones. Both used traditional techniques such as
The main contributions of this paper are: debuggers and analysis of crash dumps to catch excep-
tions generated during fuzzing.
• Vulnerability Analysis Framework for Feature Our work presented in this paper is different, as we do
Phones: We introduce a novel method to conduct not rely on debugging capabilities provided by the vari-
vulnerability analysis of feature phones that is based ous manufacturers, which mostly do not provide such ca-
on a small GSM base transceiver station. We solve pabilities at all. Instead we use a small GSM base station
the major issue of such analysis: the monitoring to monitor and catch abnormal behavior of the phones
for crashes and other unexpected behavior. We by monitoring and analyzing radio link activity. MMS-
present multiple solutions for monitoring such de- based attacks that lead to battery exhaustion due to in-
vices while analyzing them. Our method further- creasing power consumption have been studied in [39].
more shows that once a system, such as GSM, be- They utilized the fact that MMS messages use more bat-
comes partially open, the security of the entire sys- tery resources because of GPRS and increased CPU us-
tem, including the parts that are still closed, can be age. However, we did not conduct this kind of analysis
analyzed and exploited. since our focus was software bugs in SMS implementa-
• Bugs Present in Most Phones: We show that vul- tions.
nerabilities exist in most mobile phones that are de- Over the last few years a small number of bugs have
ployed on mobile networks around the world today. been discovered by individuals. Most of them have been
The bugs we discovered can be abused for carrying found by accident. To our knowledge no systematic test-
out large scale Denial-of-Service attacks. ing has been conducted. Some examples are: the Curse-
of-Silence [44] named bug for Symbian OS that prevents
• Attack Impact: We show that a small number of a phone from further receiving any SMS after receiving
bugs in the most popular mobile phone brands is the curse SMS message. The WAP-Push vCard bug on
enough to take down a significant number of mobile Sony Ericsson phones [33] that caused a target phone to
phones around the world. We further show that bugs reboot. Some Nokia phones [34] contained a bug that
present in mobile phones can possibly be used to could be abused to remotely crash a phone by sending it
attack the mobile phone network infrastructure. a specially crafted vCard via SMS. Some mobile phones
produced by Siemens contained a bug [17] that would
The rest of this paper is structured in the following shutdown the phone when displaying an SMS message
way. In Section 2 we discuss related work and show how that contained a special character. Bugs like these fuelled
our research extends previous work in this area. In Sec- our research effort since we believed that most phones
tion 3 we explain how we selected our targets for analy- contain similar bugs. A large number of similar issues
sis and resulting attacks. In Section 4 we show in great in an exploit arsenal can likely be used to carry out at-
detail how to analyze feature phones for security vulner- tacks against a bigger percentage of mobile phone users
abilities. In Section 5 we layout methods to use the vul- around the world.
nerabilities discovered for large scale attacks on mobile Enck et al. show in [47] that SMS messages sent over

2
the Internet can be used to carry out a Denial-of-Service is considered a feature phone. Dumb phones are phones
attack against mobile phone networks. The attack fo- with minimal functionality, often they only support voice
cused on blocking the mobile network’s control chan- calls and sending SMS messages, just basic functional-
nels, therefore, no more calls could be initiated. Solu- ity. Feature phones have less functionality than smart-
tions against this type of resource consumption attack phones but still more than dumb phones. Feature phones
are investigated in [37]. However our attacks, described have proprietary operating systems (firmware) and have
in this paper, are not based on attacking the radio link additional features (thus the term feature) such as play-
(the control channel) in any way. We attack the hand- ing music, surfing the web, and running simple applica-
sets directly without targeting the control channel. A tions (mostly J2ME [41]). Despite this lack of function-
study on the capabilities of mobile phone botnets [36] ality (compared to smartphones) they are quite popular
shows that these could be used to carry out DoS attacks because they are cheap and offer long battery life.
against a mobile network. The attack works by over- Technically interesting is the fact that feature phones
loading the Home Location Register (HLR) by trigger- are based on a single processor that implements the base-
ing large amounts of state changes by zombie phones. band, the applications, and user interface. Smartphones
However, in this paper we show that one can achieve a usually have a dedicated processor for the baseband. The
similar kind of DoS attack against an operators network consequence of this is that a simple bug on a feature
by disconnecting large amounts of mobile phones from phone may bring down the complete system.
the network. The difference to the botnet approach is that Mobile phones are produced by many different manu-
we do not need to have control over the zombie phones in facturers that all have their own OS, therefore, targeting
the first place. We can remotely force them to reboot and a single one of them will not result in global effect. Since
disconnect and re-authenticate to the network and thus we can not simply target all mobile phone platforms we
cause a higher load on the network core infrastructure. have to select the few ones that have enough market share
Denial-of-Service attacks such as the one presented in to be of global relevance.
this work have been studied in a wide area. Attacks rang- To determine the major mobile phone manufacturers
ing from the Web to DNS [38]. More interesting in our we analyzed various market reports: World wide [42]
context are attacks that disable real-world systems and and European [31] market share. Market shares in the
processes such as emergency services [29] (although just United States [28] and in Germany [27]. In the Appendix
as a side effect) or even postal services [40]. of this paper we include a table containing the raw num-
Essentially the work presented in this paper is differ- bers we gathered from the various market reports.
ent in many aspects. We focus on feature phones because Through this analysis we got a clear picture about the
feature phones are much more popular than smartphones. top manufacturers. These are Nokia, Samsung, LG,
Therefore, attacks against feature phones have a larger Sony Ericsson, and Motorola. We further chose
global impact. In this work we present a security testing to add Micromax [4] to the list of interesting mobile
framework for analyzing SMS implementations of any phone manufacturers because we read [9] that they are
kind of mobile phone. We used this framework to ana- the third most popular brand of mobile phones in India.
lyze feature phones of the most popular manufacturers in
the world, as shown in Section 3. We also performed this
4 Security Analysis of Feature Phones
type of analysis because it has not been done in the past,
even though these devices are widely deployed. Analyzing feature phones for security vulnerabilities is
hard for several reasons. There is no access to source
3 Target Selection code of the OS and applications. There are no exist-
ing native-SDKs, therefore, there is no way to run native
To achieve maximum impact with an attack, it makes code on the device and further no access to a debugger.
sense to target the most popular devices. We deter- JTAG-based debugging is also no option since not all de-
mined that feature phones are the dominant type of mo- vices have JTAG enabled. Furthermore, deeper knowl-
bile phones. They account for 83% of the U.S. mobile edge of the hardware and software is required in order to
market [10], smartphones in comparison just make for use JTAG debugging in a meaningful way.
16% of all mobile phones world wide [43]. We acknowl- Because of these reasons we choose to conduct fuzz-
edge that today smartphone sales are rising very fast, but based testing. The testing is carried out on our own GSM
feature phones still dominate when it comes to deployed network. In order to monitor for misbehavior, crashes,
devices in the field. and to find the related bugs, we designed our own mon-
Most of the definitions of the term feature phone are itoring system. Throughout this section we will first de-
a bit fuzzy. A loose definition of the term is: every mo- scribe the setup of our GSM network. Followed by the
bile phone that is neither a dumb phone nor a smartphone way we send SMS messages in this setup. Then we will

3
describe our novel monitoring setup. The final part of the scriber of our choice or it processes an SMS message
section will discuss test cases and the resulting bugs that that it received Over-the-Air in a store and forward fash-
were discovered throughout this work. ion. As we later see the existing interface is not feasible
for fuzzing since we need the ability to closely control all
parameters in the encoded SMS format as well as a way
4.1 Network Setup
to inject binary payloads.
Since we want to send large amounts of SMS messages Using a mobile phone to inject SMS messages into the
we decided to build our own GSM network rather than network is not an option as this would be very slow as we
sending SMS messages over a real network. On the one show later. Instead we built a software framework based
hand this has the advantage of not costing any money on a modified version of OpenBSC that allows us to:
and on the other hand we do not risk to interfere with the
telecommunication networks. We want to avoid crash- • Inject pre-encoded SMS into the phone network
ing the operator’s network equipment by either content
• Extensive logging of fuzzing related feedback from
or quantity of SMS messages. Having our own network
the phone
assures reproducible results because we have control of
the entire system and are able to quickly find parameters • Logging of non-feedback events, i.e. a crash result-
that cause unexpected results. Analysis over a real oper- ing in losing connection to the network
ator network would only leave us with the possibility of
guessing in many cases. In addition, the delivery of SMS • Automatic detection of SMS that caused a certain
messages is much faster on our small network compared event
to a production setup of a mobile operator.
• Process malformed SMS with OpenBSC
On the hardware side we decided to use an ip.access
nanoBTS [32], which is a small, fairly cheap (about 3500 • Smart fuzzing of various SMS features
Euro) GSM Base Transceiver Station (BTS) that pro-
vides an A-bis over IP interface. The A-bis interface • Ability to fuzz multiple phones at once
is used to communicate between the BTS and the Base
• Sending SMS at higher rate than on a real network
Station Controller (BSC). The BSC part of our setup is
driven by OpenBSC [30]. OpenBSC is a Free Software The format of an SMS [15] differs depending
implementation of the A-bis protocol that implements on whether the message is Mobile Originated
a minimal version of the BSC, Mobile Switching Cen- (MO) or Mobile Terminated (MT). This is
ter (MSC), Home Location Register (HLR), Authenti- mapped to the two formats SMS SUBMIT (MO) and
cation Center (AuC) and Short Message Service Center SMS DELIVER (MT). In a typical GSM network, shown
(SMSC) components of a GSM network. Figure 1 shows in Figure 4, an SMS message that is sent from a mo-
a picture of our setup. bile device is transferred Over-the-Air to the BTS of an
operator in SMS SUBMIT format. Every BTS is han-
dled by a Base Station Controller (BSC) that is inter-
acting with a Mobile Switching Center (MSC), which
acts as the central entity handling traffic within the net-
work. The MSC relays the SMS message to the respon-
sible Short Message Service Center (SMSC), which is
usually a combination of software and hardware that for-
wards and relays messages to the destination phone or
other SMSCs (in case of inter-operator messages or an
operator with multiple SMSCs). In our setup OpenBSC
Figure 1: Our setup: A laptop that runs OpenBSC and acts as BSC, MSC, and SMSC. During the final trans-
the fuzzing tools, the nanoBTS, and some of the phones mission to the destination the SMS will get converted
we analyzed. to SMS DELIVER, this is taken care of by OpenBSC.
Both formats are similar and no field that is subject to
our fuzzing is lost. SMS SUBMIT only contains the
As GSM operates on a licensed frequency spectrum destination number and since SMS works in a store-and-
we had to carry out our experiments in an Faraday cage. forward fashion, the destination address is replaced with
Utilizing this setup we are able to send SMS mes- the sender number on the final transmission to the desti-
sages to a mobile phone. OpenBSC allows us to either nation. SMS DELIVER does not include the destination
send a text message from its telnet interface to a sub- number but instead relies on an existing channel to the

4
phone (after the phone has been paged). For this rea- The mobile phone as well as the MSC are usually di-
son we utilize the SMS SUBMIT format when injecting vided into separated layers for transferring and process-
messages. ing a message. As shown in Figure 2 they consist of
a Short Message Transport Layer (SM-TL), Short Mes-
sage Relay Layer (SM-RL) and the Connection Sublayer
4.2 Sending SMS Messages (CM-Sub). The SM-TL [13] receives and relays mes-
OpenBSC itself does not provide an interface to submit sages that it receives from the application layer in TPDU
pre-encoded SMS messages to the network, but only an form (Transport Protocol Data Unit). This is the original
interface to submit text SMS messages that are then con- encoding form that we describe later in this paper. The
verted into the corresponding encoding. We added a new message is passed to the SM-RL to transport the TPDU
interface to OpenBSC that allows us to submit SMS mes- to the mobile station. At this point the TPDU is encap-
sages directly in SMS SUBMIT format. These messages sulated as an RPDU. As soon as a connection is estab-
are inserted into a database that is used by OpenBSC lished between the mobile station and the network the
as part of the SMSC functionality. In our version not RPDU is transferred Over-the-Air encapsulated in a CP-
only the parsed SMS values are stored, but also the com- DATA unit that is part of Short Message Control Protocol
plete encoded message for easy reproducibility. Modi- (SM-CP). Both sides communicate via their CM-Subs
fying the existing text message interface to be capable with each other. The CM-Sub on the phone side will
of handling binary encoded SMS messages proved to be unpack the CPDU and forward the encapsulated TPDU
infeasible. Messages submitted over this interface are to the Transport Layer using an RP-DATA unit. At this
instantly transmitted to the subscriber if he is attached to point the mobile phone stack has already performed san-
the network. This means opening a channel, initiating a ity checks on the content of the SMS and parsed it. The
data connection, sending the message and tearing down resulting reply, passed to CM-Sub, will include an ac-
the connection. This works, but is very slow and takes knowledgement of the SMS message and it will then be
about seven seconds per message. This is also the reason passed to the higher layers. From there it will end up
why we did not want to use a mobile phone to send our in the user interface or an error message is encapsulated
fuzz-messages in the first place. Our method of inject- and sent back to the network. For our monitoring we
ing messages is much faster. Prior to testing we use our need to log these replies carefully to observe the status
new interface to inject thousands of messages into the of the phone.
SMSC database. Next, we send these messages. Ideally,
this only opens a channel once and sends all SMS mes-
sages (pending delivery) to the recipient and then closes
the connection. This greatly improves the speed at which
we can fuzz since the actual message transfer only takes
about one second.
In essence we removed the sending mobile phone and
replace it with a direct interface to the network. This way
it was not necessary to modify the target mobile phone in
any way.

4.3 Monitoring for Crashes

In fuzz-based testing, monitoring is one of the essential Figure 2: Mobile terminated SMS
parts. Without good monitoring one will not catch any
bugs.
OpenBSC itself already has an error handler that takes From the wide variety of error messages a phone can
care of errors reported from the phone, which we mod- reply to a received SMS message (defined in [14]), we
ified to fit our fuzzing case. The default error handler observed during our fuzzing experiments that all of the
does not differentiate between errors and is not taking the tested phones either reply with a Protocol Error
cause of an error into account. It simply stops the SMS or Invalid Mandatory Information message
sending process in case of an error. The only exception in the case of a malformed message. These two re-
is a Memory Exceeded error, which causes OpenBSC sponses besides the memory error have been the only er-
to dispatch a signal handler to wait for an SMMA signal rors that we observed in practice. We added code to flag
(released short message memory) indicating that there is such an SMS message as invalid in the database and con-
enough space again. tinue delivering the next SMS that has not been flagged

5
as invalid. OpenBSC would otherwise continue trying to or already during receiving it in which it will never be ac-
retransmit the malformed SMS message and thus block knowledged and OpenBSC continuously tries to deliver
further delivery for the specific recipient. the SMS message.
SMS messages are usually sent over a SDCCH (Stand- Detecting the SMS message that caused such an error
alone Dedicated Control Channel) or a SACCH (Slow condition then is fairly simple. Our script checks the er-
Associated Control Channel). The details of such a chan- ror condition and if it occurred because of the loss of a
nel are not important for the scope of this paper. However channel it first looks up the database to find SMS mes-
the use of such a logical channel is an important mea- sages that have a delivery count that is bigger or equal
surement to detect mobile phone crashes. Such a channel to one and the message is not marked as sent (meaning
will be established between the BTS and the phone on the it was not acknowledged). In this case we can with a
start of an SMS delivery by paging the phone on a broad- high probability say that the found SMS message caused
cast channel. As we explained earlier, we only open the the problem. If there is no message the script checks
channel once and send a batch of messages using this which messages have been sent in a certain time inter-
one channel. The channel related signaling between the val around the time of the log event. During our testing
BSC and the BTS happens over the A-bis interface over we decided that a one minute time interval works well
highly standardized protocols. We added modifications enough to have a fairly small subset of candidate SMS
to the A-bis Radio Signaling Link code of OpenBSC that messages that could have caused a problem. Figure 3
allows us to check if a channel tear down happens in a shows the logical view of our monitoring setup.
usual error condition, log when this happens and which
phone was previously assigned to this channel. deliver
nanoBTS

So while we lack possibilities to conduct traditional SMS

Message
inject SMS
SMS Database Delivery Engine
Generator
debugging methods on the device itself we can use the feedback

r
ro
open part - OpenBSC - to do some debugging on the

er
to
Fuzzing Framework OpenBSC

S
SM
other end of the point-to-point connection.
ap
Target Phone

The difference to traditional debugging techniques is m

log evaluation J2ME
Monitor Logging Echo
that we are mostly limited towards noticing an error con- Server

dition and monitoring the impact of such an error. We

are not able to peek at register values and other soft-
ware related details of the phone firmware. However, Figure 3: Logical view of our setup.
it is enough to be able to reliably detect and reproduce
the error. Using this method it also possible to find code
execution flaws. However exploiting them and getting to
know the details about the specific behavior requires the
4.4 Additional Monitoring Techniques
effort of reverse engineering the firmware for a specific
model. We try to avoid such a large scale test of phones In addition to the aforementioned OpenBSC setup we
but these bugs are a good base for further investigations have developed more methods for monitoring for abnor-
such as reverse engineering of firmware. mal behavior.
In the next step we have written a script that parses the Bluetooth: Bluetooth can be used to check if a de-
log file, evaluates it and takes actions in order to deter- vice crashes or hangs. Our monitor script connects to the
mine which SMS message caused a problem. device using a Bluetooth virtual serial connection (RF-
When delivering an SMS message to a recipient phone COMM) by connecting to the RFCOMM channel for
under the assumption that it is associated with the cell the phone’s dial-up service. The script calls recv(2)
in practice three things can happen. Either the message and blocks since the client normally is supposed to send
is accepted and acknowledged, it is rejected with a rea- data to the phone. When the phone crashes or hangs, the
son indicating the error, or an unexpected error occurs. physical Bluetooth connection is interrupted and recv(2)
Such an unexpected error can be that the phone just dis- returns, thus signaling us that something went wrong.
connected because it crashed or due to other reasons the J2ME: Almost every modern feature phone supports
received message is never acknowledged. In the latter J2ME [41] and this is providing us with the only way
case, OpenBSC stores the SMS message in the database, to do measurements on the phone since they do not run
increases a delivery attempt counter and tries to retrans- native applications. Applications running on the mobile
mit the SMS message when the phone associates with phone can register a handler in an SMS registry simi-
the cell again. For our fuzzing results this means that lar to binding an application to a TCP/UDP port. SMS
this method detects bugs in which the SMS message ei- can make use of a User Data Header [13] (UDH) that
ther results in a phone crash after it accepted the message indicates that a certain SMS message is addressed to a

6
specific SMS-port. When the phone receives a message 4.6 Fuzzing Test-cases
this header field will be parsed and the message is for-
warded to the application registered for this port. Our We have implemented a subset of the SMS specification
J2ME application that is installed to the fuzzed phone as a Python library to create SMS PDUs (Protocol Data
registers to a specific port and receives SMS messages Unit) and used this to develop a variety of fuzzers. This
on it. For each chunk of fuzzed SMS messages we in- includes fuzzers for vCard, vCalendar, Extended Mes-
ject a valid message that is addressed to this port. The saging Service, multipart, SIM-Data-Download, WAP
application then replies with an SMS message back to push service indication, flash SMS, MMS indication,
a special number that is not assigned to a phone. Fig- UDH, simple text messages and various others fuzzing
ure 3 shows this as the J2ME echo server. The message only single fields that are part of a specific SMS feature.
is just saved to the SMS database. This allows us to eas- Some of these features can also be combined. For exam-
ily lookup the count of SMS messages for this special ple most of the features can either consist of single SMS
number in the database and check if it increased or not. message or be part of a multipart sequence by adding the
If not, it is very likely that some odd behavior was trig- corresponding multipart UDH.
gered. This kind of monitoring is useful to identify bugs For the scope of this paper we focused on fuzzing mul-
that block the phone from processing received messages tipart, MMS indication (WAP push), simple text, flash
such as those described in [44]. SMS, and simple text messages with protocol ID/data
coding scheme combinations. These test cases cover a
wide variety of different SMS features.
4.5 SMS SUBMIT Encoding
Multipart: SMS originally was designed to send up
The SMS SUBMIT format as defined in [13] consists of to 140 bytes of user data. Due to 7-bit encoding it is
a number of bit and byte fields, the destination address, possible to send up to 160 bytes. However various SMS
and the message payload. Below we briefly describe the features rely on the possibility to send more data, e.g.
parts the are important for our analysis. We included a binary encoded data. Multipart SMS allow this by split-
diagram of the structure of an SMS SUBMIT message ting payload across a number of SMS messages. This
in the Appendix. is achieved by using a multipart UDH chunk (IEI: 0,
TP-Protocol-Identifier (1 octet) describes the type of length: 3). This UDH chunk comprises three one byte
messaging service being used. This references to a values. The first byte encodes a reference number that
higher layer protocol or telematic interworking being should be random and the same in all message parts that
used. While this is included in the specifications, we be- belong to the same multipart sequence. Based on this
lieve that these interworkings are mostly legacy support value the phone is later able to reassemble the message.
and not in use these days. This makes it an interesting The second byte indicates the number of parts in the se-
target to study unusual behavior. quence and the last byte specifies the current chunk ID.
TP-Data-Coding-Scheme (1 octet) as described in [12] By fuzzing these three values we were mainly looking for
indicates the message class and the alphabet that is used abnormal behavior related to combinations of the current
to encode the TP-User-Data (the message payload). This chunk ID and the number of chunks in a sequence. For
can be either the default 7 bit, 8 bit or 16 bit alphabet and example missing chunk and chunk IDs higher than the
a reserved value. number of total chunks.
The TP-User-Data field together with the TP- MMS indication: When a subscriber receives
Protocol-Identifier and the TP-Data-Coding-Scheme are an MMS (Multimedia Messaging Service) message an
the main targets for fuzzing. The receiving phone parses MMS notification indication message [48] is sent to him.
and displays the message based on this information. This MMS indication is in fact a binary encoded WAP-
However these fields are not enough to cover the com- push message sent via SMS. The notification contains
plete range of possible SMS features. If the TP-User- multiple variable length fields for subject, transaction ID
Data-Header-Indicator bit (one of the earlier mentioned and sender name. There are no length fields for these
bit fields) is set this indicates that TP-User-Data includes values. They are simple zero terminated hex strings. An
a UDH. MMS indication message can also consist of multipart
The UDH is used to provide additional control infor- sequences. Therefore, our fuzzing target were the vari-
mation like headers in IP packets. It can hold multiple so able length field values included in the message seeking
called Information Elements [15] (IEI), for example el- for classic issues like buffer overflow vulnerabilities.
ements for port addressing, message concatenation, text Simple text: Implementations of decoders for sim-
formatting and many more. IEIs are represented in a sim- ple 7 bit encoded SMS often work with a GSM alpha-
ple type-length-value format. We included an example bet represented for example with an array. The decoder
UDH with multiple IEIs in the Appendix. first needs to unpack the 7 bit encoded values and convert

7
them to bytes. After this step it can lookup the charac- no personal data is lost. The behavior also differed be-
ter values in the GSM alphabet table. Our fuzzers mixed tween phones of the same manufacturer. When testing a
valid 7 bit sequences with invalid encodings that would bug on the Samsung B5310 it was always sufficient to re-
result in no corresponding array index. This could trigger move the offending SMS message from the phone’s SIM
all kinds of implementation bugs but most noteworthy card while the Samsung S5230 needed an additional hard
out of bounds access resulting in null pointer exceptions reset. Understanding such issues proved to be extremely
and the like. time-consuming. However, it is worth noting that purg-
TP-Protocol-Identifier/TP-Data-Coding-Scheme: ing a phone of all personal information can prove to be
The combination of both of these fields defines how nearly impossible for a user. This can become an issue
the message is displayed and treated on the phone. whenever a user plans to sell a used handset to a third
Both of these fields are one byte values and also cover party.
several rather unpopular features and reserved values.
With fuzzing combinations of these values with random
lengths of user data payload we were aiming for odd
4.8 Results
behavior and bugs in code paths that are seldom used by During our fuzz-testing we discovered quite a few bugs
normal SMS traffic. that lead to security vulnerabilities. The bugs mostly
Flash SMS: Flash messages are directly displayed on lead to phones crashing and rebooting, which discon-
the phone without any user interaction and the user can nected the phones from the mobile network and inter-
optionally save the message to the phone memory. Our rupted ongoing voice calls and data connections. Our
observations made it clear that often the code that ren- testing even resulted in two bricked phones that could
ders the flash SMS message on the display is not the no longer be reset and brought back into working order.
same as the one that displays a normal message from We did not investigate the bricking in-depth because this
the menu. Therefore, it can be prone to the same imple- would have gotten quite costly. Furthermore, some of
mentation flaws as simple text messages. Additionally, the phones crash during the process of receiving the SMS
flash SMS can consist of multipart chunks and there are message, and, therefore, fail to acknowledge the message
several combinations of TP-Protocol-Identifier and TP- thus causing re-transmission of the SMS message by the
Data-Coding-Scheme that cause the phone to display the network.
SMS as flash message. Our flash SMS fuzzers aim to Below we present some of the bugs we discovered on
cover a combination of all of the above possible imple- each platform. In most cases we fuzzed only one phone
mentation weaknesses. from each platform and later only verified the bugs on
other phones we had access to. This is expected because
most manufacturers base their entire product line on a
4.7 Fuzzing Trial
single software platform. Only customizing options such
After each fuzzing-test-run we evaluate the log gener- as the user interface depending on the hardware of a spe-
ated by our monitoring script. All of the bugs described cific device.
later in this paper were triggered by one or very few SMS We reported all bugs to the manufacturers including
messages and reproducing problems from log entries was full PDUs in order to verify and reproduce them. The
rarely problematic. However, during our fuzzing stud- feedback we received indicates that the bugs are present
ies we stumbled across various forms of strange behav- in most of their products based on their feature phone
ior. Problems we faced included non-standard conform- platforms. So far we have not received any information
ing message replies and various kinds of weird behav- about fixes or updates.
ior. Some phones were not properly reporting memory Nokia S40: On our test devices 6300, 6233,
exhaustion. Others did not notice free memory until a re- 6131 NFC, 3110c we found a bug in the flash SMS
boot. Some did not display a received SMS message on implementation. The phones run different versions of the
the user interface which made it hard to tell if the phone S40 operating system, the oldest of which was over 3
accepted a message or silently discarded it on the phone. years older than the newest. The manufacturer confirmed
Almost every phone we fuzzed needed a hard reset at that this bug is present in almost all of their S40 phones.
some point because it became simply unusable for un- By sending a certain flash SMS the phone crashes and
known reason, the mass of messages or a specific SMS triggers the ”Nokia white-screen-of-death”. This also re-
needed to be deleted from the SIM card using another sults in the phone disconnecting and re-connecting to the
phone. One of the biggest issues we came across was mobile phone network. Most notably, the SMS actually
that very few manufacturers’ hard reset actually restored never reaches the mobile phone. The phone will crash
the phone to an initial factory state. From what we know before it can fully process and acknowledge the message.
this is done as a feature for customers in order to ensure On the one hand this has the side effect that the GSM net-

8
work performs a Denial-of-Service attack for free as it differently. When sending one SMS that contains a mul-
continuously tries to transmit the message to the phone. tipart UDH with a higher chunk ID than the overall num-
On the other hand this has a side effect on the phone since ber of chunks and a reference ID that has not been used
there seems to be a watchdog in place that is monitoring yet, the phone receives the SMS message without in-
such crashes. This watchdog shuts down the phone af- stantly crashing. However a few seconds after the re-
ter 3 to 5 crashes depending on the delay between the ceipt the display turns black for some seconds before the
crashes. phone disconnects and reconnects to the network.
Sony Ericsson: Our test devices W800i, W810i,
W890i, Aino running OSE have a problem similar
to the Nokia phones. When combining certain payload 4.9 Validation and Extended Testing
lengths together with a specific protocol identifier value
it is possible to knock the phone off the network. In After the initial fuzz-testing we needed to validate our
this case there is no watchdog, but one SMS message is results over a real operator network since we tested in a
enough to force a reboot of the phone. As in the case of closed environment – our own GSM network. We need
the Nokia bug, this SMS message will never be acknowl- to evaluate if the bugs can be triggered in the real world
edged by the phone. To get an idea on how wide spread or if operator restrictions prevent this. For the validation
the problem is, we investigated the age of the devices and we put an active SIM card (of the four German operators)
found that the oldest phone (W800i) is from 2005 while into our test phones and connected them to a real mobile
the newest phone (Aino) is from late 2009. phone network. We sent the SMS PDUs that triggered
LG: Our LG GM360 seems to do insufficient bounds the bugs using the AT command interface of another mo-
checking when parsing an MMS indication message. bile phone. These tests validated all the bugs described
This allows us to construct an MMS indication SMS in the previous section.
message containing long strings that span over three or During our fuzzing tests we deactivated the security
more sms. This crashes the phone and thus forces an un- PIN on the SIM cards we used in the target phones so that
expected reboot when receiving the message or as well we did not have to enter the PIN on every reboot. We also
when trying to open the SMS message on the phone. tested the phones with an enabled SIM PIN. Our goal was
Motorola: As aforementioned, SMS supports telem- to determine if such reboots also reset the baseband and
atic interworking with other network types. By send- the SIM card. If the SIM card is blocked after reboot the
ing one SMS message that specifies an Internet elec- phone is not reconnected to the GSM network, and, thus,
tronic mail interworking combined with certain charac- the user is cut off permanently. We determined that this
ters in the payload it is possible to knock the phone off is true for our LG, Samsung, and Nokia devices.
the mobile network. Upon receiving the message the
phone shows a flashing white screen similar to the one
shown by the Nokia phones. The phone does not com- 4.10 Bug Characterization
pletely reboot; instead it simply restarts the user interface
and reconnects to the network. This process takes a few We group the discovered bugs depending on the software
seconds and depending on the payload it is possible to layer they trigger.
achieve this twice in a row with one message. We ver- The first group are bugs that require user interaction
ified this on the Razr, Rokr, and the SVLR L7 – such as the bug we discovered in the Samsung mobile
older, but extremely popular devices. The devices span phones. In this case the user has to view the message in
3+ years, providing us with confidence that the bug is order to trigger the bug.
present in their entire platform. The second group are bugs that crash without user in-
Samsung: Multipart UDH chunks are commonly used teraction. These bugs occur as soon as the phone has
for payloads that span over multiple SMS messages. The completed receiving the entire message and starts pro-
header chunk for multipart messages is simple. cessing it. In this group we put the bugs we found on the
Our Samsung phones S5230 and B5310 do not prop- Motorola, LG, and Micromax devices.
erly validate such multipart sequences. This allows us to The third and last group are bugs that trigger at a lower
craft messages that show up as a very large SMS mes- layer of the software stack. With lower layer we mean
sage on the phone. When opening such a message the during the process of receiving the SMS message from
phone tries to reassemble the message and crashes. De- the network. A crash during the transfer process means
pending on the exact model one to four SMS messages that the process is not completed and the network be-
are needed to trigger the bug. lieves the message is not successfully delivered to the
Micromax: The Micromax X114 is prone to a sim- phone. We categorize the bugs discovered in our Nokia
ilar issue like the Samsung phones but behaves slightly S40 and the Sony Ericsson devices in this third group.

9
5 Implementing the Attack 5.2 Sending SMS Messages
SMS messages can be sent by a mobile phone that pro-
The attacks presented in this work utilize SMS messages vides either an API that allows it to send arbitrary binary
to trigger software bugs and crash mobile handsets, in- messages or through its AT command interface. We used
terrupting mobile communications. These bugs cover the the AT interface for most of our testing and validation.
mobile phone platforms of all major handset manufactur- To carry out any kind of large scale attack a way for de-
ers and a wide variety of different models and firmware livering large quantities of SMS messages for low price
versions. The resulting bug arsenal can potentially be is needed. Multiple options exist to achieve this:
abused to carry out a large scale attack. Bulk SMS Operators: Bulk SMS operators such
as [1, 5, 3] offer mass SMS sending over the Internet
providing various methods ranging from HTTP to FTP
and the specialized SMPP (Short Messaging Peer Proto-
col). Bulk SMS operators are so-called External Short
5.1 Building a Hit-List
Message Entity (EMSE) that are often connected via In-
ternet to the mobile operators but sometimes have their
To launch an attack phone numbers of mobile phones own SS7 connection to the Public Switched Telephone
need to be acquired since simply sending SMS messages Network (PSTN). Figure 4 shows the various connec-
to every possible number is problematic. Furthermore, tions of an EMSE. All Bulk SMS operators operate in
sending SMS messages to a large number of unconnected the same way. For a given amount of money they de-
phone numbers dark address space could trigger some liver SMS messages to the specified destination(s). No
kind of fraud prevention system, such as observed on questions asked. Most of the APIs support sending a sin-
the Internet to detect worms [7]. In addition, for the de- gle message to a list of recipients. Prices range from 0.1
scribed attack only phone numbers that are connected to to 0.01 Euro depending on the volume and destination
a mobile phone are of interest. Depending on the kind of of the messages. The APIs among the bulk SMS opera-
attack, a different set of phone numbers is required. In tors differ. Usually they allow to set a number of SMS
one case an attack might be targeted towards a specific fields from which they assemble the actual payload. Not
mobile operator, therefore, only phone numbers that are all of them are offering the same predefined fields. For
connected to the specific operator are of interest. example [3] was the only one that allows us to set a TP-
Regulatory Databases: In many countries around Protocol-Identifier field. However, we verified that the
the world mobile network operators have their own area provided APIs are sufficient to carry out the presented
codes. Some examples are Germany1, Italy2 , the United attacks and to generate attack payloads that are identical
Kingdom3, and Australia4 . Such area codes can be read- to those sent from one of our phones.
ily acquired to help building a hit-list. Likewise one can
use the North American Numbering Plan (NANP) to de- MNO A
ESME K ESME J
termine which area exchange codes are used by mobile
SS7
operators. PSTN
BS
Web Scraping: Web Scraping is a technique to col- Internet

lect data from the World Wide Web through automated MSC

querying of search engines using scripted tools. Find- BS HLR

SS7
ing German mobile phone numbers can be easily done SMSC
through queries like "+49151*" site:.de. More- Network
SMSC MNO B
BS
over, online phonebooks [2] also include mobile phone
numbers. These sites often allow wild card searches, and,
thus can be abused to harvest mobile phone numbers.
Figure 4: SMS relevant structure of a mobile network
HLR Queries: Some Bulk SMS operators [5] offer a operator (MNO) network and the links to the PSTN, ES-
service to query the Home Location Register (HLR) for a MEs, and other MNOs.
mobile phone number. These queries are very cheap (we
found one for only 0.006 Euro) and answers the ques-
tion if a mobile phone number exists and where it is Mobile Phone Botnets: A botnet consisting of hi-
connected. Together with the information from the reg- jacked mobile or smartphones [35] could also be used
ulatory databases one can easily generate a list of a few for such attacks since every mobile phone is capable of
thousand mobile phone numbers that belong to a specific sending SMS messages. A mobile botnet has the distinct
mobile network operator. advantage of free message delivery and high anonymity

10
for the attacker. using a mobile phone botnet one could is removed from the hit-list. The method can be opti-
circumvent restrictions Bulk SMS operator might have mized through ordering the crash payloads according to
in different countries. the popularity of mobile phones in the targeted country.
SS7 Access: With direct access to the Signaling Sys- With this method an attacker can optimize a hit-list
tem 7 (SS7) of the Public Switched Telephone Network during an ongoing attack by matching bug-to-phone-
(PSTN) an attacker can very easily send SMS messages number. This optimized hit-list could as well be used for
in large quantities, for example to send SMS spam [25]. highly targeted attacks. For example against the network
Figure 4 shows the basic network connections of a mo- operator as described in Section 5.5, which explains our
bile network operator. SMS sending via SS7 also has the attack scenarios.
advantage of not being easily traceable, thus an attacker
can stay hidden for a longer period of time. Addition-
ally, SMS messages sent via SS7 are not restricted by 5.4 Network Assisted Attack Amplification
the Bulk SMS Operators (APIs) in terms of content or
Some of the bugs we discovered prevent the phone from
header information that they contain.
acknowledging the SMS message to the network. Fig-
ure 2 shows the states that happen during a message
5.3 Reducing the Number of Messages transfer from the network to the phone. In the case of
some of our bugs (Nokia S40 and Sony Ericsson; Bug
There is one issue left with our attack. That is how can Characterization Section 4.10) the message RP-ACK is
one determine the type of mobile phone that is connected not sent by the phone. This leads the network to believe
to a specific phone number. If money does not play a that the message was not received, therefore, the SMSC
role in carrying out the attack this issue is easily resolved. will try to resend the SMS message to the phone. This re-
The attacker just sends multiple SMS messages, each one delivery attempt is a perfect attack amplifier somewhat
containing the payload for a specific type of phone, to similar to smurf attacks [26] on IP networks.
each phone number. One of the messages will trigger the
bug if the phone is vulnerable at all. This works well Vodafone Germany
but is not optimal. To reduce the number of messages E-Plus Germany
O2 Germany
130 T-Mobile Germany
an attacker has to send we developed a technique that 120

allows the attacker to determine what kind of phone is 110

connected to a specific phone number. Actually we can 100

90
only determine if a specific malicious message has an
minute

80

effect on the phone that is connected to a specific number. 70

60
Our method abuses a specific feature present in the 50
SMS standard. This feature is called recipient noti- 40

fication, it is indicated through the TP-Status-Report- 30

20
Request flag in an SMS message. If the flag is set the 10
SMSC notifies the sender of the message when the re- 0
1 2 3 4 5 6 7 8 9 10 11
cipient has received the message. Most Bulk SMS oper- delivery attempt

ators support this feature through their APIs. Our method

works by measuring the delay between sending the mes- Figure 5: Timing of SMS message delivery attempts.
sage and receiving the reception notification.
The technique works as follows: First, we send the
message containing the payload for crash(1). Second, In our tests, sending malicious SMS messages over
when we receive the receipt for that message we send the real operator networks, we discovered that operators
payload for crash(2). Third, we measure the time differ- have different re-transmit timings, shown in Figure 5.
ence between the two notifications. If the difference is Furthermore, they also seem to have different transmit
equal we continue with the next payload. If the differ- queues. We measured the delivery timings of some Ger-
ence between both notifications is significant we deter- man mobile network operators in order to determine how
mine that the first message crashed the phone. The phone one could abuse the delivery attempts for improving our
needed to reboot and register on the network before be- Denial-of-Service attacks. We conducted the test by at-
ing able to accept the next message. If there is no noti- tacking one of our Sony Ericsson devices and monitoring
fication we determine that the phone did not receive the the phone using the Bluetooth method described in Sec-
message because it crashed before completely accepting tion 4.4.
the message. Fourth, we continue until all crash pay- The tests were carried out on the networks of Voda-
loads are sent. If none of them trigger, the phone number fone, T-Mobile, O2 (Telefonica), and E-Plus. The initial

11
delivery attempt is at minute 0. It shows that all opera- on unusual requests was shown in [36]. It is not nor-
tors do a first re-transmit after 1 minute, and a few more mal that thousands of phones try to connect and authen-
re-transmits every 5 minutes. In addition to what Fig- ticate at the same time over and over again. To optimize
ure 5 shows, Vodafone does an additional re-delivery 24 this DoS attack, the attacker needs to make sure to tar-
hours after the last delivery shown in the graph. O2 also get phones connected to different BTSs and MSCs (Fig-
attempts an additional re-delivery 20 hours after the last ure 4) of the targeted operator in order to circumvent bot-
delivery shown in the graph. tlenecks such as the air interface at the BTS. A clogged
Through the same test we determined that SMS mes- air interface would throttle the attack.
sages are not queued, but have an individual re-transmit Manufacturers: Likewise manufacturers could be
timer. That means an attacker can send multiple mali- threatened to have their brand name destroyed or weak-
cious SMS messages to a victim’s phone with a short ened by attacking random people owning their specific
delay between each message and thus can increase the brand of mobile phones. The attack could cost them
effect of the network assisted attack by sending multiple twice. Once for the bad reputation and second for re-
messages. placement devices. Even if the phones are not broken
victims of such an attack will still try to claim their de-
vice broken to get a replacement.
5.5 Attack Scenarios and Impact Public Distress: A carefully placed attack during a
There are multiple possible attack scenarios such as or- time of public distress could lead to large scale prob-
ganized crime going after the end-user, the mobile op- lems and possibly a panic. One example occurred in
erator, and the manufacturer to demand money. Attacks Estonia [19] in 2007 when a group of people carried
could also be carried out for fun by script kiddies and the out a Denial-of-Service attack against the countries Inter-
like. Below we discuss some possible scenarios. We ac- net infrastructure. Additionally, cutting off certain user
knowledge that some scenarios such as the attack against groups such as fireman or police officers during an emer-
individuals are more likely then an attack against a man- gency situation would have a critical impact. Not ev-
ufacturer. ery country has special infrastructure for emergency per-
Individuals: Individuals could be pressured to pay a sonal, and, therefore, rely on mobile phones to communi-
few Euros in order to keep their phone operational. This cate. This is even true in countries like Germany where
has happened with the Ikke.A [35] worm that requested every police officer carries a mobile phone since their
the user to pay 5 Euros in order to get back the control two-way-radios are often not usable.
over their iPhone. In our case the victim could be forced
to send a text message to a premium rate number in order 6 Countermeasures
to be taken off the hit-list.
Another attack against an individual or a group could In this section we present countermeasures to detect and
aim to prevent them from communicating. This can be prevent the kind of attacks we developed. First, we
efficiently carried out if the target uses a SIM card with present a mechanism to detect our and similar attacks
security PIN enabled, as we describe in Section 4.9. through monitoring for a specific misbehavior. Second,
Operators: Operators could be threatened to have all we discuss filtering of SMS messages. Filtering can be
their customers attacked. Such an attack would mainly done on either the phones themselves or on the network.
kill the operator’s reputation as being reliable. The op- We discuss the advantages and disadvantages of each of
erator might also lose money due to people being un- them. Third, we briefly discuss amplification attacks.
able to call and send text messages. In order to have a
global impact such an attack has to be carried out on a
6.1 Detection
very large scale for a longer time. As a result, customers
could possibly terminate their contract with the operator. To prevent our attacks, operators first need to be able
Such extortion scams were and still are popular on the to detect them. Detection is not very easy since the
Internet [8]. operator does not get to look inside the phone during
Furthermore, the operator’s mobile network can be runtime. Therefore, the only possible way to monitor the
attacked directly or as a side effect of an large attack phone is through the network. We propose the following:
against its users. This could work when thousands of at-
tacked phones drop off the network and try to re-connect Monitor Phone Connectivity Status: Monitor if a
at the same time. This can cause an overload of the back- phone disconnects from the network right after receiving
end infrastructure such as the HLR. This kind of attack an SMS message.
seems likely since mobile networks are not optimized for Log last N SMS Messages: Log the last N SMS mes-
these specific kinds of requests. A similar attack based sages sent to a particular phone in order to analyze pos-

12
sible malicious messages after a crash was detected. Use load during an attack.
the message as input for SMS filters/firewall. Network-side filters also have drawbacks. First, if a
Use IMEI to Detect Phone Type: The brand and phone is roaming within another operator’s network, the
type of a mobile phone can be derived from the IMEI SMS message does not travel through the network of the
(International Manufacturer Equipment Identity). This home operator. Thus the filters are not touched. This is
is useful to correlated malicious SMS messages to a the only advantage of phone-side SMS filtering. In this
specific brand and type of phone. case the user becomes attackable as soon as he leaves
his home network. For traveling business people in Eu-
Using this technique it is possible to catch malicious rope, this is quite normal. The GSMA already has a solu-
SMS messages that cause phones to reboot and lose net- tion for this issue called SMS homerouting. SMS Home-
work connectivity. This should especially help to catch routing as specified in [11] defines that SMS messages
unknown payloads that cause crashes. Such a monitor is are always routed through the receiver’s home-network.
also capable of detecting if a large attack is in progress by Meaning that all SMS messages travel through SMSCs
correlating multiple SMS-receive-disconnect events in a of his service provider at home. SMS messages, there-
certain time-frame. fore, can be filtered by the receiver’s service provider.
The second issue with network-side filtering is privacy.
In order to do SMS filtering the operator must be allowed
6.2 SMS Filtering to inspect SMS messages. This could be an issue in some
SMS filtering can be implemented either directly on the countries where mobile telephony falls under special reg-
phone or within the operator’s network. Both possibil- ulations.
ities have inherent benefits and drawbacks that are pre-
sented in this section.
6.3 Preventing Network Amplification
It is important to reconsider the process of SMS
delivery. First, an SMS message is sent from the Attack amplification through re-transmissions of SMS
sender phone to the senders SMSC. Next, the senders messages should be avoided since this greatly helps an
SMSC queries for the SMSC of the recipient and attacker. We suggest that operators limit the number of
delivers the message to the responsible SMSC. Fi- re-transmissions. Some operators re-send the messages
nally, the relevant SMSC locates the recipient’s phone 10 times, this seems unnecessary.
and delivers the SMS message via the BTS Over-the-Air.

Client-side SMS Filtering would need to be done 7 Conclusions

right after the modem of the phone received and demod-
ulated all the frames carrying the SMS message and be- In this paper we have shown how to conduct vulnerabil-
fore pushing it up the application stack. The filter would ity analysis of feature phones. Feature phones are not
need to parse the SMS message and check for known bad open in any way, the hardware and software are both
messages similar to signature-based antivirus software or closed and thus do not support any classical debugging
a packet filter firewalls. The problem with this solution methods. Throughout our work we have created analy-
is the update of the signatures. Of course, the parser sis tools based on a small GSM base station. We use the
in the SMS filter must be bug free otherwise the attack base station to send SMS payloads to our test phones and
just moves from the phone software to the filter software. to monitor their behavior. Through this testing we were
Also, devices that are already in the field would not profit able to identify vulnerabilities in mobile phones built by
from such a filter since only new phones will have this. six major manufacturers. The discovered vulnerabilities
Also, newer phones will likely not contain bugs that are can be abused for Denial-of-Service attacks. Our attacks
known at the time they are manufactured. Therefore, we are significant because of the popularity of the affected
believe network-side filters make more sense. models – an attacker could potentially interrupt mobile
Network-side SMS Filtering takes place on the communication on a large scale. Our further analysis
SMSC of the mobile network operator. Therefore, it can of the mobile phone network infrastructure revealed that
inspect all incoming and outgoing SMS messages. There networks configured in a certain way can be used to am-
are multiple advantages of network-side filtering. First, plify our attack. In addition, our attack can be used to not
the filter software runs on the network, therefore, it cov- only attack the mobile handsets, but through their misbe-
ers all mobile phones connected to that network. Second, havior can be used to carry out an attack against the core
changing the filter rules can be done in one central place. of the mobile phone network.
Third, malicious SMS messages are not sent out to the To detect and prevent these kind of attacks we suggest
destination mobile phones, therefore, reducing network a set of countermeasures. We conceived a method to de-

13
tect our and similar attacks by monitoring for a specific [14] 3GPP/ETSI. 3GPP TS 04.11 Point-to-Point (PP)
behavior. Short Message Service (SMS) Support on Mobile
Radio Interface. http://www.3gpp.org/ftp
/specs/html-info/0411.htm, 1998.
Acknowledgements
[15] 3GPP/ETSI. 3GPP TS 23.040 - Techni-
The authors would like to thank Charlie Miller, An- cal realization of the Short Message Service
dreas Krennmair, Dmitry Nedospasov, Borgaonkar Rav- (SMS). http://www.3gpp.org/ftp/Specs
ishankar, and Simon Schoar for their help reviewing the /html-info/23040.htm, September 2004.
paper and for helping us to acquire phones for testing.
[16] ABI R ESEARCH. Worldwide Mobile Subscrip-
References tions Number More than Five Billion. http:
//www.abiresearch.com/press/3531-Wo
[1] Clickatell Bulk SMS Gateway. http://www.c rldwide+Mobile+Subscriptions+Num
lickatell.com. ber+More+than+Five+Billion, October
2010.
[2] Das Örtliche. http://dasoertliche.de.
[17] B. J URRY XF OCUS T EAM. Siemens Mo-
[3] Hay Systems Ltd. http://www.hslsms.com. bile SMS Exceptional Character Vulnerability.
[4] Micromax mobile. http://www.micromaxi http://www.xfocus.org/advisories/
nfo.com. 200201/2.html, January 2002.

[5] Routo Messaging. http://www.routomessag [18] B. M ÜLLER. From 0 to 0-Day On Symbian.

ing.com. https://www.sec-consult.com/files/S
EC Consult Vulnerability Lab Pwnin
[6] Ping of Death. http://insecure.org/spl g Symbian V1.03 PUBLIC.pdf, 2009.
oits/ping-o-death.html, October 1996.
[19] BBC N EWS. Estonia hit by ’Moscow cyber
[7] Honeynet Project. http://project.honeyne war’. http://news.bbc.co.uk/2/hi/eur
t.org, 2005. ope/6665145.stm, 2007.
[8] DDoS extortion-themed scam circulating.
[20] C. G UO , H. J. WANG , W. Z HU. Smartphone at-
http://www.zdnet.com/blog/securi
tacks and defenses. In Third ACM Workshop on
ty/ddos-extortion-themed-scam-ci
Hot Topics on Networks (2004).
rculating/7180, August 2010.
[21] C. M ILLER. Exploiting the iPhone.
[9] Micromax becomes the third largest handset man-
http://securityevaluators.com/c
ufacturer in India. http://www.topnews.in/
ontent/case-studies/iphone/, August
micromax-becomes-third-largest-h
2007.
andset-manufacturer-india-2260105,
April 2010. [22] C. M ILLER , M. DANIEL , J. H ONOROFF. Exploit-
[10] When It Comes to Apps, Feature Phones Are the ing Android. http://securityevaluators
New Black. http://gigaom.com/2010/03/ .com/content/case-studies/android/
27/when-it-comes-to-apps-feature- index.jsp, October 2008.
phones-are-the-new-black/, May 2010. [23] C. M ULLINER , C. M ILLER. Injecting SMS Mes-
[11] 3GPP/ETSI. TR 23.840 Study into routeing of sages into Smart Phones for Security Analysis. In
MT-SMs via the HPLMN. Proceedings of the 3rd USENIX Workshop on Of-
fensive Technologies (WOOT) (Montreal, Canada,
[12] 3GPP/ETSI. 3GPP TS 03.38 Alpha- August 2009).
bets and language-specific information.
http://www.3gpp.org/ftp/Specs/h [24] C. M ULLINER , G. V IGNA. Vulnerability Analysis
tml-info/0338.htm, 1998. of MMS User Agents. In Proceedings of the Annual
Computer Security Applications Conference (AC-
[13] 3GPP/ETSI. 3GPP TS 03.40 Technical SAC) (Miami, FL, December 2006).
realization of the Short Message Service.
http://www.3gpp.org/ftp/specs/h [25] CELLULAR - NEWS . A ”rising Tide” of SS7 Based
tml-info/0340.htm, 1998. Mobile Network Fraud. http://www.cellu

14
 lar-news.com/story/46377.php, Novem- [37] P. T RAYNOR , W. E NCK , P. M CDANIEL , T. L A
ber 2010. P ORTA. Mitigating attacks on open functionality
in sms-capable cellular networks. In In ACM Mo-
[26] CERT. Advisory CA-1998-01 Smurf IP Denial-of- biCom (2006), pp. 182–193.
Service Attacks. http://www.cert.org/adv
isories/CA-1998-01.html, January 1998. [38] R. FARROW. DNS Root Servers: Protecting the
Internet.
[27] C OM S CORE. German Mobile Market Share.
http://www.comscore.com/index.php/P [39] R. R ACIC , D. M A , H. C HEN. Exploiting MMS
ress Events/Press Releases/2010/1/ vulnerabilities to stealthily exhaust mobile phone’s
comScore Reports November 2009 Ger battery. In Proceedings of the Second IEEE Com-
man Mobile Market Share, November 2010. munications Society / CreateNet International Con-
ference on Security and Privacy in Communication
[28] C OM S CORE. U.S. Mobile Subscriber Market Network (SecureComm) (Baltimore, MD, Auguest
Share. http://comscore.com/Press Eve 28 - September 1, 2006).
nts/Press Releases/2010/7/comScore
[40] S. B YERS , A. D. RUBIN , D. KORMANN. Defend-
Reports May 2010 U.S. Mobile Subscri
ing against an Internet-based attack on the physical
ber Market Share, May 2010.
world. ACM Trans. Internet Technol. 4, 3 (2004),
[29] D. M OORE , V. PAXSON , S. S AVAGE , C. S HAN - 239–254.
NON , S. S TANIFORD , N. W EAVER. Inside the
[41] SUN M ICROSYSTEMS. Java Micro Edition.
Slammer Worm. IEEE Security and Privacy 1 http://www.oracle.com/technetwork/j
(2003), 33–39. ava/javame/index.html.
[30] H. W ELTE. OpenBSC. http://openbsc.osm [42] T. A HONEN. Mobile Phone Market Shares for year
ocom.org/trac/, 2008. of 2009. http://communities-dominate
.blogs.com/brands/2010/02/phone-ma
[31] IDC. Western European Mobile Phone Mar-
rket-shares-for-year-of-2009-and-
ket Grows. http://www.idc.com/getdo
last-quarter-2009.html, February 2010.
c.jsp?containerId=prUK22402810, June
2010. [43] T. A HONEN. Tomi Ahonen Almanac 2010 Mobile
Telecoms Industry Review. February 2010.
[32] IP. ACCESS LTD . nanoBTS 1800. http:
//www.ipaccess.com/picocells/nanoB [44] T. E NGEL. Remote SMS/MMS Denial of Service
TS picocells.php. - Curse Of Silence. http://berlin.ccc.de/
˜tobias/cursesms.txt, December 2008.
[33] M OBILE S ECURITY L AB. SonyEricsson WAP
Push Denial of Service. http://www.mseclab [45] T HE I NTREPIDUS G ROUP. WebOS: Ex-
.com/?page id=123, January 2009. amples of SMS delivered injection flaws.
http://intrepidusgroup.com/insig
[34] O. W HITEHOUSE. Nokia Phones Vulnerable to ht/2010/04/webos-examples-of-sm
DoS Attacks. http://www.infoworld.com s-delivered-injection-flaws/, April
/article/03/02/26/HNnokiados 1.htm 2010.
l, February 2003.
[46] V. I OZZO , P. W EINMANN. iPhone Sa-
[35] P. A. P ORRAS , H. S AIDI , V. Y EGNESWARAN. An fari vulnerability allowed to steal the SMS
Analysis of the iKee.B iPhone Botnet. In Proceed- database. http://news.cnet.com/8301-
ings of the 2nd International ICST Conference on 27080 3-20001126-245.html, March 2010.
Security and Privacy on Mobile Information and [47] W. E NCK , P. T RAYNOR , P. M C DANIEL , T. L A
Communications Systems (Mobisec) (May 2010). P ORTA. Exploiting Open Functionality in SMS-
[36] P. T RAYNOR , M. L IN , M. O NGTANG , V. R AO , T. Capable Cellular Networks. In Conference on
JAEGER , T. L A P ORTA , P. M C DANIEL. On Cel- Computer and Communications Security (2005).
lular Botnets: Measuring the Impact of Malicious [48] WAP F ORUM. WAP-209-WSP Wireless Applica-
Devices on a Cellular Network Core. In ACM Con- tion Protocol MMS Encapsulation Protocol. ht
ference on Computer and Communications Security tp://www.wapforum.com, 2002.
(CCS) (November 2009).

15
 Notes Table 8 shows an overview of the popularity of mobile
phone manufacturers in Germany, the United States, in
Europe, and around the world.
1 http://en.wikipedia.org/wiki/Telephone numbers in Germany
2 http://en.wikipedia.org/wiki/Telephone numbers in Italy Manufacturer Market Share
3 http://en.wikipedia.org/wiki/Telephone numbers in the United Kingdom
Nokia 35.4%
4 http://en.wikipedia.org/wiki/Telephone
Sony Ericsson 22.0%
numbers in Australia
Samsung 15.0%
Motorola 8.6%
Siemens 5.4%
(a) Germany, November 2009

APPENDIX Manufacturer Market Share

Samsung 22.4%
Figure 6 shows the layout of an SMS message in the LG 21.5%
SMS SUBMIT format. Figure 7 shows the generic lay- Motorola 21.2%
out of a User Data Header (UDH) with a number of In- RIM 8.7%
formation Elements. Nokia 8.1%
(b) U.S.A., May 2010

Field Size Manufacturer Market Share

TP-Message-Type-Indicator 2 bit Nokia 32.8%
TP-Reject-Duplicates 1 bit Samsung 12.5%
TP-Validity-Period-Format 2 bit LG 4.1%
TP-Status-Report-Request 1 bit Sony Ericsson 3.7%
TP-User-Data-Header-Indicator 1 bit Apple 3.0%
TP-Reply-Path 1 bit RIM 2.4%
TP-Message-Reference integer Others 3.0%
(c) Europe, June 2010
TP-Destination-Address 2-12 byte
TP-Protocol-Identifier 1 byte Manufacturer Market Share
TP-Data-Coding-Scheme 1 byte
Nokia 38.0%
TP-Validity-Period 1 byte/7 byte
Samsung 20.0%
TP-User-Data-Length integer
LG 10.0%
TP-User-Data depends on DCS/UDL
Sony Ericsson 5.0%
Figure 6: Format of the SMS SUBMIT PDU. Motorola 5.0%
ZTE 4.5%
Kyocera 4.0%
RIM 3.5%
Sharp 2.6%
Field Size Apple 2.2%
UDHL 1 byte Others 5.0%
(d) World, for the year 2009
IEI1 1 byte
IEIDL1 1 byte
Figure 8: Mobile phone Manufacturer Market share
IEID1 n bytes
...
IEIn 1 byte
IEIDLn 1 byte
IEIDn n bytes

Figure 7: The User Data Header

16

View publication stats