SMS Vulnerability Analysis on Feature Phones · SMS Vulnerability Analysis on Feature Phones Nico Golde January 17, 2011 Technische Universität Berlin Fakultät IV Institut für

Diploma Thesis

SMS Vulnerability Analysis on FeaturePhones

Nico Golde

January 17, 2011

Technische Universität Berlin

Fakultät IV

Institut für Softwaretechnik und Theoretische Informatik

Security in Telecommunications

Supervisors : Prof. Dr. Jean-Pierre Seifert

Prof. Dr. Anja Feldmann

Advisor: MSc Collin Mulliner

Abstract

Mobile phone communication has become part of our daily lives. One of the most widelydeployed and used services is the Short Message Service (SMS). Therefore it has to bereliable as well as secure. The security of so-called smartphones has been well researchedin the past and, with the rise of new phone applications, is still an ongoing researchtopic. Though the majority of people do not use these high-end phones, but insteadrely on simple, so-called feature phones. When compared to smartphones, these phonestypically do not allow operating system modifications and thus have not been the targetof security analysis in the past. However, due to the recent development in implementingOpen Source GSM stacks the formerly closed part of the GSM communication - the GSMnetwork - allows analysis of these devices to some extent.

In this thesis we present a “framework” based on a Base Transceiver Station that ison the market, a modified version of a piece of Open Source software to run a GSMnetwork and several scripts to monitor phone behaviour and create large amounts ofSMS payloads. This allows us to conduct a large scale security study of SMS imple-mentations on a wide variety of feature phones. Due to the existence of numerous waysto test smartphones we concentrated on the analysis of feature phones even though thisapproach is not necessarily limited to these devices.

Through our analysis we discovered security bugs in the feature phone platforms ofall major manufacturers. We show what impact these issues have as well as discussinga small set of non-feature phone dependent issues that we noticed during our tests.

III

Declaration

Hereby I declare that I have produced my work independently and have named allsources and additives which I have used.

Berlin, January 17, 2011

Nico Golde

Acknowledgements

I would like to thank Professor Jean-Pierre Seiffert for letting me write this thesis athis research group as well as Collin Mulliner for his support and feedback during thework. Without this none of the presented work would have been possible. Furthermore,I would like to thank Kevin Redon, Sebastian Tiesler, Andreas Krennmair and MartinZuber for their input and reviews of this thesis.

Contents

1 Introduction & Motivation 11.1 Contribution of this Thesis . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Related Work 32.1 Mobile Phone Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Mobile Malware . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2 Application Security . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.3 Baseband Security . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 SMS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.1 SMS Security Network Side . . . . . . . . . . . . . . . . . . . . . 52.2.2 SMS Design Weaknesses . . . . . . . . . . . . . . . . . . . . . . . 52.2.3 Implementation Weaknesses . . . . . . . . . . . . . . . . . . . . . 6

2.2.3.1 MMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.3.2 SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 GSM infrastructure/procedures and SMS 93.1 Historic Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.2 SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.2.1 Applications of SMS . . . . . . . . . . . . . . . . . . . . 103.2 Base Station Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.1 Base Transceiver Station . . . . . . . . . . . . . . . . . . . . . . . 123.2.2 Base Station Controller . . . . . . . . . . . . . . . . . . . . . . . 12

3.3 Network Switching Subsystem . . . . . . . . . . . . . . . . . . . . . . . . 123.3.1 Mobile Switching Center . . . . . . . . . . . . . . . . . . . . . . . 133.3.2 Home Location Register . . . . . . . . . . . . . . . . . . . . . . . 133.3.3 Visitor Location Register . . . . . . . . . . . . . . . . . . . . . . 143.3.4 Short Message Service Center . . . . . . . . . . . . . . . . . . . . 14

3.3.4.1 SMS-GMSC . . . . . . . . . . . . . . . . . . . . . . . . 153.3.4.2 SMS-IWMSC . . . . . . . . . . . . . . . . . . . . . . . . 153.3.4.3 Message Submission . . . . . . . . . . . . . . . . . . . . 153.3.4.4 Message Delivery . . . . . . . . . . . . . . . . . . . . . . 15

3.4 Considerations Regarding Vulnerability Analysis . . . . . . . . . . . . . 163.4.1 Feature Phones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4.2 Used Hardware/Software . . . . . . . . . . . . . . . . . . . . . . 17

3.4.2.1 nanoBTS . . . . . . . . . . . . . . . . . . . . . . . . . . 18

IX

Contents

3.4.2.2 OpenBSC . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Vulnerability Analysis 214.1 Introduction & Requirements . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Target Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3 SMS Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3.1 SMS PDU mode/SMS_SUBMIT . . . . . . . . . . . . . . . . . . 234.3.2 SMS UDH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.4 OpenBSC Modifications and Additions . . . . . . . . . . . . . . . . . . . 274.4.1 Sending SMS Messages . . . . . . . . . . . . . . . . . . . . . . . 27

4.4.1.1 Injection of Pre-encoded SMS . . . . . . . . . . . . . . 274.4.1.2 Other Small/Useful Additions . . . . . . . . . . . . . . 28

4.4.2 Monitoring for Phone Behaviour . . . . . . . . . . . . . . . . . . 284.4.2.1 Feedback From the Phone . . . . . . . . . . . . . . . . . 294.4.2.2 Network Events . . . . . . . . . . . . . . . . . . . . . . 304.4.2.3 Monitoring via J2ME . . . . . . . . . . . . . . . . . . . 31

4.4.3 Log Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4.4 Other Possibilities . . . . . . . . . . . . . . . . . . . . . . . . . . 344.4.5 Crash Analysis/Decoder . . . . . . . . . . . . . . . . . . . . . . . 34

4.5 Fuzzing Test-cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.5.1 TP-Data-Coding-Scheme/TP-Protocol-Identifier . . . . . . . . . 354.5.2 User-Data-Header . . . . . . . . . . . . . . . . . . . . . . . . . . 364.5.3 Multipart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.5.4 Simple Text Messages . . . . . . . . . . . . . . . . . . . . . . . . 374.5.5 Flash SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.5.6 VCard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.5.7 Enhanced Messaging Service . . . . . . . . . . . . . . . . . . . . 394.5.8 MMS Notification . . . . . . . . . . . . . . . . . . . . . . . . . . 404.5.9 WAP-push Service Indication . . . . . . . . . . . . . . . . . . . . 414.5.10 (U)SIM Data Download . . . . . . . . . . . . . . . . . . . . . . . 41

5 Evaluation 455.1 Feature Phone Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.1.1 Nokia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.1.2 Sony Ericsson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.1.3 LG Electronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.1.4 Motorola . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.1.5 Samsung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.1.6 Micromax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.2 Other Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.2.1 Operator Differences in SMS Delivery . . . . . . . . . . . . . . . 505.2.2 Spoofing Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2.3 SMS DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.3 Counter Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.3.1 Network Side SMS Filtering . . . . . . . . . . . . . . . . . . . . . 52

X

Contents

5.3.2 Firmware Updates . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6 Conclusions 55

Glossary 57

Bibliography 59

7 Appendix 657.1 Deutsche Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 65

XI

List of Figures

3.1 GSM network infrastructure components . . . . . . . . . . . . . . . . . . 113.2 Fuzzing Setup using nanoBTS . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1 Simple SMS message encoding “hello world” . . . . . . . . . . . . . . . . 254.2 SMS User-Data-Header structure (picture taken from 3GPP TS 23.040) 264.3 Mobile terminated SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.4 Logical view of our setup. . . . . . . . . . . . . . . . . . . . . . . . . . . 324.5 Concatenated Message consisting of 2 messages . . . . . . . . . . . . . . 374.6 Flash SMS encoding “Hello World” . . . . . . . . . . . . . . . . . . . . . 384.7 EMS encoding “Hello” in bright yellow font on dark red background . . 394.8 MMS Indication - sender: barbaz, subject: foobar, http://google.com . . 40

5.1 Timing of SMS message delivery attempts. . . . . . . . . . . . . . . . . 50

XIII

List of Tables

4.1 Mobile phone Manufacturer Market share . . . . . . . . . . . . . . . . . 434.2 Format of the SMS_SUBMIT PDU. . . . . . . . . . . . . . . . . . . . . 44

XV

1 Introduction & Motivation

Mobile phones have become a crucial part of our daily lives and people rely on themfunctioning in many situations. Especially in emergency situations they have become adire necessity. With the rising usage of mobile phones, security concerns affecting thememerge as well. In the recent years a lot of research has been put into vulnerabilityanalysis on smartphones (See Section 2), totally neglecting structured research on so-called feature phones.

Yet feature phones, mobile phones that have additional capabilities besides voicecalls and text messaging (e.g. the possibility to install Java applications), make up thelargest percentage of mobile phones deployed in mobile networks. The lack of structuredresearch is partly due to the fact that smartphone operating systems often provide openprogramming interfaces and debugging capabilities. The hardware and especially theoperating systems are closer to desktop computers. Smartphones are also an attractivetarget as they are mostly used by business people.

However, in comparison smartphones only account for about 16% of all mobilephones [Aho10b]. As a result of this, billions of feature phone users (there are morethan 4 billion mobile phone subscribers worldwide1) are left with devices that may bevulnerable to all kinds of attacks. Nevertheless, due to the popularity of those phonesthey are an attractive target for large scale attacks against a mobile phone network andits users. The goal of the research presented in this thesis is to fill this gap betweenpopularity and security research in the area of mobile phones.

A complete security study of a wide variety of phones of various manufacturers andtheir features is not possible in the scope of this thesis. Still the security of these devicesis important so our interest is to pick one feature that is widely deployed and do anin-depth test on a wide variety of phones. As a result of this, the focus of this thesisis the Short Message Service (SMS) as an attack vector. It provides a feature thatis available on every feature phone. From an attackers perspective SMS is the mostinteresting feature besides voice calls, since it requires no or very little user interactionto exploit.

1.1 Contribution of this Thesis

The work presented in this thesis provides a study of the security of feature phones andespecially the security of SMS implementations. While this novel approach presentedin this thesis is intended for the analysis of feature phones it is not necessarily limitedto them and can also be used to analyze smartphones.

1 http://www.bitkom.org/de/presse/62013_60608.aspx

1

http://www.bitkom.org/de/presse/62013_60608.aspx

1 Introduction & Motivation

The main contribution of this thesis is to show how to utilize a GSM network toanalyze feature phones for SMS vulnerabilities despite the lack of debugging possibilitieson the phone.

Specific contributions are:

• Vulnerability Analysis of Feature Phones: We introduce a novel methodfor a platform independent feature phone security analysis, specifically SMS. Thisapproach is not based on modifications directly on the phone, but instead the GSMnetwork side is utilized to monitor phones for crashes and misbehaviour. To doso, Open Source software to operate a GSM network was modified for monitoringand gathering “feedback” from the phone.

• Feature-rich Fuzzing Suite for SMS: Further a feature-rich set of fuzzingscripts is developed in order to cover a wide range of features used in nowadaysSMS implementations.

• Bugs Present in Phones by the Top Manufacturers: We present the effec-tiveness of the developed framework by conducting a study of the major manufac-turers of feature phones and describe the security issues discovered by us.

1.2 Structure

This thesis is structured as follows: Chapter 2 provides a general overview about previ-ous security studies on mobile phone security, in specific SMS security. Chapter 3 givesan introduction into GSM network infrastructure, which parts are relevant for SMSdelivery and the components we used to build a minimal GSM network and use it toconduct a security study. In Chapter 4, we present an introduction to SMS encodingsand describe a novel approach to conduct a study of SMS security vulnerabilities onfeature phones. In Chapter 5, several feature phones of major manufacturers are ana-lyzed and the SMS fuzzers are presented. Chapter 6 discusses our findings and possiblethreats on feature phones. We further give a short overview about possible countermeasures to the found flaws.

2

2 Related Work

In the recent years a lot of research was done on mobile phone application security,especially on smartphone devices. This chapter presents an overview of previous researchon mobile devices and specifically on SMS/MMS security.

2.1 Mobile Phone Security

A lot of effort has been put into the security of mobiles phones, mostly smartphone basedon the Android [Ope], Apple iOS [App10], Symbian [Sym] or Windows Mobile [Micb]platforms. In-depth research on feature phone security does not exist to our knowledge.

2.1.1 Mobile Malware

In [Mul08] the author developed a proof-of-concept self signing mobile malware forSymbian. A similar research has been conducted in [MB07] by analysing the possibilitiesof a self-spreading worm running on Windows Mobile devices. The authors built aproof-of-concept worm and showed that it is possible to develop a malicious smartphoneapplication that can reliably infect devices and spread over wireless LAN. This threatclass however depends on a software vulnerability on the device that can be exploitedin order to gain control over the device.

Another possibility is a user installing untrusted software to the device on his own. AnExample for this is the first iPhone worm named ikee [F-S09] which infected jail-brokeniOS devices through default SSH [IET06] passwords only altering the devices wallpaper.Trojan-SMS.AndroidOS.FakePlayer.a [Kas10] covered itself as a media player later send-ing out premium-rate SMS messages. While these are manufacturer/operating systemspecific there have been as well malicious, platform independent applications based onJ2ME [SUN] that are able to run on feature phones. Trojan.Redbrowser.A [Sym06] wasadvertised as a legitimate application, pretending to allow users to browse WAP [WAP]sites without using a WAP connection, while sending out premium-rate SMS messageson their behalf. These threats are not new and can be seen as an act of porting existingknowledge about computer malware to portable devices.

2.1.2 Application Security

A lot of research has been put into the area of application security on the mobile device.Based on the plain mass of third-party software (e.g. PDF readers have been high profiletargets), web browsers and libraries, the attack surface is high. This research also focusesmostly on smartphones. This is partly due to the fact that most smartphones can bebetter utilized for debugging and system modifications than typical feature phones.

3

2 Related Work

One reason for this is the partial openness of these systems that allow users to heavilymodify the smartphone operating system. Either via jail-breaking [iPh] (in the caseof the iPhone) or through the possibility of installing custom software (native codeapplications) beyond typical J2ME applications to the system. In [Mil07] the authorsconducted a comprehensive security analysis of the iPhone platform. They built twoexploits demonstrating the high impact of vulnerabilities in the Safari [Appa] browserused on the phone. Both exploits gained access to the phone via a malicious HTMLpage. The first exploit caused the phone to send personal data from the phone toa remote server under the control of the attackers. The payload used in the secondexploit, also targeting a browser weakness, triggered physical actions such as vibrationor system sounds. In [VI10] a browser vulnerability was used to steal SMS data fromthe phone while technically the exploit could have also gathered other data from thephone.

A similar effort [CM08] has been put into the Android platform revealing securityproblems in the system’s browser. Android consists of a huge amount of third-partyOpen Source pieces that were not all up-to-date with upstream sources. Some of themincluded known vulnerabilities leading to the browser compromise. The impact of thisissue has been limited to the browser process because of the security architecture of theAndroid system. However such issues are often combined with a second vulnerabilityenabling an elevation of privileges, e.g., in the case of recent jail-breaking. This wasalso the reason for another recent security vulnerability [The10] which exploits [Kei10]a bug in the Webkit [Appb] rendering engine used on Android and also by the Safaribrowser.

2.1.3 Baseband Security

A new research field is the area of bugs in the Baseband firmware. The Basebandchip is usually a dedicated piece of hardware which is responsible for receiving andtransmitting GSM frequencies, modulation and demodulation, digital signal processing,and the GSM protocol stack. This new research [Wei10] focuses on problems in theGSM protocol stack that is driven by software. The author focused on security bugs inlayer 3 [3GP98c] of the GSM stack. Layer 3, consisting of Radio Resource Management(RR), Mobility Management (MM) and Connection Management (CM) is responsible forestablishing, operating, and releasing dedicated radio channels, network authentication,handling calls and other procedures involving complex protocols.

He identified a number of typical programming errors leading to memory corruptions,information leaks, state engine confusion, and other unexpected system behaviour withsecurity impact. Contrary to the previous research in this scenario the GSM network isthe evil counter part. The author exploited one of the found issues by using a USRP [Ett]to switch on the automatic call accept feature of a victims iPhone that believes it isconnected to an operator cell, while associating with this rogue USRP-powered cell.

4

2.2 SMS Security

