Mobile Application Security : SMS Security - Protocol Attacks (part 1)

7/28/2011 3:10:23 PM
A number of attacks belong together under one logical heading of “protocol” attacks. However, these attacks can then be thought of as belonging to one of two subcategories.

The first of these subcategories is abusing legitimate functionality. These attacks do not exploit a previously undiscovered flaw in the implementation of software on a target mobile phone, but rather misuse legitimate functionality purposely built into the mobile phone. In every mobile phone network there is a significant portion of functionality that is meant to be hidden from the end user of a mobile device. For example, administrative and provisioning communication between mobile phones and the carrier network is designed to take place in such a way that the user should have no way to modify it, and ideally such that the user is not even aware it is taking place. In the SMS realm, a number of administrative messages take place without the user being directly informed. Typically these relate to actions such as updating settings on the phone, pushing executable updates to the phone, and setting up more advanced and involved communications like MMS. One administrative function that is not an attack, but clearly illustrates the sort of administrative functions that can be delivered over SMS, is voicemail notifications.

Voicemail notifications occur after a voicemail has been left for a mobile subscriber. Once the carrier receives the voicemail, a notification must be generated to let the mobile subscriber know they have a voicemail waiting on the carrier’s voicemail server. This notification can be sent in one of several ways; however, the most commonly used method is to send the mobile subscriber a specially crafted SMS that informs the mobile phone that X number of voicemail messages are waiting. When the mobile phone receives this special message from the carrier, it displays a notification to the user, generally in the form of a pop-up or a graphic appearing on the phone. In this example, the voicemail notification is a special administrative message sent over SMS that is only supposed to be generated by the carrier’s network. However, often there is nothing blocking an attacker from generating their own voicemail notification message and sending it to a victim. Although this could hardly be considered a serious attack, it serves to illustrate the point that there are legitimate administrative functions performed over SMS. These functions are meant to be sent from a carrier to a subscriber’s mobile phone; however, typically nothing is in place to stop an attacker from spoofing these messages and sending them to victims’ mobile phones. Figures 1 and 2 graphically illustrate, respectively, a legitimate voicemail notification being sent to Alice, followed by an attacker (Bob) spoofing a voicemail notification to his victim (Alice).

Figure 1. Carrier-initiated voicemail notification

Figure 2. Spoofed voicemail notification

The second of these subcategories involves attempting to find vulnerabilities in the implementations of the popular SMS protocols. The goal of these attacks is to find a vulnerability in the SMS implementation of a mobile phone that would allow an attacker to send a corrupted message to a victim’s phone that would result in the victim’s phone running hostile code. Discovering these vulnerabilities often relies on corrupting, or fuzzing, otherwise valid SMS messages in such a way that triggers an error condition on the mobile phone. For example, in a basic SMS header, the length field tells the receiving mobile phone how many characters are stored in the incoming message. If an attacker can manipulate this length field to say there are a larger number of characters than there really are, an error condition could potentially be triggered.

Figure 3 illustrates a normal SMS with the length field first correctly set at 3 (03), followed by the same message with the length field manipulated to 255 (FF).

Figure 3. Corrupted SMS PDU

Abusing Legitimate Functionality

This section focuses on three different examples of abusing legitimate functionality. First a background on WAP Push messages is discussed, followed by an example attack. Next, MMS Notification functionality and attacks are discussed. Finally, an example OTA Settings attack is covered.

WAP Push Intro

For a multitude of reasons, mobile carriers require the ability to interact with the mobile phones on their network in an administrative fashion. A WAP Push SMS message is one such mechanism carriers employ to achieve this goal. A WAP Push message is designed to allow an authorized party such as a user’s carrier to push content to a user’s cell phone. This allows carriers to initiate a connection to the cell phone in order to provide updates or services to the customers. Although WAP Push functionality can communicate over UDP port 2049 on phones that support it, SMS is used as the primary delivery mechanism. Once it is delivered over SMS, the content contained inside a WAP Push message requires little if any user interaction, depending on message type and options. The messages are meant not to interrupt the user by mostly operating in the background, as exemplified by the different types of WAP Push messages available.

The three types of WAP Push messages available are SI (Service Indication), SL (Service Loading), and CO (Cache Operations). Both SI and SL types deliver a URI to the phone pointing to content. The CO type invalidates objects created by SI or SL messages. This section provides the necessary background information on these three types so that SMS attacks involving WAP Push messages can be discussed.

Service Indication messages are used to inform the user that a service is available. The user can choose to act on the information by starting the service or postponing it.

The service is pointed to by the URI included in the SI message. The message can also include a description of the service in order to give the user more contextual information on whether or not they’d be interested in the message. Typical services can be stock quotes, e-mail notification, and advertising. The key concept is that this message type requires user notification and interaction.

Service Indication messages are created in XML and then compiled to the WAP Binary XML (WBXML) binary format, as defined by the WAP Forum. The following is a sample Service Indicator message:

<?xml version="1.0"?>
<indication href="" si-id="1234"
action="signal-medium" >
Message Text

The various attributes in this message are explained in the following list:

  • href This is a Uniform Resource Identifier (URI) to the service.

  • si-id This an ID for the message, represented as a string value. If it is omitted, the ID will be set to the href value.

  • action This defines the action taken by the phone. The first three present information to the user and vary in urgency. The possible actions are:

    • signal-low

    • signal-medium

    • signal-high

    • signal-none

    • delete

There are also attributes related to message creation and expiry times.

Service Loading messages, as the name implies, load a service and have the option of doing so without any user interaction. These messages were designed for carriers to be able to force the user to execute a service. In contrast to SI messages, SL messages only have two attributes. The following is a sample Service Load message:

<?xml version="1.0"?>
<sl href="" action="execute-low" ></sl>

The various attributes in this message are explained in the following list:

  • href As before, the href attribute defines the location of the service. However, the action attribute has different options. The action attribute defines the level of user interaction.

  • execute-low The specification states that this option must not be user intrusive. In other words, the service is executed without informing the user.

  • execute-high The specification states that this option may be user intrusive. The implementation can vary whether the user is informed or not.

  • cache The service is cached onto the phone. It is not executed but rather just fetched. The user is not informed that the service is loaded onto the phone.

The difference between SI and SL is apparent in their action names: signal versus execute. As will be shown in the next section, the service-loading functionality is of far more use to attackers.

WAP Push CO messages invalidate objects in the cache. CO messages are not covered because they only allow invalidating previously sent messages. Generally the same privileges are required to successfully send CO messages as well as SL and SI messages.

WAP Push Attack

WAP Push Service Loading messages are the quintessential example of legitimate functionality that can be abused by an attacker. SL messages were designed to allow mobile phone carriers the ability to push content to users without user interaction. Precisely because of this functionality, SL messages provide an incredibly attractive target for attackers who wish to be able to push malicious content to phones. This section walks through using a WAP Push SL message to perform an attack pushing an executable to a mobile phone.