2.2 SMS Security

Security problems in Short Message Service (SMS) implementations have been investi-gated in the past. However most of the discovered problems have been related to logicerrors, were focusing on the network side or were found by accident. It is also interestingto note that the conducted studies focus almost exclusively on smartphones. The ShortMessage Service (SMS) is an interesting area to conduct mobile phone security studiesas it is probably the most widely deployed service besides the ability to do calls anda lot of customers rely on it. It is also a service that requires no or only limited userinteraction as we will see later.

2.2.1 SMS Security Network Side

In [TEMLP08] the authors conducted a study on security of the SMS infrastructureinside a GSM operator network to find the security impact of SMS to the overall avail-ability of the network. Based on the possibility to send SMS messages from the internetto customers inside the GSM network the authors evaluated the possible risks whentraffic is crossing these two neworks. They demonstrated the possibility of DistributedDenial of Service (DDoS) attacks against the mobile telecommunication infrastructureof a large city. SMS works in store-and-forward fashion. This means that a message isnot directly sent from one customer to another, but instead stored inside the networkand then delivered from the network to the recipient side.

This queueing and forwarding is done by a Short Message Service Center (SMSC) ofwhich usually more than one exist in a GSM network. The study focuses on the factthat these SMSCs are typically responsible to store and forward messages for a certaingeographical area and the limited resources of the SMSC. By carefully targeting mobilephone numbers in a specific area and with the use of fast internet bulk SMS providers,they have been able to overload the SMS infrastructure inside the network. This alsocaused message loss because of queuing at the SMSC.

2.2.2 SMS Design Weaknesses

Multiple studies [dH01, Mob09a, Mob09b, Lac09] have been conducted in the area ofSMS design issues/logic errors. The presented attacks range from being plain annoyingto real security threats. Besides the normal text messaging by mobile phone users,a lot of administrative payloads are sent in the background mostly unnoticed by theuser. An example for this are certain binary messages sent to mobile customers of someoperators that indicate the receipt of new voicemail messages. When a customer gets anew voicemail, the operator sends a special binary SMS to the phone of the customer.This advises the phone to display a certain amount of new voicemail messages. Afterthe customer checked his voicemail the operator will send another message resettingthe counter to zero. These messages are however not authenticated and are not limitedto being sent by an operator. Another problem is spoofing of sender addresses. Since

5

2 Related Work

there is no way to authenticate the originating address of an SMS, customers have beensubject to online services1 offering the transmission of spoofed messages.

Additional to such plain annoying attacks there exist a number of weaknesses tar-geting Over-the-Air (OTA) programming of mobile phones. This is used by carriersto push settings to the mobile phone via SMS, but can also include firmware updates.A popular use for this are internet settings needed by the customer to enable properaccess to GPRS/UTMS gateways. These messages are authenticated based on securitymechanisms using HMAC to protect customers from accepting malicious messages fromuntrusted sources. However the shared secrets in this process are not secure and oftenrely on the International Mobile Subscriber Identity (IMSI) number. Due to the possi-bility of online lookups and IMSIs not being completely random this is an insufficientsecret. It has been demonstrated [Mob09a, Mob09b] how this can be abused to sendmalicious provisioning data to customers allowing an attacker to hijack/eavesdrop inter-net connections of the mobile phone by reconfiguring proxy settings. On most mobilephones it is not possible for the user to distinguish between a real carrier configurationSMS and a spoofed one. In some cases, received configurations are as well installedautomatically. The research in this thesis will not focus on such design problems.

2.2.3 Implementation Weaknesses

Probably most of the research on mobile phones has been focusing on implementationproblems of installed applications. These applications are often not core functionalitydeveloped by the manufacturer, but instead third party applications installed to thephone.

2.2.3.1 MMS

In [MV06] the authors built a framework for security analysis of Multimedia Messag-ing Service (MMS) client implementations of smartphones. To prevent sending largeamounts of test cases over a real carrier network, the authors made use of the MMSclient also accepting messages via a port on its wireless LAN interface. The authorsconducted fuzz-based testing of a Windows Mobile device. They found and exploitedseveral vulnerabilities of which some lead to arbitrary code execution.

This has partly been possible due to the nature of MMS relying on port addressingand thus also (in the past) exposing an interface to other networks besides GSM whichopens up the device for in-depth analysis involving large amounts of test cases.

2.2.3.2 SMS

A fuzz-based, structured approach towards fuzzing SMS on mobile phones has beenpresented in [MM09]. The authors built modifications for Windows Mobile, Android andiOS phones that allowed them to inject messages directly on the mobile phone withoutgoing through the carrier network. This research identified several vulnerabilities leadingfrom denial of service conditions on the phone (interrupt calls) to remote code execution

1 An example should be http://www.smsgang.com/, many more exist

6

2.2 SMS Security

on the iPhone. Unfortunately modifications to the phone had to be done for eachmanufacturer individually and are to our knowledge not possible on feature phones.There have not only been implementation problems that were found by a structuredsecurity analysis.

Other vulnerabilities affecting only a small number of devices have been found byaccident in the past. A special SMS containing email payload [Eng08] that becamefamous under the name Curse of Silence, allowed an attacker to completely disablethe functionality of receiving SMS messages on a victims Nokia phone until a factoryreset has been done. Another issue [@st03] affecting Nokia 6210 devices, caused bya format string vulnerability in the VCard parser, lead to phone reboots, terminationof the SMS receiver handler or locked up phones until the battery was removed. TheSiemens 3568i device has been vulnerable to a denial of service bug [XFo02] causingthe mobile to switch itself off when trying to display certain characters of the message.

These findings are fundamentally different from the work presented in this thesis. Weaim to present a platform independent solution that allows us to identify such flaws ina structured approach on a wide variety of phones. The previous work either focusedon smartphones partly due to the ease of modifying them or identified problems byaccident that affected a very small number of devices.

7

3 GSM infrastructure/procedures and SMS

This chapter will give an introduction to GSM and more specifically SMS technology.The goal of this chapter is to give the reader an idea about the components used tosuccessfully transfer text messages from one subscriber to another without going intodetails of involved protocols.

3.1 Historic Background

As SMS is based on GSM, we start with a short historical outline of GSM and SMS.

3.1.1 GSM

In 1982 the Groupe Spécial Mobile (GSM, later known as the Global System of MobileCommunications) started working on a mobile phone telecommunication system. Thissystem should allow customers across Europe mobile communication and can inter-change information with the existing analogue and Integrated Services Digital Network(ISDN) telephone technology. A memorandum of understanding between 13 Europeancountries was signed agreeing on the development of a common cellular telephone net-work which should form the basis of what GSM is. In 1989 GSM was given in custody ofthe European Telecommunications Standards Institute (ETSI [Ets]). During the sameyear the Deutsche Bundespost and Mannesmann in Germany acquired licenses to oper-ate GSM networks at 900 MHz. The specification for GSM-900 was frozen in 1990 andshould form the basis for all later GSM specifications, this has been phase I of the GSMspecifications. Based on this specification the first public GSM network went live 1991in Finland. Derived from GSM-900 the specifications for GSM-1800 which should allowthe operation of a network in the 1.800 MHz frequency spectrum were released. In 1992the first GSM mobile phones haven been sold to the general public and the first carriersstart to conquer the market. GSM as a new technology for mobile phone communicationhas been a huge success. Referring to a report1 there were more than 4 billion mobilephone users world wide in 2009.

3.1.2 SMS

The Short Message Service (SMS) was designed as a technology that enables customersin mobile telecommunication networks to send and receive text message between mobilephones. The initial concepts for SMS have been developed in 1984. The key idea atthis time has been to deliver text information on signalling channels needed by GSM.As a voice call is using traffic channels, this should better utilize the signalling channels

1 http://www.bitkom.org/de/presse/62013_60608.aspx

9

http://www.bitkom.org/de/presse/62013_60608.aspx


during this time period. This also allows to receive a message while a voice call isactive. To make this technically possible it has been necessary to limit the length oftext messages to 128 characters. Later this length was extended to 140 characters and160 characters (if the characters are 7-bit encoded). International encodings includingArabic, Chinese and others are supported through 16-bit UTF-16 encoding, allowing upto 70 characters.

An important advantage to the prior used pager technology was that the messagingprocess happens in store-and-forward fashion. The recipients mobile phone can beswitched off at the time the message is sent. The message is stored in the carriers networkuntil the subscriber associates with the network again. These days SMS completelyreplaced the pager technology.

In 1993 SMS has been commercially deployed in Finland and was released as a partof the GSM phase 2 specifications.

SMS can not only send text messages, but can also contain binary content. Thiswas used to incorporate WAP [WAP] services into SMS. This was also the basis for theEnhanced Messaging Service (EMS) [3rd04b]. EMS was developed to extend traditionalSMS messaging with possibilities for rich text formatting, embedding of pictures, sound(e.g. ringtones), and animations. With the Smart Messaging Specification [Nok00],Nokia developed a proprietary alternative to EMS that was not widely adopted throughother manufacturers.

SMS has been very successful since its introduction. Referring to a report2 the world-wide population sent about 5 billion messages per day with a growing tendency despiteother possibilities for communication like Email and Instant Messaging.

3.1.2.1 Applications of SMS

Besides the traditional exchange of text messages between subscribers in a GSM networkSMS is nowadays used in various areas. It is widely deployed and a lot of customersrely on it in many situations. This includes (but is no complete list):

• Notifications: E.g. voicemail and Fax messages

• Over-The-Air (OTA) programming: Provisioning data and phone settings

• Interchange with other protocols: E.g. Email/Fax gateways

• Electronic payment: Premium-rate SMS services

• Two-Factor Authentication: TANs in SMS, e.g., for online banking

• Monitoring: Often used as a way to alert employees in case of problems

• Machine to machine (M2M) communication

• Advertising and Spam

2 CTIA The Wireless Association Announces Semi-Annual Wireless Industry Survey Results http://

www.ctia.org/media/press/body.cfm/prid/1936

10

http://www.ctia.org/media/press/body.cfm/prid/1936

http://www.ctia.org/media/press/body.cfm/prid/1936

3.2 Base Station Subsystem

Figure 3.1: GSM network infrastructure components

Following is a listing of GSM infrastructure components. This list is by no meanscomplete. Components like the Authentication Center (AuC), Equipment Identity Reg-ister (EIR) and Operation and Maintenance Center (OMC) are not explained in thisthesis as they are unimportant for the scope of this work.

3.2 Base Station Subsystem

The Base Station Subsystem (BSS) combines the GSM components responsible for han-dling traffic between mobile phone subscribers and the Network Switching Subsystem. Itis responsible for handling radio related procedures and components that are responsiblefor the allocation of radio channels, changes between radio cells (also called Handover),receiving and transmitting Over-the-Air interface (also called Um interface3) and others.Its components are the following.

3 after the mobile analog to the U interface of ISDN

11


3.2.1 Base Transceiver Station

The Base Transceiver Station (BTS) – also called GSM cell or (incorrectly) Base Station– is a piece of hardware responsible for receiving and transmitting (Transceiver) dataOver-the-Air. This is the network entity in direct contact with the mobile station(mobile phone) and communicates with the Base Station Controller (See Section 3.2.2)on the network side. It is the edge node of the GSM network, every traffic to the mobilephone from the network or from the phone to another network will cross a BTS.

A BTS is responsible for handling signals in a certain geographical area (GSM cell).It is broadcasting an identifier for the current location (Location Area Code, LAC) thatis shared among all BTSs in a certain area and a unique Cell Identifier (CI). In biggerareas usually more than one BTS is used to ensure optimal radio coverage connectivity.One or more BTSs are controlled by the Base Station Controller. The BTS is alsotaking care of encryption and decryption of the communication between mobile phoneand network, allocation and deallocation of frequency channels, association of the phonewith the network and everything that is signalling related. The BTS is no self-containeddevice like other Base Station devices in wireless communications. It can not functionwithout a Base Station Controller.

3.2.2 Base Station Controller

The Base Station Controller (BSC) controls a group of BTSs. It is basically a switchbetween the rest of the GSM network and the BTSs. It is aggregating information aboutthe BTSs in an area. It keeps track of used radio resources, is responsible of holding theconnection in case a subscriber connection switches inside two BTSs (Handover) as wellas handling call setup procedures and location updates for each mobile phone in the areaof the controlled BTSs. It is also is responsible for deciding when a Handover is necessaryby analysing measurement results gathered during a call. The BSC is communicatingto the BTS system via an A-bis interface and is connected to the Mobile SwitchingCenter (See Section 3.3.3) through a Transcoder and Rate Adaption Unit (TRAU). TheTRAU is used to do speech transcoding between the compressing GSM coded speech(13 kbit/s) and ISDN coding (64 kbit/s)4.

3.3 Network Switching Subsystem

The Network Switching Subsystem (NSS) is the switching center for data connectionssuch as voice calls or SMS from inside the Base Station Subsystem. It is also an interme-diator between the GSM network and the Public Switched Telephone Network (PSTN)5.As a core network component it is crucial for the possibility to establish a call betweentwo phones. It consists of components that are able to handle the fact that mobilephones are not at a fixed location and can move inside and between BSSs. It also han-

4 Assuming that the TRAU is part of the BSC, depending on the network design it can also be part ofthe BTS and transcoding between GSM and ISDN can be performed within the BTS

5 normal land line network

12


dles registration and authentication with the GSM network. Following are descriptionsof the components included in the NSS.

3.3.1 Mobile Switching Center

The Mobile Switching Center (MSC) is the central entity responsible for the previouslymentioned switching within the NSS. Since mobile phones are only in direct connectivitywith a BTS, switching and routing between phones needs to be done. The MSC isrouting voice calls, SMS and other services within the GSM network. It also acts asa switch between the GSM network, the PSTN, and other inter-workings. To performproper routing it is connected to a set of BSCs using the A interface. The main dutiesof the MSC are Mobility Management (MM) and Call Control (CC). The MM is themain difference compared to public land line network switching. Since users in a mobilephone network can rapidly change their geographical location and thus connectivity withspecific cells, the MSC has to know where inside the network a subscriber is (which BTSis connected to it) to do routing. Also it has to take care that phones registering orchanging locations are authenticated with the network. As a lot of components in a GSMnetwork, an MSC is also responsible for a certain geographical area and is connected toother MSCs over the so-called E interface to perform handover procedures. To do allthis, the MSC is connected to several smaller components assisting in the procedures,namely the SMSC, VLR, HLR and AUC (see the following sections). So the MSC is incharge of [DH03]:

• Connection establishment between subscribers

• Tracking billing information

• Registration and Authentication of subscribers

• Handover procedures including inter-MSC handovers

• Location updating

• Interconnection of PSTN and other mobile phone networks

• Call routing

3.3.2 Home Location Register

The Home Location Register (HLR) serves as a central database storing informationabout subscribers. Most of the stored information is related to the location of a mobilephone inside the network in order to route calls. Every Public Land Mobile Network(PLMN)6 has at least one HLR keeping track of who is registered in the GSM networkin conjunction with his current location. This information is updated in the HLR atthe moment a mobile phone is switched on and registers with the network. It is as wellconstantly updated, if the phone is in idle state, to ensure the HLR is always aware of

6 Term used to describe all mobile wireless networks that use earth-based stations. It is the mobilecounterpart of the PSTN.

13


the latest location and the network is able to establish a connection to the phone. Foreach subscriber it stores the International Mobile Subscriber Identity (IMSI) and theMobile Subscriber ISDN Number (MSISDN). The IMSI is a unique identifier attachedto the phones SIM card and MSISDN is the normal telephone number. Besides thissubscriber information the HLR stores [3rd04a]:

• Location information (Visitor Location Register number)

• Basic telecommunication services subscription information

• Service restrictions (e.g. roaming limitations)

• Supplementary services; the tables contain the parameters attached to these ser-vices

• GPRS subscription data and routing information

3.3.3 Visitor Location Register

Each MSC has a Visitor Location Register (VLR) attached to it (or is part of theMSC) that stores temporary information about the subscribers in the area handled bythe MSC. When a mobile phone is moving into the area serviced by an MSC and isperforming a location update, the responsible VLR is requesting subscriber informationfrom the HLR. Since the HLR is a central entity, the VLR acts like a cache in thissituation. When the subscriber issues a phone call, the VLR has all needed subscriberinformation and does not need to query the HLR every time. The VLR also recordsthe Location Area (LA) of the mobile phone. This is a unique identifier that can bemapped to geo-coordinates and is composed of a Mobile Country Code (MCC), MobileNetwork Code (MNC) and a Location Area Code (LAC). If a subscriber leaves the areaof the specific MSC, the data is deleted from the VLR.

3.3.4 Short Message Service Center

The Short Message Service Center (SMSC) is the network component required for send-ing and receiving SMS messages. Every operator that supports sending of SMS messagesneeds at least one SMSC in his network. Due to the popularity of SMS it is common thatoperators have multiple SMSCs. The SMSC is usually a combination of software andhardware and its job is to forward and relay SMS messages to the destination phone orother SMSCs (in case of inter-operator messages or an operator with multiple SMSCs).SMSCs work in store-and-forward fashion so that messages addressed to mobile phonesthat are switched off do not get lost. If the recipient is not available, the message isstored in the SMSC until a certain amount of time has passed or until the subscriber isavailable again. The specifics of this are usually operator dependent. Besides routing,storing and forwarding the SMSC also provides the delivery confirmation service oftenused for SMS.

The SMSC is linked to the network via two gateways [3rd04a], the SMS-GatewayMobile Switching Centre (SMS-GMSC) and SMS Interworking Mobile Switching Centre

14


(SMS-IWMSC). As they are usually integrated directly within the SMSC they are leftout in Figure 3.1.

3.3.4.1 SMS-GMSC

To route messages to a destination number, the SMSC needs to know where in thenetwork the recipient is. For this the SMS-GMSC is used. It queries the HLR for thesubscriber information and delivers the message to the MSC in charge.

3.3.4.2 SMS-IWMSC

The SMS-IWMSC provides access to the SMSC for submitting a message from the phoneto the network. The SMS-IWMSC queries the HLR to obtain a route to the destina-tion number and sends the message to an SMSC in the area handling the destinationsubscriber.

3.3.4.3 Message Submission

The format of an SMS is different in each state of the store and forward operation. SMSexist in two formats, SMS_SUBMIT and SMS_DELIVER, depending on if the message is sentfrom a mobile phone to the corresponding SMSC (MO/Mobile Originated) or from theSMSC to a mobile phone (MT/Mobile Terminated). In order to submit a message to theSMSC, the mobile phone has to address it. The SMS_SUBMIT encoding can encode anSMSC address which is an ordinary telephone number in international number format.Often this information is not included in the message itself, but instead a fixed SMSCaddress is used that is encoded on the SIM card in the phone. In this case the specificSMS field is set to zero. The message first hits the MSC that queries the VLR to getinformation on the sender of the message (e.g. to check if the subscriber is allowed toaccess a certain service). Besides the possibility to inject a message via a phone intothe network, this service is also offered by so-called External Short Message Entities(ESMEs), e.g., in the form of web SMS gateways [Rou, Cli]. Afterwards the message isforwarded to the SMS-IWMSC. To determine further routing information it queries theHLR and forwards the message to the destination SMSC.

3.3.4.4 Message Delivery

The SMSC passes the message to the SMS-GMSC. To acquire the final routing informa-tion and to find out if the MSISDN is registered, the SMS-GMSC also queries the HLR.The message is then passed to the MSC in charge of the destination subscriber. After-wards the MSC queries the VLR to get subscriber information as well as the LocationArea and thus the cell in charge of the destination. Based on this information the MSCdelivers the SMS over the BSC to the corresponding cell, from where it is transmittedOver-the-Air to the mobile phone in SMS_DELIVER format.

15


3.4 Considerations Regarding Vulnerability Analysis

The following will give an introduction to things to consider when doing vulnerabilityanalysis on feature phones with a GSM network as well as introducing the used soft-and hardware.

3.4.1 Feature Phones

What is the difference between a feature phone and smartphone and why does it matterfor security analysis? Most of the definitions of the term feature phone are a bit fuzzy.A loose definition of the term is: Every mobile phone that is neither a dumb phone nora smartphone is considered a feature phone. Dumb phones are phones with minimalfunctionality, often they only support issuing phone calls and sending SMS messages,just basic functionality. Feature phones have less functionality than smartphones, butstill more than dumb phones.

Feature phones have proprietary operating systems (firmware), add additional fea-tures (thus the term Feature) such as playing music, surfing the web, and runningsimple applications (mostly J2ME [SUN] or BREW [Qua]). The application platformsare less integrated into the operating system, have less abilities to interact with otherapplications on the phone, and have far less advanced APIs compared to open APIs onsmartphones. Smartphones often provide the ability to run native code.

Despite this lack of features they are quite popular because they are cheap and offera long battery life. A more technical definition of feature phones is given by HaraldWelte in [Wela]:

A feature phone is a phone that runs the GSM protocol stack (the softwareimplementing the GSM protocol) as well as the user interface and all appli-cations on a single processor. For historic reasons, this processor is knownas the so-called baseband processor (BP).

The baseband processor often exposes a serial port (or today USB) overwhich the phone can be used as a terminal adapter, similar to old wirelinemodems. The industry standard protocol for this interface is an AT com-mand set - extended and modified from how computers interfaced old wire-line modems. The AT-command interface can be connected to a computer.The computer can then use the phone to establish data calls, send/receiveshort messages via SMS, and generally remote-control the phone.

All this has implications from the point of a vulnerability analysis. Without thepossibility to run native code on the phone, an injection-based approach like conductedin [MM09] is not possible. This relies on the possibility to hook system libraries and/ordo modifications directly on the underlying operating system. While the injection-basedmethod is nice, it also has a drawback that is related to how a typical GSM stack isdivided into separate layers.

The GSM stack in the BaseBand is divided into 3 layers. Layer 1 (physical layer) pro-vides functions required for the transmission of bit streams Over-the-Air via GSM chan-

16


nels. Layer 2 on the mobile phone (data link layer) uses a simplified version (LAPDm7)of the LAPD protocol that is used in ISDN layer 2. Layer 3 is subdivided into 3 parts,Radio Resource management (RR), Mobility Management (MM) and Connection Man-agement (CM). The RR layer is responsible for establishing and managing the linkbetween the mobile phone and the BTS. The MM layer has a similar purpose as MMof the MSC. The CM layer is responsible for Call Control (CC), supplementary servicemanagement such as call forwarding, and Short Message Service management.

By injecting SMS directly into the phone’s operating system, the drawback is a com-plete bypass of this CM layer that may contain bugs as well. This layer is processingSMS encodings and formats before the SMS hits the user interface on the phone. Eventhough on feature phones the difference is rather small. Because of the single-processordesign, a bug in the BB code as well as in the application layer code is very likely tobring down the complete phone.

On account of the poor APIs and proprietary operating systems of feature phones thisleaves us with nearly no suitable way for security analysis of the SMS implementation.It is possible to download firmware images and reverse engineer them in order to findvulnerabilities. However for a large scale analysis of feature phones this is no viableapproach as it is very time consuming. Also analyzing the part of the phone thatinteracts with the mobile phone network is hard since we have a large black box betweenus and the target device: the mobile phone network.

Therefore we decided to utilize the GSM network infrastructure for an approach basedon fuzzing. Fuzzing can be defined [Oeh05] as:

A highly automated testing technique that covers numerous boundary casesusing invalid data (from files, network protocols, API calls, and other targets)as application input to better ensure the absence of exploitable vulnerabil-ities. The name comes from modem applications’ tendency to fail due torandom input caused by line noise on “fuzzy” telephone lines.

Fuzzing will be conducted on the various SMS encodings and formats. The termfuzzing is usually divided into dumb fuzzing and smart fuzzing. Dumb fuzzing is the pro-cedure of completely random encoded data without taking specifications into account.Smart fuzzing is aware of used data structures, encodings and protocols. The test casesare not completely random. As SMS formats are fairly complex and have to pass severalstages between submission and transmission to the recipient, dumb fuzzing is not anoption. Instead we decided to conduct smart fuzzing by building a set of fuzzers basedon the python SMS library [Mul] used in the injection-based efforts.

3.4.2 Used Hardware/Software

What about the network infrastructure? To drive a GSM network besides a softwarestack implementing the BSC and NSS we also need hardware to function as a BTS.

17


Figure 3.2: Fuzzing Setup using nanoBTS

3.4.2.1 nanoBTS

We decided to use an ip.access nanoBTS 165AU [ip.] (nanoBTS in Figure 3.2) whichis a small, fairly cheap (about 5000 Euros) GSM Base Transceiver Station (BTS) thatprovides an A-bis over IP interface. The A-bis interface is used to communicate betweenthe BTS and the Base Station Controller (BSC) that can be implemented in software.An alternative would have been a Siemens BS11 [Sie] which has the drawback of aslightly bigger size and not being able to make use of A-bis over IP. We can operate thisnanoBTS on the 1800 MHz GSM spectrum.

3.4.2.2 OpenBSC

There has been no Free Software implementing GSM stacks for years. This is partlydue to the closeness of the GSM industry. While the GSM protocol specifications areavailable (very comprehensive though, over 1000 pdf documents) there are very fewmanufacturers of GSM equipment and those never released any public documentation.There are only about four closed-source protocol stacks [Wel09] that are licensed by thebaseband chipset manufacturers.

This situation has changed in the last years with the development ofOpenBSC [Wel08], OpenBTS [Kes08], the recent development of OsmocomBB [Welb]and a lot of reverse engineering efforts. With the reversing of sold hardware to runGSM networks and the implementation of Free Software stacks security research in thearea of GSM has become possible. For security research focused on GSM on a lowerlevel this is a major breakthrough. In parts the security of GSM relies and was built

7 specified in 3GPP TS 04.05

18


on the principle of security by obscurity and the fact that very few people knew aboutGSM details from a practical point of view.

OpenBSC is a Free Software implementation of the A-bis protocol and implementsa minimal version of the BSC, Mobile Switching Center (MSC), Home Location Reg-ister (HLR), Authentication Center (AuC) and Short Message Service Center (SMSC)components of a GSM network. It currently supports the BS11, the nanoBTS and isable to be used for 2G8, voice calls and SMS. Using this software we are able to runour own GSM network to conduct security studies. In combination with the fuzz-basedapproach for SMS security analysis, this perfectly fits our needs as we will see.

8 original GSM standard in the second generation

19

4 Vulnerability Analysis

We address the difficulties of vulnerability analysis by building our own GSM networkusing equipment that can be bought on the public market. We use the network not onlyfor sending fuzzed SMS payload, but also to build a monitoring system. A fuzz-basedapproach is only useful if there is a sophisticated monitoring system that allows findingproblematic payloads. While manual monitoring of the fuzzed phone is possible, it isslow and error prone. Therefore we designed our own monitoring system. Throughoutthis chapter we will describe the setup used in our GSM network as well as the targetselection, requirements to our setup, and details about SMS encodings. So far, we havefound numerous vulnerabilities in feature phones sold by the six market leading mobilephone manufacturers.

4.1 Introduction & Requirements

As previously outlined, vulnerability analysis has been conducted using a fuzz-basedapproach, utilizing the GSM network infrastructure. We replace the sending phone byinjecting messages directly into the network. This induces several requirements in orderto be useful and successful. Since we want to send large amounts of SMS messages, wedecided to build our own GSM network rather than sending SMS messages over a realnetwork. On the one hand this has the advantage of not costing any money and onthe other hand we do not risk to interfere with any telephone company’s network. Themost noticeable advantage however is that proper monitoring in a real operator networkwould be more difficult or not possible. Using our own network further guarantees usto create reproducible results since we control the entire system and are not left withguessing in the case something does not work as expected. In addition, the delivery ofSMS messages is much faster on our small network compared to a production setup ofa mobile operator. Utilizing this setup, we are able to send SMS messages to a mobilephone. OpenBSC allows us to either send a text message from its telnet interface to asubscriber of our choice or it processes an SMS message that it received Over-the-Air instore-and-forward fashion. As we later see the telnet interface is not feasible for fuzzingsince we need the ability to closely control all parameters in the encoded SMS format aswell as a way to inject binary payloads. Using a mobile phone to inject SMS messagesinto the network is not an option as this would be very slow as we will show later aswell.

21


Instead we built a software framework based on a modified version of OpenBSC thatallows us:

• Injection of pre-encoded SMS into the phone network

• Extensive logging of fuzzing related feedback from the phone

• Logging of non-feedback events, i.e., a crash resulting in losing connection to thenetwork

• Automatic detection of SMS that caused a certain event

• Processing malformed SMS with OpenBSC

• Smart fuzzing of various SMS features

• Ability to fuzz multiple phones at once

• Sending SMS at higher rates than on a real network

4.2 Target Selection

Mobile phones are produced by many different manufacturers that all have their ownOS. Therefore, targeting a single one of them will not result in global effect. Since wecan not simply target all mobile phone platforms, we have to select the few ones thathave enough market share to be of global relevance.

To determine the major mobile phone manufacturers we analyzed various marketreports: World wide [Aho10a] and European [IDC10] market share. Market shares inthe United States [Com10b] and in Germany [Com10a]. The essence of these marketreports is shown in Table 4.1. Table 4.1(a) shows Germany and Table 4.1(b) showsthe popularity for the United States. It is interesting that those tables are almost theopposite of each other. Table 4.1(c) shows popularity in Europe and Table 4.1(d) showsthe world wide popularity.

Through this analysis we got a clear picture about the top manufacturers. Theseare Nokia, Samsung, LG, Sony Ericsson, and Motorola. We further chose to addMicromax [Mica] to the list of interesting mobile phone manufacturers because we read[Kut10] that they are the third most popular brand of mobile phones in India.

4.3 SMS Encoding

SMS [3rd04c] messages exist in two formats depending on being Mobile Originated

(MO) or Mobile Terminated (MT). This is mapped to the two formats SMS_SUBMIT

(MO) and SMS_DELIVER (MT). Delivery report SMS messages also have their own encod-ing, but are based on these two.

In the previous research [MM09] on SMS fuzzing the authors injected messagesdirectly on the phone. Thus the messages were in SMS_DELIVER format. In a typical

22

4.3 SMS Encoding

GSM network, shown in Figure 3.1, an SMS message that is sent from a mobile deviceis transferred Over-the-Air to the BTS of an operator in SMS_SUBMIT format. Westrip the sending mobile phone from the scenario by directly injecting messages intoOpenBSC. Therefore our messages are SMS_SUBMIT encoded. During the final trans-mission to the destination the SMS will get converted to SMS_DELIVER, this is takencare of by OpenBSC.

As explained in Section 3.4.1 the operating system is usually sending SMS messagesvia an AT-command interface. There are two ways of passing a message to the GSMmodem. Messages can usually be submitted in text mode (not all phones support this)or Protocol Data Unit (PDU) mode. A submission for a message in text mode lookslike:

at+cmgf=1

OK

at+cmgs="+491234567890"

> this is an sms in text mode

+CMGS: 248

OK

The first AT-command sets the mode to text mode, the second command includes thedestination number and the text to be sent. This can be used to send simple textmessages. The PDU AT interface works and looks similar with the difference that themessage is not submitted in text form.

4.3.1 SMS PDU mode/SMS_SUBMIT

The PDU mode is a hexadecimal encoded form of the message and is more flexible asit can also be used to send binary payload. Messages in PDU mode can contain moreinformation than text mode PDUs.

Table 4.2 shows the SMS_SUBMIT format as specified in [3GP98b].TP-Message-Type-Indicator (TP-MTI), when set properly (0x1), is used to indi-cate that the message is an SMS_SUBMIT message. For vulnerability analysis thisfield is not interesting. Each message has a reference identifier represented byTP-Message-Reference (TP-MR). This field is usually just incremented after eachsent message and used to map errors reported back from the network to a specificmessage. In our fuzzing we set this to zero so the receiving phone can set the referencenumber itself. If TP-Reject-Duplicates (TP-RD) is not set, a phone will accept SMSmessages even if a message on the phone exists with the same reference ID (TP-MR).

TP-Validity-Period-Format (TP-VPF) defines if the message carries informationabout its validity period and in which format it is. If set, TP-Validity-Period