In this example, the attack targets Windows Mobile devices, many of which are vulnerable by default (refer to In the case of Windows Mobile devices, the vulnerability arises out of configuration mistakes as opposed to an implementation flaw such as a buffer overflow. In its configuration, Windows Mobile defines what authentication is required for SL messages in the registry using security policies. The security policies are stored in HKEY_LOCAL_MACHINE\Security\Policies\Policies. The SL message policy is defined by the “0000100c” DWORD value. The default value is 0x800 or SECROLE_PPG_TRUSTED. This means that only messages originating from a trusted push proxy gateway are authorized. Many Windows Mobile phones, however, have the policy set to SECROLE_PPG_TRUSTED or SECROLE_USER_UNAUTH. Thus, any SL message regardless of source will be accepted. Although Microsoft specifically states that SECROLE_USER_UNAUTH should not be used in SL Message Policy (, in practice a large number of default carrier-provided Windows Mobile devices have been found to be set to the vulnerable setting of SECROLE_USER_UNAUTH.

When an attacker wishes to attack a device that is set to not require any authentication of WAP Push SL messages, they craft an attack by sending an SL message with a link to a malicious payload. The payload can be a web page but it can even be an executable. The following XML illustrates an attacker’s WAP Push SL message:

<?xml version="1.0"?>
<sl href="" action="execute-low" ></sl>

The message will force the target phone to download payload.exe and proceed to execute it. The attack is done without any user interaction because the action is specified as execute-low.

This section illustrates the ease with which attackers can abuse functionality legitimately built into mobile phones involving SMS if the conditions are right. Although the number of public disclosures on attacks such as this remain far behind the number of publicly announced implementation flaws, the severity of attacks such as this will ensure that they remain a target of attackers for some time to come.

MMS Notification

As described in the section on MMS, there are far more moving pieces involved in sending and receiving an MMS message than a regular SMS. From the user’s perspective, however, there is not much difference between sending/receiving an MMS and sending/receiving an SMS. That is because the additional steps needed to send and receive an MMS are handled silently in the background by the carrier and the user’s mobile phone. MMS notifications are one of the many background messages used in MMS delivery. MMS notification messages are not attacks on their own; however, other attacks are built on top of them. In order to understand these attacks, more detailed coverage of MMS and MMS notifications in particular is needed.

As noted earlier, MMS uses many more messages than SMS. The majority of the new messages are background traffic used by the phone and carrier to aid message delivery. These messages are not displayed or available to the user. Figure 4 shows the traffic and messages used by MMS.

Figure 4. MMS message

This figure uses numbers to represent messages in order:

  1. Bob sends an MMS message. The underlying message is M-Send-req.

  2. The Mulimedia Messaging Service Server (MMSC) confirms Bob’s message and sends an M-send-conf message confirming the message.

  3. The MMSC sends Alice a notification message, M-Notification.ind. The message contains an URL. Note that this URL is the key for various attacks.

  4. Alice responds to the MMSC with an M-NotifyResp.ind message. This message is just a confirmation of message 3.

  5. Alice issues a WSP or HTTP GET.req message to the location provided in the notification message from message 3. This operation can happen after a time delay if user action is required. User action varies on different platforms.

  6. The MMSC sends an M-Retrieve.conf message to Alice. The rest of the messages are background traffic, which isn’t too relevant for attack purposes.

  7. Alice sends the MMSC an M.Acknowledge.inf message. The message completes the MMS for Alice.

  8. Finally, the MMSC sends Bob an M-Send.conf message.

This discussion demonstrates the delivery of MMS at a more detailed level. As seen, the majority of the traffic is delivered in the background without informing the user. Out of the messages delivered to the target phone, M-Notification.ind is the most interesting. It is delivered on top of a WAP Push message. The payload contains a URL that usually would point to the carrier-controlled server.

In order to observe what effect this message, by itself, would have on a mobile phone. The phones tested provide a range of results, as detailed here:

  • The majority of the phones did not probe the user at all and performed the GET request to an arbitrary URL. For an attacker, this is easily the most sought-after result. This means that if an attacker can send a victim a specially crafted MMS notification that points to a server they control, they can force a victim’s mobile phone to connect directly to their attack server. This obviously opens a wide-ranging attack surface on the victim’s mobile phone to which an attacker can directly connect.

  • Some phones that prompted the user for confirmation on accessing the URL contained in the MMS Notification still performed a silent GET request without informing the user.

  • Other phones prompted the user without providing any context as to where the URL was located. The user was merely provided with a screen informing them “A new message has been received – Download? (Yes/No).” It is likely that almost every user would say yes in this situation. After the user selects Yes, the GET request is issued.

  • Finally, some phones prompted the user with full contextual information about the originating phone number of the message and the URL pointed to in the message.

Although it may not seem so at first, the MMS notification message is exceptionally useful for an attacker. To realize this importance, one needs to be aware of a large difference between attacking a mobile device and a regular desktop or server system. First, consider an unfirewalled system sitting on the Internet. If an attacker wishes to launch an attack on this system, there is nothing preventing the attacker from connecting to the system and launching a slew of attacks. Next, consider a firewalled system on the Internet. In this case, the attacker will likely be blocked from accessing significant portions of the target system, yet many potentially large areas will still remain. Compare this to a mobile phone, where an attacker has virtually no ability to connect to the target device. By using an MMS notification message to force a victim’s phone to connect back to a system the attacker controls, the attacker finally obtains the ability to launch attacks directly against the mobile phone.

  •  Mobile Application Security : SMS Security - Overview of Short Message Service
  •  iPad SDK : Popovers - The Font Name Popover (part 2)
  •  iPad SDK : Popovers - The Font Name Popover (part 1)
  •  Beginning Android 3 : Working with Containers - Tabula Rasa
  •  Beginning Android 3 : Working with Containers - LinearLayout Example & The Box Model
  •  iPhone Application Development : Reading and Writing User Defaults (part 2) - Implementing System Settings
  •  iPhone Application Development : Reading and Writing User Defaults (part 1) - Creating Implicit Preferences
  •  - Mobile Application Security : SMS Security - Overview of Short Message Service
  •  - Mobile Application Security : Bluetooth Security - Bluetooth Security Features
  •  Integrating Your Application with Windows Phone 7
  •  Introducing Windows Phone 7 Photo Features (part 2) - Using a Chooser to Open Photos & Saving Photos to the Phone
  •  Introducing Windows Phone 7 Photo Features (part 1) - Using a Chooser to Take Photos
  •  Mobile Application Security : Bluetooth Security - Bluetooth Technical Architecture
  •  Mobile Application Security : Bluetooth Security - Overview of the Technology
  •  Windows Phone 7 Development : Push Notifications - Implementing Cloud Service to Track Push Notifications
  •  Windows Phone 7 Development : Push Notifications - Implementing Raw Notifications
  •  Windows Phone 7 Development : Push Notifications - Implementing Tile Notifications
  •  Windows Phone 7 Development : Push Notifications - Implementing Toast Notifications
  •  iPhone Application Development : Creating a Navigation-Based Application
  •  Windows Phone 7 Development : Push Notifications - Introducing the Push Notifications Architecture
    Top 10
    Nikon 1 J2 With Stylish Design And Dependable Image And Video Quality
    Canon Powershot D20 - Super-Durable Waterproof Camera
    Fujifilm Finepix F800EXR – Another Excellent EXR
    Sony NEX-6 – The Best Compact Camera
    Teufel Cubycon 2 – An Excellent All-In-One For Films
    Dell S2740L - A Beautifully Crafted 27-inch IPS Monitor
    Philips 55PFL6007T With Fantastic Picture Quality
    Philips Gioco 278G4 – An Excellent 27-inch Screen
    Sony VPL-HW50ES – Sony’s Best Home Cinema Projector
    Windows Vista : Installing and Running Applications - Launching Applications
    Most View
    Bamboo Splash - Powerful Specs And Friendly Interface
    Powered By Windows (Part 2) - Toshiba Satellite U840 Series, Philips E248C3 MODA Lightframe Monitor & HP Envy Spectre 14
    MSI X79A-GD65 8D - Power without the Cost
    Canon EOS M With Wonderful Touchscreen Interface (Part 1)
    Windows Server 2003 : Building an Active Directory Structure (part 1) - The First Domain
    Personalize Your iPhone Case
    Speed ​​up browsing with a faster DNS
    Using and Configuring Public Folder Sharing
    Extending the Real-Time Communications Functionality of Exchange Server 2007 : Installing OCS 2007 (part 1)
    Google, privacy & you (Part 1)
    iPhone Application Development : Making Multivalue Choices with Pickers - Understanding Pickers
    Microsoft Surface With Windows RT - Truly A Unique Tablet
    Network Configuration & Troubleshooting (Part 1)
    Panasonic Lumix GH3 – The Fastest Touchscreen-Camera (Part 2)
    Programming Microsoft SQL Server 2005 : FOR XML Commands (part 3) - OPENXML Enhancements in SQL Server 2005
    Exchange Server 2010 : Track Exchange Performance (part 2) - Test the Performance Limitations in a Lab
    Extra Network Hardware Round-Up (Part 2) - NAS Drives, Media Center Extenders & Games Consoles
    Windows Server 2003 : Planning a Host Name Resolution Strategy - Understanding Name Resolution Requirements
    Google’s Data Liberation Front (Part 2)
    Datacolor SpyderLensCal (Part 1)