(TP-VP, which is optional) specifies when the message should expire. Messages notdelivered to this point can be discarded by the SMSC. We do not think this field isof relevance as real operator networks probably enforce their own policies on messagevalidity periods. This field is not interesting for fuzzing and will be set to zero in all

23


test cases. TP-Status-Report-Request (TP-SRR) is used by the phone to be able togive the mobile phone user a visual feedback that the message has reached the recipient.TP-User-Data-Header-Indicator (TP-UDHI) indicates additional SMS headers (seeSection 4.2). TP-Reply-Path (TP-RP) indicates that a reply path exists. This shouldcause a destination phone to send an answer message via the same SMSC throughwhich the original message arrived. We will as well ignore this field in our setup.TP-Destination-Address (TP-DA) starts with a byte indicating the address formatand is followed by the MSISDN of the recipient.

Only the fields TP-Protocol-Identifier, TP-Data-Coding-Scheme, TP-User-Data,and TP-User-Data-Length are interesting for fuzzing. The remaining fields justdescribe how the SMS message should be delivered or how SMSCs and mobile phonesshould generally handle them. TP-UDL would score as a prime target for vulnerabilityanalysis, but in practice it does not. From our experience GSM modems refuse to sendmessages with TP-UDL values that do not fit the actual payload length and it is likelythat operators fail to properly process such messages as well.

TP-Protocol-Identifier (TP-PID) is used to describe the type of the messagingservice being used. This refers to a higher layer protocol or inter-working being used.Examples for this are telefax, National Paging System, Internet Electronic Mail, areserved value range and lots of others. While this is included in the specifications, webelieve that these inter-workings are mostly legacy support and not in use these days.This makes it an interesting target to study unusual behaviour.

TP-Data-Coding-Scheme (TP-DCS) as described in [3GP98a], is used to indicate acertain message class and which alphabet is used to encode TP-User-Data (TP-UD),whether the payload is compressed and to indicate if new messages are waiting forthe customer (used in certain countries to indicate waiting voice mails for example).Message class 1 is usually the default for normal text messages and indicates that theSMS should be stored on the mobile phone while class 2 message is used to signal thatthe messages should be stored on the SIM card. 2 bits in this field are used to encodethe GSM alphabet [3GP98a] that was used to encode the TP-UD payload. This canbe either the default 7 bit, 8 bit or 16 bit alphabet and a reserved value. Togetherwith the TP-UD fields, TP-PID and TP-DCS are our main targets for fuzzing the basicSMS_SUBMIT structure. The receiving mobile phone then reassembles the messagebased on this information.

There are no conversion problems we need to take into account that may be caused dueto the conversion from SMS_SUBMIT to SMS_DELIVER. Both formats are similarand no field that is subject to our fuzzing is lost. The conversion is needed though.SMS_SUBMIT only contains the destination number and since SMS works in store-and-forward fashion, TP-Destination-Address is replaced with the sender number onthe final transmission to the destination.

This is also the reason why we did not directly inject the messages in SMS_DELIVERformat. This format does not include the destination number anymore but instead relies

24

4.3 SMS Encoding

010005912143F0000000be8329bfd06dddf723619

TP-{MTI,RD,VPF,SRR,UDHI,RP}TP-MRTP-DATP-PIDTP-DCSTP-VPTP-UDLTP-UD

Figure 4.1: Simple SMS message encoding “hello world”

on an existing channel to the phone (after the phone has been paged). The authors of[MM09] were able to do this because they were injecting the messages directly on thephone, no transmission from the network was required.

An example of a simple SMS to 12345 and the text hello world is visible in Figure 4.1.This is a hex encoded text message in PDU mode. It comprises most of the previouslydiscussed fields and includes no special encodings. This is an ordinary text message.Most noticeable is the encoding of the destination number (TP-DA). The first byte issimply a length encoding (5 bytes). The second byte notes the number format. 0x91is the type code used by the international format1 for phone numbers. The succeedingbytes are the mobile phone number (12345) in swapped-nibble notation and 0xF isappended as a padding. TP-DCS is zero, indicating the message (TP-UD payload) is7-bit ASCII encoded.

4.3.2 SMS UDH

However these fields are not enough to cover the complete range of possible SMSfeatures. If the TP-User-Data-Header-Indicator (UDHI) bit is set (which is part ofthe first byte of the SMS_SUBMIT PDU), it indicates that TP-User-Data includes aUser-Data-Header (UDH).

The optional UDH is used to provide additional control information just like headersin IP packets. It has to be included in the available 140 bytes message payload. If theactual message content is 7 bit encoded, padding bits are added between the UDH andthe message. UDHs add a huge complexity layer on top of traditional SMS encoding.Encodings for every single UDH differ and multiple UDH chunks can be chained.

1 http://en.wikipedia.org/wiki/Telephone_numbering_plan Page Version ID: 403204650

25

http://en.wikipedia.org/wiki/Telephone_numbering_plan


Figure 4.2: SMS User-Data-Header structure (picture taken from 3GPP TS 23.040)

Figure 4.2 shows the general structure of a UDH. UDHL specifies the length of thecomplete UDH in bytes and is followed by one or multiple headers. IEI are so calledInformation Element Identifiers [3rd04b], a one byte identifier specifying the type ofheader that maps to a certain feature. IEDL specifies the length of the specific headerelement and IED is the actual header data.

A selection of features that are available via the use of UDH are:

• Concatenated short messages

• SMS port addressing

• Text Formatting (EMS)

• Sound

• Animation

• RFC 822 E-Mail Header

• (U)SIM Toolkit Security Headers

A complete listing can be found in [3rd04b].The number of features and UDH combinations is huge. Therefore, based on our

experience, the security analysis of UDH in this thesis only selects the most popularsupported features.

26

4.4 OpenBSC Modifications and Additions


While OpenBSC is very useful to drive a GSM network, its defaults did not quite fit ourrequirements outlined in Section 4.1. We needed to implement changes for both sendingmalformed messages and monitoring phone behaviour during our testing.

4.4.1 Sending SMS Messages

Besides the ability to process SMS messages received Over-the-Air, OpenBSC featuresa telnet interface to send SMS messages. This allows sending basic text messages tospecific recipients. The downside of it however is that this only allows us to set TP-Userdata and TP-Destination. TP-DCS and TP-PID are implicitly set to zero forminga standard text message in 7 bit encoding. If the destination subscriber is attached tothe network, the SMS will be sent to it. If not it will simply be discarded.

If a mobile phone sends an SMS message to another phone, the process works slightlydifferently. The received message will be parsed by OpenBSC and fills an internal SMSdata structure that is dumped into an SQLite database afterwards. This database andespecially its sms table is an important part of the SMSC implementation of OpenBSC.The message will be sent to the destination subscriber on reassociation with the networkor an sms send pending command is issued manually via the telnet interface.

This section will discuss the changes made to OpenBSC in order to be able to sendpre-encoded SMS messages. Other modifications that are related to monitoring andevaluation of test cases will be presented in Section 4.4.2.

4.4.1.1 Injection of Pre-encoded SMS

In order to do proper fuzzing of the previously discussed SMS field values and theability to send binary messages, we required a combination of both SMS submissionpossibilities OpenBSC already provides (telnet interface for text messaging and pro-cessing messages from a phone). Modifying the existing text message interface tobe capable of handling binary encoded SMS messages would have been no option.Messages submitted over this interface are instantly transmitted to the subscriber if heis attached to the network. This means opening a channel, initiating a data connection,sending the message and tearing down the connection. This works, but is very slow(about seven seconds per message). This is also the reason why we did not want to usea mobile phone to send our fuzzed-messages in the first place.

Instead we added a new telnet interface command to OpenBSC that allows us tosubmit SMS messages directly in SMS_SUBMIT format. This way we also fill theinternal SMS structure and store the message in the database from which it is laterconverted to SMS_DELIVER format. By doing so we replace the sending mobile phoneand are able to inject huge amounts of SMS messages into the network via the telnetinterface. Thus we do not require modifications on the phones. The syntax of thenewly introduced command is sms submit PDUINHEX. This allows us to injectthousands of pre-generated SMS messages using a simple python script that connects

27


to OpenBSC’s telnet interface and submits the messages through our newly introducedcommand. On sending the messages this ideally only opens the channel once, sends outall SMS messages to the recipient and then closes the connection. This greatly improvesthe speed at which we can fuzz since the actual message transfer only takes about 2-3seconds. OpenBSC by default is not storing the complete received PDU, but only theparsed values needed to perform the SMS_DELIVER conversion in the database. Weadded an additional column to store the complete PDU. As we will see later this willbe necessary to reproduce monitored problems.

Example output of an SMS submission in PDU mode (telnet interface and OpenBSCresponse):

pagefault> sms submit 010005912143F500000BE8329BFD06DDDF723619

layer3 pdu: 010005912143F500000BE8329BFD06DDDF723619

parsed pdu: 1 0 5912143f5 0 0 be8329bfd 6dddf723619

RX SMS: Sender: 262073978403216, MTI: 0x01, VPF: 0x00, MR: 0x00,

PID: 0x00, DCS: 0x00, DA: 12345, UserDataLength: 0x0b,

UserData: "hello world"

4.4.1.2 Other Small/Useful Additions

Some additional small, but useful changes have been added on the sender side. Weintroduced an additional telnet command to not only send all messages to attachedsubscribers, but to be able to selectively send messages to individual subscribers. Thesyntax for this new command is subscriber (extension|imsi|tmsi|id) dest smssend pending. Unfortunately, the use of the existing command to send all messages toall subscribers was impossible as it will confuse internal OpenBSC states at this pointin time, when starting a sending process while messages are already being delivered toa subscriber. For debugging purposes it is also better to be able to only target specificsubscribers.

As we replace the sending mobile phone, the SMS_DELIVER conversion lacks anoriginating address. To solve this a new configuration file variable and telnet commandhas been added that allows to set a static originator mobile phone number for messagessubmitted with our injection command. The syntax for this is sms sender number.

OpenBSC by default handles 7 bit, 8 bit and 16 bit TP-DCS values. It has to takethis value into account as it determines the number of characters that need to be copiedas TP-UD payload when sending the message. Our fuzzing also targets invalid TP-DCSencodings that will not be handled by OpenBSC (e.g. compressed TP-UD payload).Therefore we made the design decision to implicitly assume that messages with unknownencodings are 8 bit encoded.

4.4.2 Monitoring for Phone Behaviour

In a fuzz-based study it is necessary to introduce monitoring techniques that catchunusual behaviour. Ideally this should not only notice such behaviour, but also deter-

28


Figure 4.3: Mobile terminated SMS

mine the cause for it. In our case the specific SMS message that caused it. We wereinterested in feedback directly generated from the fuzzed phone as well as non-feedbackevents caused in the GSM network that might be related to security issues. Additionalmodifications have been made to OpenBSC and a set of monitoring scripts and usefulhelpers have been developed.

4.4.2.1 Feedback From the Phone

The GSM standard defines [3GP98d] a ACK/NACK based mechanism to report feed-back from the phone back to the network. This is used for example so that the phonecan report full SMS memory to the network so it can stop delivering SMS messagesuntil the phone is able to receive messages again. OpenBSC itself already has an errorhandler which takes care of errors reported from the phone. We modified this to fitour fuzzing case. The default error handler does not differ between errors and causesthe SMS sending process to stop in case of an error. The only difference is a Memory

Exceeded error which causes OpenBSC to dispatch a signal handler to wait for anSMMA signal (released short message memory) indicating that there is space again.

The mobile phone as well as the MSC is usually divided into separated layers fortransferring and processing a message. As visible in Figure 4.3 they consist of a Short

Message Transport Layer (SM-TL), Short Message Relay Layer (SM-RL) and theConnection Management Sublayer (CM-Sub). The SM-TL [3GP98b] receives and

29


relays messages that it receives from the application layer in TPDU form (TransportProtocol Data Unit), this is the original encoding form previously referred to as PDU.The message is passed to the SM-RL to transport the TPDU to the mobile station.At this point the TPDU is encapsulated as an RPDU. As soon as a connection isestablished between the mobile station and the network the, RPDU is transferredOver-the-Air encapsulated in a CP-DATA unit that is part of Short Message ControlProtocol (SM-CP). Both sides communicate via their CM-Subs with each other. TheCM-Sub on the phone side will unpack the CPDU and forward the encapsulated TPDUto the Transport Layer using an RP-DATA unit. At this point the mobile phone stackhas already done sanity checks on the content of the SMS and parsed it. The resultingreply, passed to CM-Sub, will include an acknowledgement of the SMS message and itwill then be passed to the higher layers. From there it will end up in the user interfaceor an error message is encapsulated and sent back to the network. For our monitoringwe need to log these replies including the causing message carefully to observe thefeedback of the phone. This logging process is completely separate from OpenBSCsdebug output, is logged to a special file and has been added specifically to do loggingfor our fuzz-testing.

From the wide variety of error messages a phone can reply to a received SMS message,defined in [3GP98d], we observed during our fuzzing experiments that all of the testedphones either reply with a Protocol Error or Invalid Mandatory Information mes-sage in the case of a malformed message. These two responses besides the memory errorhave been the only errors that we observed in practice. We added code to flag such anSMS message as invalid in the database and continue delivering the next SMS that hasnot been flagged as invalid. OpenBSC would otherwise continue trying to retransmitthe malformed SMS message and thus block further delivery for the specific recipient.Memory Exceeded feedback was handled manually. Most of the tested phones have alarge enough internal memory that it was feasible to delete all messages at once everynow and then manually. If this is not the case, one could use tools like Gammu [Či10]to automatically delete messages from the phone. This would be an enhancement ofour log evaluation script in Section 4.4.3. Example log output (includes sender/receiverimsi, receiver number (EXT) and the actual PDU):

2010-10-29 16:03:32 - REASON: (MT) Memory Exceeded,

ID: 596485, SND: 262073978403216, RCV: 262021050154830, EXT: 1338, PDU:

41000491318300f188050003a6fff03b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b

3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b



3b3b3b3b3b

4.4.2.2 Network Events

SMS messages are usually sent over a Slow Dedicated Control Channel (SDCCH) ora Slow Associated Control Channel (SACCH). The details of such a channel are not

30


important for the scope of this thesis. However, the use of such a logical channel isan important measurement to detect mobile phone crashes. Such a channel will beestablished between the BTS and the phone on the start of an SMS delivery by pagingthe phone on a broadcast channel (BCCH). As we mentioned earlier, we only open thechannel once and send a batch of messages using this one channel. So if this channel islost during our sending process, it is very likely that something went wrong. The channelrelated signaling between the BSC and the BTS happens over the A-bis interface overhighly standardized protocols. We added modifications to the “A-bis Radio SignallingLink” code of OpenBSC that allows us to check if a channel tear down happens in ausual error condition, log when this happens and which phone was previously assignedto this channel. At this layer we lack the context of the offending SMS that cause thiserror. As we will see in Section 4.4.3, we use a different approach to find it for severalreasons. Example log output of a crashed phone:

2010-11-03 15:04:02 - 1338 (262024040584040)

ME released lchan unexpectedly (abis_rsl_rf_rel_err, state: 4)

Channel release states different from that are also logged for completeness, but notprocessed by our log evaluation script described in Section 4.4.3. An example shouldbe:

2010-11-03 15:49:11 - channel release in state: 3,

not logged as error condition, no subscriber information available

anymore

4.4.2.3 Monitoring via J2ME

Almost every modern feature phone supports J2ME [SUN] and this is the only wayfor us to do measurements on the phone since they do not run native applications.Applications running on the mobile phone can register a handler in an SMS registrysimilar to binding an application to a TCP/UDP port. An simple example in J2ME:

try {

TextMessage tmsg;

// bind SMS port

serverConn = (MessageConnection)Connector.open("sms://:5000");

// Register the listener for inbound messages.

serverConn.setMessageListener(this);

// send test message to 7331

tmsg = (TextMessage)serverConn.newMessage(MessageConnection.TEXT_MESSAGE);

tmsg.setAddress("sms://7331");

tmsg.setPayloadText("testfoo");

serverConn.send(tmsg);

} catch (IOException ioExc) {

System.out.println("Server connection could not be obtained");

ioExc.printStackTrace();

}

When sending a message, this is indicated by the previously described UDH [3GP98b]which can encode that a certain SMS message is addressed to a specific SMS-port.

31


Figure 4.4: Logical view of our setup.

When the phone receives a message, this header field will be parsed and the messageis forwarded to the application registered for this port. Our J2ME application that isinstalled to the fuzzed phone registers to a specific port and receives SMS messageson it. For each chunk of fuzzed SMS messages we can inject a valid message that isaddressed to this port. The application then replies with an SMS message back to aspecial number that is not assigned to a phone. Figure 4.4 shows this as the J2MEecho server. The message is just saved to the SMS database. This allows us to easilylookup the count of SMS messages for this special number in the database and checkif it increased or not. If not, it is very likely that some odd behavior was triggered.This kind of additional monitoring is useful to identify bugs that block the phone fromprocessing received messages as happened in the Curse of Silence case [Eng08].

4.4.3 Log Evaluation

While we lack possibilities to conduct traditional debugging methods on the device itselfwe can use the open part - OpenBSC - to do some debugging on the other end of thepoint-to-point connection.

The difference to traditional debugging techniques is that we are limited towards thetechnical reason and impact of such an error condition in the meaning that we are notable to peak at register values and other software related details. However it is enoughto be able to reliably detect and reproduce the error. Using this method it also possibleto find code execution flaws. However exploiting them and getting to know the detailsabout the specific behavior requires the effort of reverse engineering the firmware for aspecific model. We try to avoid such a large scale test of phones, but these bugs are agood base for further investigations such as reverse engineering of firmware.

When doing fuzz-based testing, it is important to log and evaluate possible crashes.This is especially important as we send a large number of messages. We need to be able

32


to manually reproduce test cases that possibly caused unusual behaviour in a timelymanner. To do so we have written a script that processes the produced phone feedbacklog entries. It evaluates it, takes actions in order to determine which SMS messagecaused a problem and saves results to a crash log file. This crash log file can then bemanually evaluated after a test-run.

When delivering an SMS message to a recipient under the assumption that it isassociated with the cell, in practice three things can happen. Either the messageis accepted and acknowledged, it is rejected with a reason indicating the error, oran unexpected error occurs. Such an unexpected error can be that the phone justdisconnected because it crashed or because of other reasons the received message isnever acknowledged. Both error conditions are logged with the previously discussedOpenBSC enhancements. In the latter case, OpenBSC stores the SMS message in thedatabase, increases a delivery attempt counter and tries to retransmit the SMS messagewhen the phone associates with the cell again. For our fuzzing results this meansthat this method detects bugs in which the SMS message either results in a phonecrash after it accepted the message or already during receiving it. In the latter case itwill never be acknowledged and OpenBSC continuously tries to deliver the SMS message.

Detecting the SMS message that caused such an error condition is then rather easy.Our script checks the error condition and if it is because of the loss of a channel it firstlooks up the database to find SMS messages that have a delivery count that is greater orequal to one and the message is not marked as sent (meaning it was not acknowledged).In this case we can say with a high probability that the found SMS message causedthe problem. If there is no message, the script checks which messages have been sentin a certain time interval around the occurrence of the log entry. During our testingwe decided that a one minute time interval works well enough to have a small amountof prospective SMS messages that could have caused a problem. Figure 4.4 shows thelogical view of our monitoring setup.

Example for log evaluation output of a normal crash case:

phone (1337) went offline at 2010-10-15 10:58:56, checking last sms...

previous sms:

2010-10-15 10:57:58 41000491317300f488050003e1fff12f1535030c141a16173f

0205342d341c0c241d0630202e17092026272a14030c35162b30362c383f352702390c

02362e393a0c11031f3a3f1f3715071d27223a28150d262e350e3a12300c1924030f2e

2c3f040f16253c2515322f260e250218133f3229211d3a0730121009211e1e3d352e15

281b3111102a130e2d2d0d252

03d03

2010-10-15 10:58:01

41000491317300f488050003e1fff2f2729044d27caa52dacb585677aa0c346b3d12a0

ad3664ff4a9629c750bc4b6b95cbb7aa3284dd57e53dbf93dbc76ff907e80bd764eab6

77039822ac9bca74f1159237e8e8523e95b5f74b9b282b9e37cfcca09302bb425839d7

b8116c7b00268babe19735f9cbdba19b1e11ee10401fa439497a103dde60c6cf84a09d

15a2788554

33


Example for log evaluation output of a message that causes a crash, but is neveracknowledged:

phone (1331) went offline at 2010-10-29 14:28:37, checking last sms...

previous sms:

the error was very likely caused by the following sms (1, next sms):

41000491311300f1880500034affdb4040404040404040404040404040404040404040

4040404040404040404040404040404040404040404040404040404040404040404040

4040404040404040404040404040404040404040404040404040404040404040404040

4040404040404040404040404040404040404040404040404040404040404040404040

4040404040

Given a best case of 2 seconds per message delivery and 1 minute backlog this yieldsto a maximum of thirty messages that need to be evaluated manually per phone crash.The suspected test cases can simply be re-injected into the network.

4.4.4 Other Possibilities

Other possibilities that might be interesting for monitoring purposes are USB and Blue-tooth. Though not every feature phone supports them. By hooking up a phone viaits USB cable we can monitor for USB device disconnects. The same can be achievedby using Bluetooth. It is possible to use a virtual serial connection and connect to theRFCOMM channel for the phone’s dial-up service. The script can then block by tryingto receive data on this connection. On a phone crash or hang, the connection will beinterrupted and thus signal that something went wrong.

4.4.5 Crash Analysis/Decoder

Besides resending test cases to phones for reproduction it is important to be able todetermine the possible cause of a problem. For analysing SMS PDUs PDUSpy [Hü]exists. This tool allows encoding and decoding of SMS payloads. Unfortunately itis only available for Windows so we implemented a basic decoder for SMS_SUBMITmessages that works under Linux. This way it was often possible to quickly identifycrucial parts of the payload and to look for possibly problematic parts of the encodeddata.

34

4.5 Fuzzing Test-cases

Example output of SMS_SUBMIT decoder output:

$ ./decode_submit 41000491888800F5840B050423F0040B0003FD040241414141...

input pdu len: 141

TP-RP: 00

TP-UDHI: 01

TP-SRR: 00

TP-VPF: 00

TP-RD: 00

TP-MTI: 01

MSISDN_L: 04

MSISDN_T: 91

MSISDN: 8888

TP-PID: 00

TP-DCS: f5

TP-UDL: 84

UDHL: 0b

IEL: 04, IET: 05, IED: 23f0040b

IEL: 03, IET: 00, IED: fd0402

decoding 78 hex bytes user data

414141414141414141414141414141414141414141414141...


To build a toolchain of SMS fuzzers we used Mulliner’s python SMS library [Mul],enhanced it and produced a number of fuzzers for interesting SMS features. Altogetherour fuzzers produced 120995 test cases per phone (because of time constraints not allwere sent in case we already found bugs). Some of these features can also be combined.For example most of the features can either consist of a single SMS message or be partof a multipart sequence by adding the corresponding multipart UDH.

The following will list and explain the test cases that we produced and evaluated.

4.5.1 TP-Data-Coding-Scheme/TP-Protocol-Identifier

The combination of the TP-DCS and TP-PID fields yields to how the message is dis-played and treated on the phone. Both of these fields are one byte values and also coverseveral rather unpopular features like Videotex inter-workings and Electronic Mail Mes-sage Waiting indication. Additionally, TP-PID features 7 reserved values (01110..01111and 10011..10111). So this makes an interesting target to look for unusual behaviourand code paths that are often unused by normal SMS traffic. The fuzzers produced testcases ({tp − pid, tp − pid_all, tp − pid − dcs}.py) that consist of:

35


• random combinations of TP-PID/TP-DCS and 130 bytes semi-random2 bytesTP-UD payload.

• a sequence of messages covering all TP-PID values and 130 bytes random TP-UDpayload with standard 7 bit encoding

• random TP-PID values, 130 bytes random TP-UD payload and a random choiceof 4 TP-DCS values commonly used in regular SMS (0x00, 0x04, 0xF1, 0xF5)3

4.5.2 User-Data-Header

Like already explained before, UDHs are used to add additional control information toSMS payload. It is used for a wide variety of features that might reside in often unusedcode paths. The UDH fuzzer (udh.py) creates a random number of header chunks(random choice between 0 and 0xF to be precise). The UDH chunks itself consist ofa random IET (0-0xFF) and adds (random choice) between 0x2 and 0x8 random IEDbytes. Ten additional random bytes are added as TP-UD. An additional fuzzer (udh-header.py) randomizes UDH and IEL length fields.

Another UDH fuzzer (udh-port.py) is testing explicitly for UDH port addressing.Applications can bind to 8 bit and 16 bit ports. Received messages with UDH headersincluding this addressing scheme are forwarded to the application. This is usually usedfor WAP Push and other features. We were looking for unusual behaviour of applicationsbinding to such ports and additionally have some kind of UDH port scanner. Scanningthe complete range of ports and creating test cases with random TP-UD would takevery long. Instead we collected a list of ports from the Nokia Smart Messaging Specifi-cation [Nok00], WAP Forum [WAP] and some Google search. Common ports seem tobe: 2948, 2949, 9204, 9205, 9206, 9207, 2805, 2923, 9200, 9201, 9202, 9203, 9204, 9205,9206, 9207, 5505, 5006, 5507, 5508, 5514, 5512, 5501, 5502, 5503, 5504, 5505, 5506, 5507,5508, 5509, 5510, 5511, 5512, 5513, 5514, 5580, 5601, 5603, 8500, 8501, 8502, 5499, 80,226 and 228.

4.5.3 Multipart

SMS originally was designed to send up to 140 characters of user data. Due to 7-bitencoding it is possible to send up to 160 characters. However various SMS features relyon the possibility to send more data, e.g., binary encoded data. Multipart SMS messagesallow this by splitting payload across a number of SMS messages. This is achieved byusing a multipart UDH chunk (IEI: 0x00, IEDL: 0x03). This UDH chunk comprises ofthree one byte values. The first byte encodes a reference number that should be randomand the same in all message parts that belong to the same multipart sequence. Based onthis value the phone is later able to reassemble the message. The second byte indicatesthe number of parts in the sequence and the last byte specifies the current chunk ID.

2 Produced by getSMSFuzzData() which does not create complete random values, but sequences ofcharacters known to be treated in a special way on the phone. This includes URLs, numbers, Emailaddresses and others.

3 uncompressed default alphabet in 7 bit encoding, uncompressed 8 bit encoding, default alphabet in7 bit encoding Class 1, 8 bit Class 1

36


Figure 4.5: Concatenated Message consisting of 2 messages

Figure 4.5 shows an example. The multipart fuzzer (multipart.py) creates messagesconsisting of:

• 2, 10, 50, 140 and 255 parts consisting of random and semi-random TP-UD payload

• random multipart sequences with individual chunks missing

• random payload and random TP-DCS

• sequences containing chunks with random current part indices

• doubled parts

• parts in shuffled order

• sequences with random bytes flipped

By fuzzing these values we were mainly looking for abnormal behavior related tocombinations of the current chunk ID and the number of chunks in a sequence. Forexample, chunk IDs higher than the number of total chunks to trigger bugs in theroutines that reassemble the parts to a bigger message on the phone.

4.5.4 Simple Text Messages

Implementations of decoders for simple 7 bit encoded SMS often work with a GSMalphabet represented for example by an array. The decoder first needs to unpack the7 bit encoded values and convert them to bytes. After this step it can lookup thecharacter values in the GSM alphabet table. The fuzzer (simple_text.py) mixed valid 7bit sequences with invalid encodings that would result in no corresponding array index.This could trigger all kinds of implementation bugs, but most noteworthy, out of boundsaccess resulting in null pointer exceptions and the like.

37


Figure 4.6: Flash SMS encoding “Hello World”

4.5.5 Flash SMS

Flash SMS are constructed by setting the data coding scheme value in the encoded SMSto specific values. Class 0 messages [3GP98a] are usually treated as Flash messages byphones. Flash SMS are directly displayed on the phone without any user interactionand the user can optionally save the message to the phone memory (not on all phones).This can be used by providers for example to display the left balance of the SIM cardafter a call or very annoying Spam.

Our observations made it clear that often the code that renders the Flash SMS mes-sage on the display is not the same as the one that displays a normal message fromthe menu. Therefore, it can be prone to the same implementation flaws as simpletext messages. Additionally to this, Flash SMS can consist of multipart chunks andthere are several combinations of TP-Protocol-Identifier and TP-Data-Coding-Schemethat cause the phone to display the SMS as Flash message. The Flash SMS fuzzers({flash_sms, f lash_sms_multipart}.py) aim to cover a combination of all of the pre-viously mentioned possible implementation weaknesses combined with Class 0 encoding.Figure 4.6 shows an example of a Flash SMS message.

4.5.6 VCard

VCards [FD98] are used as electronic business cards and often sent over Bluetoothor SMS to other phones. They provide an easy way to send contact informationof other persons to other subscribers. The general syntax of a VCard object isembedded inside of BEGIN:VCARD/END:VCARD markers and comprises a number ofT Y PE[; PARAMET ER] : V ALUE[; V ALUE] pairs. Each line ends with a CLRF.Common TYPEs are N (object name), FN (contact name), TEL (telephone number asso-ciated with object), EMAIL (email address associated with object) and ADR (addressinformation). A typical 2.1 VCard looks like:

BEGIN:VCARD

VERSION:2.1

N:Mustermann;Max

ADR;HOME:;;Musterstraße 1;Musterstadt;;12345;Deutschland

TEL;HOME;VOICE:+49 1234 56788

TEL;CELL:+49 1234 56789

TEL;HOME;FAX:+49 1234 12345

END:VCARD

38


Figure 4.7: EMS encoding “Hello” in bright yellow font on dark red background

For SMS this data has to be 8 bit encoded and is usually sent in a multipart sequence.For the scope of this thesis it does not make sense to build a full-featured VCardfuzzer that fuzzes the syntax of this format. Also because it would involve immenseamount of SMS messages. Of course this is only a time constraint. Instead the writtenfuzzers ({vcard, vcard_multipart, vcard_samsung}.py) aim to find typical implemen-tation flaws like buffer overflows by combining common VCard fields with a variablelength of random byte values. Additionally, not only VCards including the commonfields are created, but also test cases that contain all VCard fields and random lengthvalues. Another fuzzer has been written for the very similar VCalendar format.

4.5.7 Enhanced Messaging Service

The Enhanced Messaging Service (EMS) [3rd04b] was developed as a cross-vendorcollaboration to enhance SMS with rich text formatting and embedding of pictures,sound and animations. We decided to fuzz the text formatting feature which can beused via UDH. The length of such an IE is either 0x3 or 0x4 depending on if color isencoded as well. It is followed by a formatting start offset, a length byte, a formattingbyte and depending on the length of the IE a color byte. An example for this isvisible in Figure 4.7. The EMS text formatting fuzzer (ems-text-format.py) randomizes(0x0-0xFF values) the start offset, length value and formatting value bytes.

Unfortunately during our tests it became clear that none of the tested phones supportthis feature. The additional format information was just ignored. It is unclear howwidely supported it is.

39


Figure 4.8: MMS Indication - sender: barbaz, subject: foobar, http://google.com

4.5.8 MMS Notification

When a subscriber receives an MMS (Multimedia Messaging Service) message, theMMSC sends an MMS notification indication message [WAP02a] that contains the URLto the MMS content. This data is encoded using the Wireless Session Protocol [WAP02b](WSP). The phone then starts a GPRS connection to download the content. This MMSnotification is in fact a binary encoded WAP-push message sent via SMS. Such a noti-fication can contain additional variable length fields for subject, transaction ID andsender name. There are no length fields for most these values. Field values are precededby a one byte identifier. The value itself is either one byte, a variable length value witha preceding length byte or variable length values that are zero-terminated. An exampleMMS indication SMS is visible in Figure 4.8.

IET 0x5 identifies a 16 bit port addressing UDH header. 0x0B84 (2948) isused as the default destination port for WAP-push messages, 0x23F0 (9200) asthe source port. In this example another UDH chunk is added to indicate amultipart message with one part4. The example message starts with one byte(non variable length) transaction id (0x2E), followed by 0x6 indicating that thisis a Push message. The 0x3 byte specifies the WSP header length, 0xBE indi-cates the Content-Type being application/vnd.wap.mms-message, followed by0xAF84 setting X-WAP-Application-Id: x-wap-application:mms.ua. The lat-ter is an additional information element to further distinguish between applicationsthat handle data addressed to the WAP-push port. X-Mms-Message-Type (0x8C)is set to m-notification-ind (0x82). X-Mms-Expiry, X-Mms-Transaction-Id,

X-Mms-Content-Location and Subject are variable, zero terminated length fields.The From field can also be of variable length, but is preceded by a length byte (0x6)and an Address-present token (0x80). X-Mms-Message-Class (0x8A) is a classifierfor the message content. Typical values are Advertisement, Information, Personal(0x80). X-Mms-Expiry allows to set an expiry date in unix timestamp format. Theorder of those fields is not important. Except for the Message-Type, Transaction-ID,MMS-Version and Content-Type the order of the fields can be arbitrary.

4 This message would not need to be multipart, it is a side effect of the fuzzer which is designed to sendlarge MMS indication messages

40


MMS indication messages can also consist of multipart sequences. Therefore, ourfuzzing targets were the variable length field values included in the message seekingfor classic issues like buffer overflow vulnerabilities. The fuzzer (mms_indication.py) isgenerating a couple of hundred test cases per field while keeping the remaining fieldsalmost static.

4.5.9 WAP-push Service Indication

WAP-push Service Indication messages are similar to MMS indication (4.5.8). Theyallow WAP content to be directly pushed to the mobile phone. There are 2 types ofWAP-push messages, Service Indication (SI) and Service Load (SL). An SI mes-sage informs the subscriber about a WAP service being available at a linked locationincluded in the message. The subscriber can then open the link, defer it or delete the SIcompletely. Contrary to this SL instantly fetches the WAP content without notifyingthe user. As this is considered a security risk it is usually disabled per default on allphones and thus will not be a target for our fuzzing studies.WAP-push messages are encoded in a minimal, binary version of XML,WBXML [WAP01]. The WSP header is similar as for MMS indication (4.5.8) messages.The general structure of a WAP-push Service Indication message is:

<?xml version="1.0"?>

<!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN"

"http://www.wapforum.org/DTD/si.dtd">

<si>

<indication href="http://google.com" action="signal-medium" si-id="6532" >

This is a WAP-push SI message!

</indication>

</si>

The XML message is then converted to WBXML, embedded into the WAP-pushmessage and sent as binary message to the mobile phone. The action value only controlshow the message is signalled on the phone. This is not interesting for fuzzing. Insteadthe created fuzzer (wap_push.py) tries to find buffer overflow vulnerabilities in the hrefand indication field values. As message location a valid URL with random bytes isused (",<,> characters filtered for obvious reasons) and the message content consists ofrandom and semi-random (4.5.1) characters. To also find bugs in the WBXML payloadafter conversion from XML, the fuzzer additionally flips a random amount (0-10)5 ofbytes in the produced WBXML data. This fuzzer does as well make use of multipartmessages.

4.5.10 (U)SIM Data Download

(U6)Sim Data Download is an interface between the (U)SIM card, the mobile phoneand SMS. It is an interesting feature, as SMS messages using this mechanism are

5 The fuzzer has a command line parameter to configure this. While testing we came to the conclusionthat 0-10 is a good number that ensures messages are not completely destroyed and the majority oftest cases thus being useless

6 new SIM cards used for UMTS

41


directly passed to the (U)SIM card without any processing of the phone (originalSMS_DELIVER format). This can be used to issue configuration commands on theSIM card via SMS and is used by network operators as a method of administrativemanagement. TP-PID has to be set to 0x7F in order to mark the message as SIM Data

Download and to indicate that no inter-working is being used [3rd04b]. As specifiedin [3rd04b] TP-DCS has to be set to an 8 bit class 2 message, so either 0xF6 or 0x16.The entire TP-UD payload is then available for SIM download and will be interpretedby means of the SIM Application Toolkit (SAT) [3GP05, 3GP10, 3GP96]. SAT is notlimited to phone configuration by the operator, it is a standard allowing the SIM toinitiate various actions. Such actions are issued via Application Protocol Data Units(APDU) encoded in the SMS payload. To prevent misuse, such an SMS usually carriesadditional security information. Additionally, to the TP-PID and TP-DCS settings[3GP98a] requires a UDH to mark the messages as secure command packet. The IE forthis is 0x70 and the IEL 0x00.

As a result of the complexity of the actual command packet and the security measures,rebuilding more of the message structure is not feasible for the scope of this thesis.The fuzzer (sim-data-download.py) crafts a SIM Data Download message, but fills thecommand packet with random data.

42


Table 4.1: Mobile phone Manufacturer Market share

(a) Germany, November 2009

Manufacturer Market Share

Nokia 35.4%Sony Ericsson 22.0%Samsung 15.0%Motorola 8.6%Siemens 5.4%

(b) U.S.A., May 2010


Samsung 22.4%LG 21.5%Motorola 21.2%RIM 8.7%Nokia 8.1%

(c) Europe, June 2010


Nokia 32.8%Samsung 12.5%LG 4.1%Sony Ericsson 3.7%Apple 3.0%RIM 2.4%Others 3.0%

(d) World, for the year 2009


Nokia 38%Samsung 20%LG 10%Sony Ericsson 5%Motorola 5%ZTE 4.5%Kyocera 4%RIM 3.5%Sharp 2.6%Apple 2.2%Others 5%

43


Table 4.2: Format of the SMS_SUBMIT PDU.

Field Size

TP-Message-Type-Indicator 2 bitTP-Reject-Duplicates 1 bitTP-Validity-Period-Format 2 bitTP-Status-Report-Request 1 bitTP-User-Data-Header-Indicator 1 bitTP-Reply-Path 1 bitTP-Message-Reference integerTP-Destination-Address 2-12 byteTP-Protocol-Identifier 1 byteTP-Data-Coding-Scheme 1 byteTP-Validity-Period 1 byte/7 byteTP-User-Data-Length 1 byteTP-User-Data depends on DCS/UDL

44

5 Evaluation

In this chapter we will explain the found issues that could be evaluated using themonitoring measures that were introduced in Section 4.4.2.

After each fuzzing-test-run, we evaluated the log generated by the monitoring script.All of the bugs described later in this thesis were triggered by one or very few SMSmessages. Reproducing problems from log entries often could be done without anyproblems. However, fuzzing phones did not run as smooth as initially expected aswe stumbled across various forms of strange behavior. Problems we faced includednon-standard conforming message replies and all sorts of weird behavior. Some phoneswere not properly reporting memory exhaustion. Others did not notice free memoryuntil a reboot. Some did not display a received SMS message on the user interfacewhich made it hard to tell if the phone accepted a message or silently discarded it onthe phone. Almost every phone we fuzzed needed a hard reset at one point because itbecame simply unusable for unknown reasons, the mass of messages or a specific SMSneeded to be deleted from the SIM card using another phone. The biggest problemwith hard resets is that a lot of manufacturers do not seem to do what the name hardreset suggest, bring the phone into a fresh manufacturer state. From what we knowthis is done as a feature for customers in order to ensure no personal data is lost. Thebehavior also differed between phones of the same manufacturer. When testing a bugon the Samsung Corby, it was always enough to remove the offending SMS messagefrom the phones SIM card while the Samsung S5230 needed an additional hard reset.Things like this have been very time consuming during the fuzzing, but this is alsonoteworthy as it seems to be hard for phone customers to 100% get rid of personalinformation from the phone, e.g., when selling the phone.

In summary we stumbled across a lot of annoyances which are not important froma security point of view, but in our overall impression most of the feature phones wetested behaved rather fragile when handling SMS messages.

During our fuzz-testing we discovered quite a number of bugs that lead to securityvulnerabilities. The bugs mostly lead to phones crashing and rebooting and in the eventdisconnecting them from the mobile network, and thus interrupting established voicecalls and data connections. During the testing we even managed to brick a phone. Wedid not investigate the bricking in-depth because this would have gotten quite expensive.Further, some of the phones crash during the process of receiving the SMS message,and, therefore, fail to acknowledge the message thus causing re-transmission of the SMSmessage by the network.

Below we present bugs and unusual behaviour that we discovered during our testing.In most cases we fuzzed only one phone from each platform and later only verified the

45

5 Evaluation

bugs on other phones we had access to. This seems natural since manufacturers mostlybase their entire product line on a single software platform. Only customizing optionssuch as the user interface depending on the hardware of a specific device. Please notethat we do not note firmware versions on purpose as they had practically no impact onour testing. There has not been a single case in which multiple versions for the samedevice existed with one not having a bug while others did.

5.1 Feature Phone Issues

The following is a listing of security problems that we discovered for each tested manu-facturer. We verified that all of the below issues work over a real GSM operator network.However, the attacks also work over UMTS.

5.1.1 Nokia

Nokia is a prime target for fuzzing as Figure 4.1(d) shows Nokia is the market leader.Especially their S40 devices are very common among feature phones. On our Nokia testdevices 3110c, 6300, 6233, 6131 NFC we found a bug in the Flash SMS implementa-tion. By sending a certain Flash SMS (8 bit class 0) the phone crashes and triggers the“Nokia white-screen-of-death”. This also results in the phone disconnecting (calls areinterrupted as well) and re-connecting again to the mobile phone network. The interest-ing thing about this issue is that the SMS actually never reaches the mobile phone. Thephone crashes before it can send the RP-ACK/Error from the SM-RL to the CM-Suband back to the network as visible in Figure 4.3.

The phone will crash before it can fully process and acknowledge the message. Onthe one hand this has the side effect that the GSM network performs a Denial-of-Serviceattack for free as it continuously tries to transmit the message to the phone. One theother hand this has a side effect on the phone since there seems to be a watchdog inplace that is monitoring such crashes. This watchdog shuts down the phone after 3 to5 crashes depending on the delay between the crashes. This can be easily exploitedhowever by sending 3 messages at once.

This issue has been reported to and confirmed by Nokia.

Even though we did not do in-depth fuzz-testing on Symbian since it is used onsmartphones we stumbled upon a minor Denial of Service (DoS) issue on Nokia E51 andE65 devices. When sending a large number of Flash SMS that are not confirmed/readthrough the user interface, the device instantly reboots. On the Nokia E51 we needed68 and 90 messages on the E65 to trigger this behaviour. The content of the FlashSMS has no influence from what we experienced. The phone is unharmed and continuesoperation. It might ask for a PIN on bootup though. This issue compared to theprevious one is pretty minor, but it still allows an attacker to kick a victim off thenetwork or interrupt phone calls as Flash SMS require no user interaction. Becauseof the high number of messages needed for this attack it is a pretty minor issue eventhough in times of SMS flatrates still a feasable attack.

46


5.1.2 Sony Ericsson

Sony Ericsson devices W800i, W810i, W890i, Aino have a problem similar to theNokia S40 phones. Those are only our test devices. However, his bug affects all SonyEricsson devices except the new Android-based ones from what we know. When com-bining certain payload lengths together with a protocol identifier of 0x7E, it is possibleto knock the phone off the network. In this case there is no watchdog, but one SMSmessage is enough to force a reboot of the phone and interrupt calls. Just like in theNokia case, this SMS message will never be acknowledged by the phone, thus the GSMnetwork will continuously re-transmit the message to the victim when it re-associateswith the network. We will later show how this looks in detail. There are small differencebetween the tested operators in Germany. The Aino behaved slightly different in ourtesting. Instead of instantly rebooting, the phone display just becomes black and isnot reacting to any user interaction during the time (ca. 10 seconds). So it looks a bitdifferent than on other Sony Ericsson devices, but the impact is pretty much the same.

It is hard to say what the actual reason for this is, but we have to note that duringour testing of this bug we also managed to completely brick a device beyond repair byplaying with this bug. It does not start anymore, is only displaying white flashes onstartup and since it already had the latest firmware, a reflash is also no option. TheW890i also occasionally completely freezed when receiving such a message.

There is usually a limit of maximum retransmits and depending on the used carrier,the retransmit intervals increase over time. However from what we have observed dur-ing our tests this had no real impact on our attacks, the phones stayed unusable for days.

This issue has been reported and confirmed by Sony Ericsson. At the time of writingon this thesis they are working on a fix for this.

5.1.3 LG Electronics

Like previously explained in Section 4.5.8, a subscriber receives a special binary encodedWAP-push message when receiving an MMS message. This message can contain variousvariable length fields in binary encoding (subject, content location, transaction ID).Our device, the LG GM360, seems to do insufficient bounds checking when parsing thesevalues. This allows an attacker to construct a multipart MMS indication messagewith long field values that crash the phone and thus force an unexpected reboot whenreceiving the message. This may as well result in a PIN lock question, if a PIN numberis set (in the case of Sony Ericsson the phone also reboots but no PIN is asked), andinterrupted phone calls. Judging the behaviour and observations made while play-ing with this bug this seems to be a buffer overflow in the MMS indication parser.Depending on what values are overflowed, the phone either only crashes on receivingthe message or additionally it also crashes on an attempt to open the message on thephone. This bug could be an interesting target for further firmware reverse engineeringefforts as its behaviour indicates that this might be a typical memory corruption issue.

This bug has not been reported to LG due to the lack of a security contact.

47

5 Evaluation

5.1.4 Motorola

Like mentioned before, SMS supports telematic inter-working with other networks.By sending an SMS message that specifies an Internet electronic mail inter-workingcombined with certain characters in the payload it is possible to knock the phone off themobile network. On receiving the message the phone shows a flashing white screen sim-ilar to the one shown by the Nokia phones. The phone is not completely rebooting, butrestarting the user interface and network connectivity. This process takes a few seconds.Calls are interrupted as well. Depending on the payload, it is possible to achieve thistwice in a row with one message. We verified this on the Razr, Rokr, and the SVLR L7.

We only fuzzed those phones very briefly because the phones behaved really weirdat some point and produced lots of false positives. But the bug that we found and thegeneral behaviour of the phones during our tests made it clear that they are all butvery robust when it comes to SMS. At some point the phone even started to crash anddo user interface reboots on its own, not related to a message sent at this time. Thismade further analysis nearly impossible as the logging facilities produced false positivesin this case.

Another issue that we noticed on these devices is that it is possible to fill up the SMSmemory completely without any visible message in the inbox. By sending multipartsequences with missing chunks and unique reference the phone memory is exhausted.Since the messages are only assembled if all pieces arrived the inbox stays empty whilethe device displays full memory capacity. Since there are no messages shown it was alsonot possible to delete any, the SMS delete function (even the one to delete all messages)only works if there are messages visible. This was not solvable via a phone reboot ora hard reset from the menu. At this point we decided to stop fuzzing this phone anyfurther and especially multipart.

Initial contact to Motorola’s security team has been established.

5.1.5 Samsung

Multipart UDH chunks are commonly used for payloads that span over multiple SMSmessages. The header chunk for multipart messages is simple and described earlier inSection 4.5.3.

Our Samsung test phones S5230 Star and S3250 Corby do not properly validatesuch multipart sequences. This enables one to craft messages having a higher UDHchunk id than the overall number of parts. This will show up as a very large SMSmessage on the phone (in the range of megabytes!). When opening such a message,the phone tries to reassemble the message, crashes and reboots. In some rare casesthis leaves the phone in a constant reboot loop. Apparently there’s a bug that lets thephone crash again if the message is received at a certain time during the bootup phase.Depending on the exact model, one two four SMS messages are needed to trigger the bug.

48


Based on this issue we discovered another bug that we call Funkstille (German termfor radio silence in reference to the Curse of Silence bug - 2.2.3.2). With a modificationof the above bug it is possible to send a silent SMS that gets the phone into a state inwhich it

• is not possible to open the SMS application anymore (phone displays Messagesinitializing... forever)

• is not possible to open the phone book application anymore

• is silently rejecting every incoming message with Protocol Error

This basically renders the phone useless except for incoming calls. It is only possibleto get rid of this behaviour by inserting the SIM card into another phone and deletingthe offending message (which will not be visible from the phone itself).

Because of the lack of a security contact, the vendor has not been informed aboutthis problem.

5.1.6 Micromax

We had a brief look at Micromax at a late stage of this thesis. This is an interestingmanufacturer. Despite being completely unknown in Europe this is the third mostpopular mobile phone brand in India.

The Micromax X114 is prone to a similar issue like the Samsung phones, but behavesslightly differently. When sending a multipart SMS that contains a higher chunk IDthan the overall number of chunks and a reference ID that has not been used yet, thephone receives the SMS message without instantly crashing. However a few secondsafter the receipt the display turns black for some seconds before the phone disconnectsand reconnects to the network. Phone calls are interrupted. This process takes a coupleof seconds after which the phone displays “Message not ready” for a short time. Besidesthis a victim will not notice the message.

Because of the lack of a security contact, the vendor has not been informed aboutthis problem.

49

5 Evaluation

0

10

20

30

40

50

60

70

80

90

100

110

120

130

1 2 3 4 5 6 7 8 9 10 11

min

ute

delivery attempt

Vodafone GermanyE-Plus Germany

O2 GermanyT-Mobile Germany

Figure 5.1: Timing of SMS message delivery attempts.

5.2 Other Notes

The following will cover a few notes that are not necessary related to feature phones.Since the thesis focuses on feature phones, not all of the mentioned devices in this sectionwere tested in-depth. However we found some aspects note-worthy.

5.2.1 Operator Differences in SMS Delivery

Some of the bugs we discovered prevent the phone from acknowledging the SMS messageto the network. Figure 4.3 shows the states that happen during a message transfer fromthe network to the phone. In the case of some of our bugs (Nokia S40 and Sony Ericsson)the message RP-ACK is not sent by the phone or its CP-DATA packet is not reachingthe network. This leads the network to believe that the message was not received,therefore, the SMSC will try to resend the SMS message to the phone. This re-deliveryattempt is a perfect attack amplifier.

Through our testing trials of sending malicious SMS messages over real operatornetworks, we discovered that operators have different re-transmit timings. Further,they also seem to have different transmit queues. We measured the delivery timings ofsome German mobile network operators in order to determine how one could abuse thedelivery attempts for improving possible Denial-of-Service attacks. We conducted the

50

5.2 Other Notes

test by attacking one of the Sony Ericsson devices and monitoring the phone using theBluetooth method described in Section 4.4.4.

Figure 5.1 shows the delivery timings for Vodafone, T-Mobile, O2 (Telefonica), andE-Plus. The initial delivery attempt is at minute 0. It shows that all operators do a firstre-transmit after 1 minute, and a few more re-transmits every 5 minutes. In addition towhat Figure 5.1 shows, Vodafone does an additional re-delivery 24 hours after the lastdelivery shown in the graph. O2 also attempts a additional re-delivery 20 hours afterthe last delivery shown in the graph.

Through the same test it was possible to determine that SMS messages are not queued,but have an individual re-transmit timer. That means an attacker can send multiplemalicious SMS messages to a victim’s phone with a short delay between each messageand thus can increase the effect of the network assisted attack through sending multiplemessages.

5.2.2 Spoofing Attacks

Besides actual vulnerabilities, a lot devices contain possibilities to spoof senderaddresses. While the real sender number is always displayed correctly for normal SMSmessages, this is not always the case for other message types. This allows an attacker toconduct for example Phishing due to the spoofing possibilities, most notably Flash SMS.Since this was originally thought to be used by operators to inform their customers, alot of phones do not properly display the originating sender number.

The Palm Pre shows the sender of a Flash SMS as the SIM card operator (e.g.“Message from O2-Deutschland”). The Blackberry Curve also displays these messagesas originating from the network. An attacker could use this for example to trick a userinto calling premium rate service numbers in the name of the operator. Other phonesfrom these manufacturers might be affected as well. We lack test devices to verify this.

Similar issues have been previously reported in [c0r09]. The LG test device suffersfrom the same problem. Nokia’s and Samsung’s WAP-push implementation also hidethe sender number. The Nokia S40 test devices display Service Message, while Samsungdisplays WAP Push.

5.2.3 SMS DDoS

We did not test SIM Data Download (4.5.10) in detail because the phone to SIMcopying makes the process very slow. But even by doing only brief testing we noticedan interesting behaviour. We set a static sender address in OpenBSC for our testmessages. While testing, we noticed that this static sender number got a few messagesaddressed to it queued in the sms database. We were curious how this could happensince we did not send messages to that number on our own.

A SIM Data Download command packet as specified in [3GP98a] defines a two bytevalue called Security Parameter Indicator (SPI). These two bytes set various secu-rity characteristics of the message. This includes things like cryptographic checksums

51

5 Evaluation

and encryption indication. The second byte of the SPI controls if and how a Proof of

Receipt SMS message is sent back to the sender. This is interesting because while wecan not control the content of this reply, we can control where it is sent to.

Services like [Rou, Cli, Hay] offer to set sender numbers to arbitrary values. Thisway we can craft a spoofed message, send it to a victim and the reply gets sent backwherever we want. The reply that gets sent back even costs money unless the victimbooked an SMS flatrate. Thus it can be used to slowly drain money from a subscriber.The receipt of such a message is silent. In our tests, only the iPhone notified the userby displaying an overlay windows stating that your SIM just sent out an SMS.

Another possibility to abuse this is SMS Distributed Denial of Service (DDoS). Thescenario would be to set the sender address to a victims phone number and send themessage to a large number of subscribers. When receiving the message, each subscriberwill fire back a message at the victim and depending on the mass of messages, renderthe phone unusable.

From what we experienced this feature differs between operators and SIM cards,however it has been verified by us to work in the wild with the T-Mobile SIM cards.

5.3 Counter Measures

In this Section we will briefly discuss counter measures to detect and prevent issues likethe presented security vulnerabilities. Because of the differences between each individualfound issue, applying counter measures is not easy.

5.3.1 Network Side SMS Filtering

We have to distinguish between preventing to deliver known malicious payload anddetecting new malicious payload. To prevent our attacks, operators need to be able todetect them. This is difficult since operators have no access to the phone itself. The onlyway to detect attacks like the presented ones is to do similar monitoring as presentedin this thesis.

By combining this with heuristics or knowledge from the machine learning field, itcan be possible to classify malicious messages and reject them at an early stage. Thiscould help to identify unknown security threats. To prevent known payloads from beingdelivered, operators can build up a central database to collect vulnerabilities. As anoperator knows the IMEI of the devices attached to their network, it is even possibleto reject certain types of messages that are known to affect certain manufacturers whendelivering such a message to a customer using such a phone. Operators can work handin hand with mobile phone manufacturers to build up such a database.

SMS filter software already exists [Tek], even though its main use seems to be thefiltering of content (e.g. for political reasons), spam prevention and SMS fraud. Thisfiltering takes place in front of the SMSC of the mobile operator. However this filteringalso has disadvantages. Because SMS makes heavy use of binary payload it is not easyto automatically classify malicious payloads. Additionally if a phone is roaming intoanother operator’s network, the SMS message does not travel through the home operatornetwork. Thus it requires every operator to apply similar filtering methods.

52

5.3 Counter Measures

5.3.2 Firmware Updates

Firmware updates are one of the best ways to solve known security issues. Howeverwith feature phones the problem is that often there are no firmware updates available,they are hard to install or a customer is not aware of an available update. Additionallyoperators often have customized and branded firmware on the devices they sell. Unlikesmartphones, feature phones often do not provide an easy way to install updates on-the-fly.

But the firmware can also be updated Over-the-Air. The process called FOTA(Firmware Over-the-Air) as defined in [Ope07] can be used to deploy and push firmwareupdates to feature phones that will otherwise not get updated by their customers. Thiscan and should be offered as a service by operators.

53

6 Conclusions

In the preceding chapters we have shown how to conduct security analysis on featurephones. Feature phones are closed in every aspect. The operating system does not allowmodifications, they do not provide programming APIs deeply hooked into the operatingsystem, they use proprietary operating systems, and the hardware is closed as well.

Despite the lack of debugging possibilities throughout our work, we have shown howa formerly closed system - the GSM network - can be utilized to analyze these devices.This also shows that once a component of a formerly closed system, the GSM network,becomes open, the security of the complete system can be analyzed to some extent.

We used the Base Station Subsystem to deliver SMS messages to the phone andmonitor their behaviour. Through this testing we were able to identify security issuesin mobile phones built by six of the major manufacturers.

Due to the popularity of these devices, this can be abused to carry out a large scaleattack on mobile phone users around the world. Furthermore, some of the found issuesare amplified by the mobile network itself. Previous studies [P. 09] have also shown thatmalicious phones inside a network that rapidly change states can carry out denial ofservice attacks against an operator network.

Therefore we believe that the found issues are a real threat against users of mobilephones, specifically feature phones, and operator networks world wide. Furthermore,we believe that there is a severe need to cut down SMS functionality to really neededand used features. Manufacturers should do in house fuzz testing and code auditsbesides only testing functionality in a positive way. We know that some, but notall, manufacturers are performing in-house fuzz-testing. Additionally, monitoring byoperators should be performed. The presented monitoring could also be used to performintelligent filtering inside the network. A part of this work has been presented [GM10]at a hacker conference. The media coverage1 already made it clear that these issues onfeature phones are indeed a big problem.

Future work includes analyzing additional SMS features (e.g. FOTA 5.3.2) as well asanalyzing some of the studied features more in-depth. Because of time constraints, notevery SMS feature has been completely implemented and we may have only scratchedthe surface. Especially the SIM Data Download feature is an interesting target forfuture analysis. Furthermore, this technique could be applied to GPRS infrastructureto perform analysis of MMS and other data oriented protocols.

1 http://www.technologyreview.com/communications/27021/,http://www.wired.com/threatlevel/2010/12/simplest-phones-open-to-%E2%80

%9Csms-of-death%E2%80%9D/ and others

55

http://www.technologyreview.com/communications/27021/

http://www.wired.com/threatlevel/2010/12/simplest-phones-open-to-%E2%80%9Csms-of-death%E2%80%9D/

http://www.wired.com/threatlevel/2010/12/simplest-phones-open-to-%E2%80%9Csms-of-death%E2%80%9D/

Glossary

APDU Application Protocol Data Unit

AuC Authentication Center

BSC Base Station Controller

BSS Base Station Subsystem

BTS Base Transceiver Station

CM-Sub Connection Mangement Sublayer

DoS Denial of Service

EMS Enhanced Messaging Service

GSM Global System for Mobile Communications

HLR Home Location Register

IED Information Element Data

IEDL Information Element Data Length

IEI Information Element Identifier

IMEI International Mobile Equipment Identity

IMSI International Mobile Subscriber Identity

MMS Multimedia Messaging Service

MO Mobile Originated

MSC Mobile Switching Center

MSISDN Mobile Subscriber ISDN Number

MT Mobile Terminated

NSS Network Switching Subsystem

OTA Over-the-Air

PDU Protocol Data Unit

57

Glossary

PLMN Public Land Mobile Network

PSTN Public Switched Telephone Network

SAT Sim Application Toolkit

SM-CP Short Message Control Protocol

SM-RL Short Message Relay Layer

SM-RL Short Message Transport Layer

SMSC Short Message Service Center

SMS-GMSC SMS-Gateway Mobile Switching Centre

SMS-IWMSC SMS-Interworking Mobile Switching Centre

SMS Short Message Service

TP-DA Destination Address

TP-DCS Data Coding Scheme

TP-MR Message Reference

TP-PID Protocol Identifier

TP-UDL User Data Length

TP-UD User Data

UDH User Data Header

VLR Visitor Location Register

WAP Wireless Application Protocol

WSP Wireless Session Protocol

58

Bibliography

[3GP96] 3GPP/ETSI. 3GPP TS 11.14 Specification of the SIM Application Toolkitfor the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface.http://www.3gpp.org/ftp/specs/html-info/31102.htm, 1996. 42

[3GP98a] 3GPP/ETSI. 3GPP TS 03.38 Alphabets and language-specific information.http://www.3gpp.org/ftp/Specs/html-info/0338.htm, 1998. 24, 38, 42,51

[3GP98b] 3GPP/ETSI. 3GPP TS 03.40 Technical realization of the Short Message Ser-vice. http://www.3gpp.org/ftp/specs/html-info/0340.htm, 1998. 23,29, 31

[3GP98c] 3GPP/ETSI. 3GPP TS 04.08 Mobile radio interface layer 3 specification.http://www.3gpp.org/ftp/specs/html-info/0408.htm, 1998. 4

[3GP98d] 3GPP/ETSI. 3GPP TS 04.11 Point-to-Point (PP) Short Message Service(SMS) Support on Mobile Radio Interface. http://www.3gpp.org/ftp/

specs/html-info/0411.htm, 1998. 29, 30

[3GP05] 3GPP/ETSI. 3GPP TS 51.011 Specification of the Subscriber Identity Mod-ule - Mobile Equipment (SIM-ME) interface. http://www.3gpp.org/ftp/

specs/html-info/51011.htm, 2005. 42

[3GP10] 3GPP/ETSI. 3GPP TS 31.102 Characteristics of the Universal SubscriberIdentity Module (USIM) application. http://www.3gpp.org/ftp/specs/

html-info/31102.htm, 2010. 42

[3rd04a] 3rd Generation Partnership Project. 3GPP TS 09.02 - Mobile ApplicationPart (MAP) Specification. http://www.3gpp.org/ftp/Specs/html-info/

0902.htm, March 2004. 14

[3rd04b] 3rd Generation Partnership Project. 3GPP TS 23.040 - Technical realizationof the Short Message Service (SMS). http://www.3gpp.org/ftp/Specs/

html-info/23040.htm, September 2004. 10, 26, 39, 42

[3rd04c] 3rd Generation Partnership Project. 3GPP TS 23.040 - Technical realizationof the Short Message Service (SMS). http://www.3gpp.org/ftp/Specs/

html-info/23040.htm, September 2004. 22

[Aho10a] Tomi T. Ahonen. Mobile Phone Market Shares for year of2009. http://communities-dominate.blogs.com/brands/2010/02/

59

http://www.3gpp.org/ftp/specs/html-info/31102.htm

http://www.3gpp.org/ftp/Specs/html-info/0338.htm















http://communities-dominate.blogs.com/brands/2010/02/phone-market-shares-for-year-of-2009-and-last-quarter-2009.html

Bibliography

phone-market-shares-for-year-of-2009-and-last-quarter-2009.

html, February 2010. 22

[Aho10b] Tomi T. Ahonen. Tomi Ahonen Almanac 2010 Mobile Telecoms IndustryReview. Tomi Ahonen, February 2010. 1

[Appa] Apple. Safari Browser. http://www.apple.com/safari/. 4

[Appb] Apple/KDE/Nokia/Google/RIM/Palm/Samsung/ProFUSION/Others.WebKit Browser Engine. http://www.webkit.org. 4

[App10] Apple. Apple iOS. http://developer.apple.com/technologies/ios/,2010. 3

[c0r09] c0rnholio. Multiple Smartphones MMS Notification Sender Obfuscation.http://seclists.org/fulldisclosure/2009/Sep/103, 2009. 51

[Cli] Clickatell. Clickatell Bulk SMS Gateway. http://www.clickatell.com.15, 52

[CM08] Jake Honoroff Charlie Miller, Mark Daniel. Exploiting Android. http://

securityevaluators.com/content/case-studies/android/, October2008. 4

[Com10a] ComScore. German Mobile Market Share. http://www.comscore.com/

index.php/Press_Events/Press_Releases/2010/1/comScore_Reports_

November_2009_German_Mobile_Market_Share, November 2010. 22

[Com10b] ComScore. U.S. Mobile Subscriber Market Share. http://comscore.com/

Press_Events/Press_Releases/2010/7/comScore_Reports_May_2010_

U.S._Mobile_Subscriber_Market_Share, May 2010. 22

[dH01] Job de Haas. Mobile security: SMS and WAP, November 2001. 5

[DH03] Lee Dryburgh and Jeff Hewett. Signaling System No. 7 (SS7/C7): Protocol,Architecture, and Applications. Cisco Press, 2003. 13

[Eng08] Tobias Engel. Remote SMS/MMS Denial of Service - “Curse Of Silence”for Nokia S60 phones. http://berlin.ccc.de/~tobias/cursesms.txt,December 2008. 7, 32

[Ets] Etsi. European Telecommunications Standards Institute. http://www.

etsi.org/. 9

[Ett] Ettus Research. USRPv1. http://www.ettus.com/. 4

[F-S09] F-Secure. First iPhone Worm Found. http://www.f-secure.com/weblog/

archives/00001814.html, November 2009. 3

60



http://www.apple.com/safari/

http://www.webkit.org

http://developer.apple.com/technologies/ios/

http://seclists.org/fulldisclosure/2009/Sep/103

http://www.clickatell.com

http://securityevaluators.com/content/case-studies/android/

http://securityevaluators.com/content/case-studies/android/

http://www.comscore.com/index.php/Press_Events/Press_Releases/2010/1/comScore_Reports_November_ 2009_German_Mobile_Market_Share



http://comscore.com/Press_Events/Press_Releases/2010/7/comScore_Reports_May_2010_U.S._Mobile_ Subscriber_Market_Share



http://berlin.ccc.de/~tobias/cursesms.txt

http://www.etsi.org/

http://www.etsi.org/

http://www.ettus.com/

http://www.f-secure.com/weblog/archives/00001814.html

http://www.f-secure.com/weblog/archives/00001814.html

Bibliography

[FD98] T. Howes Netscape Communications F. Dawson, Lotus Development Cor-poration. vCard MIME Directory Profile. http://tools.ietf.org/html/

rfc2426, September 1998. 38

[GM10] Nico Golde and Collin Mulliner. SMS-o-Death From analyzing to attackingmobile phones on a large scale. http://events.ccc.de/congress/2010/

Fahrplan/events/4060.en.html, December 2010. 55

[Hay] Hay Systems Ltd. Hay Systems Ltd. http://www.hslsms.com/. 52

[Hü] Norbert Hüttisch. PDUSpy. http://www.nobbi.com/pduspy.html. 34

[IDC10] IDC. Western European Mobile Phone Market Grows. http://www.idc.

com/getdoc.jsp?containerId=prUK22402810, June 2010. 22

[IET06] IETF Network Working Group. The Secure Shell (SSH) AuthenticationProtocol. http://tools.ietf.org/html/rfc4252, 2006. 3

[ip.] ip.access Ltd. nanoBTS 1800. http://www.ipaccess.com/picocells/

nanoBTS_picocells.php. 18

[iPh] iPhone Dev Team. iPhone Dev Team Portal. http://wikee.iphwn.org/. 4

[Kas10] Kaspersky Labs. First SMS Trojan detected for smartphones run-ning Android. http://www.kaspersky.co.uk/news?id=207576158, August2010. 3

[Kei10] M.J. Keith. webkit code execution CVE-2010-1807. http://www.

exploit-db.com/exploits/15423/, November 2010. 4

[Kes08] Kestrel Signal Processing, Inc. OpenBTS. http://openbts.sourceforge.

net/, 2008. 18

[Kut10] Darpana Kutty. Micromax becomes the third largesthandset manufacturer in India. http://www.topnews.in/

micromax-becomes-third-largest-handset-manufacturer-india-2260105,April 2010. 22

[Lac09] Zane Lackey. Mobile security: SMS and WAP, July 2009. 5

[MB07] Boris Leider Michael Becher, Felix C. Freiling. On the Effort to CreateSmartphone Worms in Windows Mobile. June 2007. 3

[Mica] Micromax mobile. Micromax mobile. http://www.micromaxinfo.com/. 22

[Micb] Microsoft. Windows Mobile. http://www.microsoft.com/

windowsmobile/. 3

[Mil07] Charlie Miller. Exploiting the iPhone. http://securityevaluators.com/

content/case-studies/iphone/, August 2007. 4

61

http://tools.ietf.org/html/rfc2426


http://events.ccc.de/congress/2010/Fahrplan/events/4060.en.html

http://events.ccc.de/congress/2010/Fahrplan/events/4060.en.html

http://www.hslsms.com/

http://www.nobbi.com/pduspy.html

http://www.idc.com/getdoc.jsp?containerId=prUK22402810

http://www.idc.com/getdoc.jsp?containerId=prUK22402810


http://www.ipaccess.com/picocells/nanoBTS_picocells.php

http://www.ipaccess.com/picocells/nanoBTS_picocells.php

http://wikee.iphwn.org/

http://www.kaspersky.co.uk/news?id=207576158

http://www.exploit-db.com/exploits/15423/

http://www.exploit-db.com/exploits/15423/

http://openbts.sourceforge.net/

http://openbts.sourceforge.net/

http://www.topnews.in/micromax-becomes-third-largest-handset-manufacturer-india-2260105

http://www.topnews.in/micromax-becomes-third-largest-handset-manufacturer-india-2260105

http://www.micromaxinfo.com/

http://www.microsoft.com/windowsmobile/

http://www.microsoft.com/windowsmobile/

http://securityevaluators.com/content/case-studies/iphone/

http://securityevaluators.com/content/case-studies/iphone/

Bibliography

[MM09] C. Mulliner and C. Miller. Injecting SMS Messages into Smart Phones forSecurity Analysis. In Proceedings of the 3rd USENIX Workshop on OffensiveTechnologies (WOOT), Montreal, Canada, August 2009. 6, 16, 22, 25

[Mob09a] Mobile Security Lab. Hijacking Mobile Data Connections, April 2009. 5, 6

[Mob09b] Mobile Security Lab. Hijacking Mobile Data Connections 2.0, November2009. 5, 6

[Mul] Collin Mulliner. Python SMS library. http://www.mulliner.org/

security/sms/feed/sms_fuzz_lib_0.1.zip. 17, 35

[Mul08] Collin Mulliner. Exploiting Symbian. http://www.mulliner.org/symbian/

feed/CollinMulliner_ExploitingSymbian_25C3.pdf, 2008. 3

[MV06] C. Mulliner and G. Vigna. Vulnerability Analysis of MMS User Agents.In Proceedings of the Annual Computer Security Applications Conference(ACSAC), Miami, FL, December 2006. 6

[Nok00] Nokia. Smart Messaging Specification. http://www.forum.nokia.com/

info/sw.nokia.com/id/49d553ab-8bd6-4792-b9b6-c549db85337f/

Smart_Messaging_Specification_rev_3_0_0_Installer.zip.html,December 2000. 10, 36

[Oeh05] Peter Oehlert. Violating Assumptions with Fuzzing. IEEE Security & Pri-vacy, 3(2):58–62, 2005. 17

[Ope] Open Handset Alliance. Android. http://www.android.com/. 3

[Ope07] Open Mobile Aliance. Firmware Update Management Object. http://

www.openmobilealliance.org/technical/release_program/docs/

copyrightclick.aspx?pck=FUMO&file=V1_0_4-20090828-A/OMA-TS-DM_

FUMO-V1_0_2-20090828-A.pdf, 2007. 53

[P. 09] P. Traynor, M. Lin, M. Ongtang, V. Rao, T. Jaeger, T. La Porta and P.McDaniel. On Cellular Botnets: Measuring the Impact of Malicious Deviceson a Cellular Network Core. In ACM Conference on Computer and Com-munications Security (CCS), November 2009. 55

[Qua] Qualcom. Binary Runtime Environment for Wireless. http://brew.

qualcomm.com/brew/en/. 16

[Rou] Routo Messaging. Routo Messaging. http://www.routomessaging.com. 15,52

[Sie] Siemens. Siemens BS11 microBTS. http://openbsc.osmocom.org/trac/

wiki/BS11. 18

[@st03] @stake, Inc. Nokia 6210 DoS SMS Issue. http://www.auscert.org.au/

render.html?it=2795, February 2003. 7

62

http://www.mulliner.org/security/sms/feed/sms_fuzz_lib_0.1.zip

http://www.mulliner.org/security/sms/feed/sms_fuzz_lib_0.1.zip

http://www.mulliner.org/symbian/feed/CollinMulliner_ExploitingSymbian_25C3.pdf

http://www.mulliner.org/symbian/feed/CollinMulliner_ExploitingSymbian_25C3.pdf

http://www.forum.nokia.com/info/sw.nokia.com/id/49d553ab-8bd6-4792-b9b6-c549db85337f/Smart_Messaging_Specification_rev_3_0_0_Installer.zip.html



http://www.android.com/

http://www.openmobilealliance.org/technical/release_program/docs/copyrightclick.aspx?pck=FUMO& file=V1_0_4-20090828-A/OMA-TS-DM_FUMO-V1_0_2-20090828-A.pdf




http://brew.qualcomm.com/brew/en/

http://brew.qualcomm.com/brew/en/

http://www.routomessaging.com

http://openbsc.osmocom.org/trac/wiki/BS11

http://openbsc.osmocom.org/trac/wiki/BS11

http://www.auscert.org.au/render.html?it=2795

http://www.auscert.org.au/render.html?it=2795

Bibliography

[SUN] SUN Microsystems. Java Micro Edition. http://www.oracle.com/

technetwork/java/javame/index.html. 3, 16, 31

[Sym] Symbian Foundation. Symbian. http://www.symbian.org/. 3

[Sym06] Symantec. Trojan.Redbrowser.A. http://www.symantec.com/

security_response/writeup.jsp?docid=2006-022814-5027-99, Febru-ary 2006. 3

[Tek] Tekelec. Tekelec SMS firewall. http://www.tekelec.com/products/?

psID=49. 52

[TEMLP08] Patrick Traynor, William Enck, Patrick Mcdaniel, and Thomas La Porta.Exploiting open functionality in SMS-capable cellular networks. J. Comput.Secur., 16:713–742, December 2008. 5

[The10] The Register. Researcher outs Android exploit code. http://

www.theregister.co.uk/2010/11/06/android_attack_code/, November2010. 4

[VI10] Ralf-Philipp Weinmann Vincenzo Iozzo. iPhone Safari vulnerabil-ity allowed to steal the SMS database. http://news.cnet.com/

8301-27080_3-20001126-245.html, March 2010. 4

[WAP] WAP Forum. Wireless Application Protocol. http://www.wapforum.com/.3, 10, 36

[WAP01] WAP Forum. Binary XML Content Format Specification.http://www.openmobilealliance.org/tech/affiliates/wap/

wap-192-wbxml-20010725-a.pdf, 2001. 41

[WAP02a] WAP Forum. Wireless Application Protocol MMS EncapsulationProtocol. http://www.openmobilealliance.org/tech/affiliates/wap/

wap-209-mmsencapsulation-20020105-a.pdf, 2002. 40

[WAP02b] WAP Forum. Wireless Session Protocol. http://

www.openmobilealliance.net/technical/release_program/

docs/Browser_Protocol_Stack/V2_1-20050204/

OMA-WAP-TS-WSP-V1_0-20020920-C.pdf, 2002. 40

[Wei10] Ralf-Philip Weinmann. All Your Baseband Are Belong To Us. https://

cryptolux.org/media/hack.lu-aybbabtu.pdf, November 2010. 4

[Wela] Harald Welte. Anatomy of Contemporary GSM Cellphone Hardware. 16

[Welb] Harald Welte. OsmocomBB. http://bb.osmocom.org/trac/. 18

[Wel08] Harald Welte. OpenBSC. http://openbsc.osmocom.org/trac/, 2008. 18

63

http://www.oracle.com/technetwork/java/javame/index.html

http://www.oracle.com/technetwork/java/javame/index.html

http://www.symbian.org/

http://www.symantec.com/security_response/writeup.jsp?docid=2006-022814-5027-99

http://www.symantec.com/security_response/writeup.jsp?docid=2006-022814-5027-99

http://www.tekelec.com/products/?psID=49

http://www.tekelec.com/products/?psID=49

http://www.theregister.co.uk/2010/11/06/android_attack_code/

http://www.theregister.co.uk/2010/11/06/android_attack_code/

http://news.cnet.com/8301-27080_3-20001126-245.html

http://news.cnet.com/8301-27080_3-20001126-245.html

http://www.wapforum.com/

http://www.openmobilealliance.org/tech/affiliates/wap/wap-192-wbxml-20010725-a.pdf

http://www.openmobilealliance.org/tech/affiliates/wap/wap-192-wbxml-20010725-a.pdf

http://www.openmobilealliance.org/tech/affiliates/wap/wap-209-mmsencapsulation-20020105-a.pdf

http://www.openmobilealliance.org/tech/affiliates/wap/wap-209-mmsencapsulation-20020105-a.pdf

http://www.openmobilealliance.net/technical/release_program/docs/Browser_Protocol_Stack/V2_1-20050204/OMA-WAP-TS-WSP-V1_0-20020920-C.pdf




https://cryptolux.org/media/hack.lu-aybbabtu.pdf

https://cryptolux.org/media/hack.lu-aybbabtu.pdf

http://bb.osmocom.org/trac/

http://openbsc.osmocom.org/trac/

Bibliography

[Wel09] Harald Welte. Fuzzing GSM Phones using OpenBSC.http://events.ccc.de/congress/2009/Fahrplan/attachments/

1503_openbsc_gsm_fuzzing.pdf, December 2009. 18

[XFo02] XFocus/benjurry. Siemens Mobie SMS Exceptional Character Vulnerability.http://seclists.org/bugtraq/2002/Jan/162, January 2002. 7

[Či10] Michal Čihař. Gammu - mobile phone management utility. http://wammu.

eu/gammu/, 2010. 30

64

http://events.ccc.de/congress/2009/Fahrplan/attachments/1503_openbsc_gsm_fuzzing.pdf

http://events.ccc.de/congress/2009/Fahrplan/attachments/1503_openbsc_gsm_fuzzing.pdf

http://seclists.org/bugtraq/2002/Jan/162

http://wammu.eu/gammu/

http://wammu.eu/gammu/

7 Appendix

This appendix provides a German summary of this thesis.

7.1 Deutsche Zusammenfassung

Mobilfunkkommunikation ist ein wichtiger Teil unseres alltäglichen Lebens geworden.Einer der am meisten eingesetzten und genutzten Dienste ist dabei der Short MessageService (SMS). Deshalb müssen diese Dienste zuverlässig und auch sicher sein. DieSicherheit der sogenannten smartphones wurde dabei in der Vergangenheit gut unter-sucht und ist mit der zunehmenden Anzahl von Telefonapplikationen ein fortlaufendesForschungsgebiet. Die Mehrheit der Benutzer verwendet allerdings nicht diese high-end Geräte, sondern verlassen sich stattdessen auf die einfachen, sogenannten featurephones. Im Vergleich zu smartphones erlauben diese in der Regel keine Modifikatio-nen des Betriebssystems und sind deshalb in der Vergangenheit kein Ziel für struk-turierte Sicherheitsanalysen gewesen. Die neue Entwicklung von Open Source GSM-Software erlaubt jetzt allerdings zunehmend ein ehemals geschlossenes System - dasGSM-Netzwerk - für Analysezwecke dieser Geräte, zumindest in Teilen, zu verwenden.

In dieser Diplomarbeit präsentieren wir ein “Framework”, basierend auf einer BaseTransceiver Station, die auf dem den öffentlichen Markt erhältlich ist, einer modifiziertenVariante von Open Source Software zum Betreiben eines GSM-Netzwerkes und diversenScripten, um Telefonverhalten zu beobachten und große Mengen an SMS Nachrichtenerstellen zu können. Dies erlaubt uns eine groß angelegte Sicherheitsstudie von SMSImplementierungen auf einer Vielzahl von feature phones durchzuführen. Durch dieVielzahl von vorhandenen Möglichkeiten smartphones zu untersuchen, haben wir unsauf die Analyse von feature phones konzentriert. Es bleibt jedoch anzumerken, dass sichdie von uns verwendete Methode nicht notwendigerweise auf feature phones beschränkt.

Im Laufe unserer Analyse haben wir Sicherheitsfehler in den Plattformen aller verbre-iteten feature phone-Hersteller entdeckt. Wir legen dar, welche Wirkung diese Fehlerhaben und diskutieren auch Probleme, die nicht nur feature phones betreffen, die unswährend dieser Tests aufgefallen sind.

65

Documents

SMS Vulnerability Analysis on Feature Phones · SMS Vulnerability Analysis on Feature Phones Nico Golde January 17, 2011 Technische Universität Berlin Fakultät IV Institut für