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

7/28/2011 3:12:15 PM
Battery-Draining Attack

One attack that builds off using MMS notifications is a battery-draining attack. The goal of a battery draining attack is to drain the battery of a victim’s phone without their knowledge in a manner that is far more rapid than normal usage, thereby knocking the victim’s, phone offline. This attack exists due to the nature of how mobile phones are optimized to use their internal radio the absolute minimal amount. When a customer is looking at purchasing a new mobile phone, they are often presented with two numbers that represent battery lifetime. The first number is “standby” time, which is typically on the order of several days. The second number is “talk” time, which is a much lower number, usually measured in just a few hours. This is because modern mobile phones are highly optimized to keep their internal radio powered down and avoid sending data whenever possible because this rapidly drains the battery. A battery-draining attack takes advantage of this fact by forcing the radio in the mobile phone to stay on indefinitely until the battery has been exhausted. The key to this attack is performing it stealthily in a way that requires no victim interaction, so that the victim is completely unaware that the attack is being performed.

One of the easiest ways to perform this attack is by abusing the MMS notification functionality. To perform an attack via this method, an attacker crafts an MMS notification message that points to an attack server they control. In the case of a battery-draining attack, the bandwidth needed to perform the attack is negligible, which allows an attacker to use even a home DSL line to perform the attack. Once the MMS notification message has been constructed pointing to their hostile server, the attack sends the message to the victim. The victim’s phone receives the message and automatically connects to the attack server to receive what it assumes will be a legitimate MMS message. Instead of returning a valid image file or video as part of a normal MMS, the attacker has instead configured their server to keep the victim’s phone connected to the server indefinitely. The attacker can perform this in a number of ways, although the easiest method is by “pinging” the victim’s phone with UDP packets. In this method, the attacker waits for the victim’s phone to connect and then obtains the victim’s IP address. The attacker then slowly sends UDP packets to the victim’s IP address, which forces the victim’s phone to stay online and keep the radio powered on. The amount of resources needed for this attack is usually quite low because mobile phones have a timeout value for how long they will stay connected to the Internet without receiving data. For example, if the victim’s mobile phone is set to disconnect if no data is received after 10 seconds, then the attacker only needs to send one UDP packet every nine seconds to force the victim’s phone to stay connected. The amount of resources an attacker needs to be able to send a single UDP packet every nine seconds is so trivial that it means an attacker with a single computer on a home DSL line could likely simultaneously attack an extremely large number of mobile phones. Figure 5 illustrates the concept of this attack.

Figure 5. Battery-draining attack

For real-world results of this testing, UC Davis computer security researchers performed this attack against several mobile phones. In their research, they found that they were able to drain the battery life of a target mobile phone up to 22.3 times faster than by normal usage. For details of their research, view “Exploiting MMS Vulnerabilities to Stealthily Exhaust Mobile Phone’s Battery” at

Silent Billing Attack

Another attack that builds off the nature of MMS messages is the silent billing attack. This attack primarily targets mobile customers with prepaid mobile phones that depend on having a credit balance in their account. The goal of a silent billing attack is to silently drain the victims credit so that they are knocked offline and unable to perform further actions such as making or receiving calls.

To understand how this attack works, first one must think back to the discussion of how MMS messages function. Unlike text SMS messages, MMS messages have more overhead and involve several background messages to set up and confirm that an MMS has been successfully delivered. Because these background messages are only a small part of the process of an MMS message, mobile phones are programmed to not display messages of these types to the user. Instead, they are processed in the background as part of an MMS message, and if they refer to an invalid MMS message they are simply (from a user’s perspective) silently ignored. The silent billing attack takes advantage of two key facts about these types of messages: First, that these messages are silently ignored and not displayed to users. Second, that these messages are still perfectly valid messages from the billing perspective of the carrier’s network. Therefore, an attacker can abuse these messages when they wish to deplete the balance of a victim who has a prepaid mobile phone account, unbeknownst to the victim. By bombarding the victim’s phone with any of the background messages not displayed to the victim/user (for example, a Send Confirmation), the attacker is able to rapidly wipe out the credit balance on the victim’s account. The victim will not be aware that this attack has taken place because their phone didn’t display any of the incoming messages. Thus, once the attack has been completed, the victim is unaware that their account is now empty and they will no longer receive legitimate incoming calls or text messages, in addition to being denied when attempting to place an outbound call or send a text message.

When compared with the other attacks in this article, the silent billing attack is hardly the most severe. However, it is included here because it serves to illustrate the point that not all attacks against mobile phones via SMS will be about exploiting code-level flaws in implementations. Rather, there are a wide range of ways to abuse legitimate functionality inside the SMS specifications that can cause real and potentially serious issues for SMS users.

OTA Settings Attack

Over The Air (OTA) settings involve the ability of a carrier to push new settings to a customer’s mobile phone on their network. Support for OTA settings varies widely from mobile phone to mobile phone and from manufacturer to manufacturer; however, mobile phones from Nokia, Sony Ericsson, and Motorola typically contain at least some support for OTA settings, whereas other phones may not. Like SMS itself, the term OTA settings is actually a catchall that can refer to a number of different items. Everything from pushing new browser settings, to pushing firmware updates, to provisioning mobile phones for use on the carrier’s network has been referred to as “OTA settings.” Detailing all potential OTA settings attacks could easily fill an entire book; therefore, in this section we will focus on one common usage of OTA settings. Once this example is understood, its principles can be applied to attacking any other form of OTA settings.

The attack we discuss here involves pushing new WAP browser settings to a target mobile phone. The goal of this attack is to install new settings into the browser configuration of the target mobile phone. If the attack is successful, the victim’s browser will then route all traffic through a proxy that the attacker controls. The attacker is then able to sniff the connection to obtain personal information about the victim, as well as to perform man-in-the-middle attacks against the victim’s traffic. Luckily for an attacker, constructing a message to perform an attack such as this is fairly straightforward. This is due to the fact that WAP browser settings are typically represented in an easy-to-understand XML format. For example, the following is the XML representation of a normal WAP browser settings message that a carrier could send to a customer’s mobile phone:


In this message, the carrier has sent several settings to the customer’s mobile phone. These settings tell the mobile phone’s browser to use the carrier’s WAP proxy located at IP address and to log into this proxy using the username “wapuser” and password “wappassword” as well as to use PAP as the authentication type. Once a message such as this has been constructed, it is sent from the carrier’s network to the user, as shown in Figure 6.

Figure 6. Carrier-initiated OTA message

However, as with the attacks discussed previously, there is often nothing blocking an attacker from being able to construct their own message of this type and sending it through the carrier’s network. For example, consider the following attacker-constructed message:


It should be noted that the attacker’s message is even easier to construct than the legitimate carrier-generated message. This is due to the fact that the attacker does not worry about having the victim authenticate to the attacker’s proxy server. The attacker doesn’t want any problems with authentication to block the victim from sending their traffic through the attacker’s proxy, so they leave the authentication options out of the settings. The attacker then sends their hostile settings to the user through the carrier’s network, as shown in Figure 7.

Figure 7. Spoofed OTA message

A common assumption may be that this attack is not likely to be successful in the real world because a target of the attack would simply see a message from a friend’s number or a number they didn’t recognize displaying something along the lines of new settings being received. However, often in practice the victim has almost no contextual information with which to make an informed decision about whether or not the incoming settings are legitimate or the source of these settings. For example, consider the screen shown in Figure 8, which demonstrates the notification displayed to the user of a Sony Ericsson W810i mobile phone when it receives new hostile settings from an attacker.

Figure 8. OTA settings screenshot

The main issue that should become immediately apparent is, how does a user know whether this is a legitimate settings update from their carrier or hostile settings being sent from an attacker? No source number of the message is shown, and no indication of what settings will be changed is shown. What if this message had been combined with a social-engineering attack that preceded the new settings dialog with a message saying, “This is a free message from your carrier. We’re rolling out new settings to our customers to enhance their mobile experience. Please accept these new settings when they appear on your phone in the next several minutes.” In this case, even generally security conscious users would likely install the new hostile settings.

This section has demonstrated just one of many possible attacks using OTA settings. However, the lessons learned from this attack can easily be applied by an attacker to performing any other attack using OTA settings. Finally, this section has demonstrated just how easy this attack may be to perform when a target mobile phone displays little or no information that would allow a user to make an informed decision on the legitimacy of the incoming OTA settings.

Attacking Protocol Implementations

As implied by this section’s title, unlike the previous sections, this one does not cover a specific attack. Rather, this section describes the methodology of how to go about attacking SMS implementations.

Before attack methodologies can be discussed, it is important to understand the significant challenges that restrict and complicate testing for SMS security issues in mobile devices. Specifically, when testing SMS implementations for security issues, the primary hurdle to overcome is reliance on the carrier network. Imagine a scenario in which a tester wishes to fuzz a certain MMS message type where there are 50,000 possible test cases (which is not a particularly high number of test cases for a fuzzer). If each one of these test cases needs to be sent through the carrier’s network as an actual SMS, the amount of time this will take the tester is unrealistically high, to say nothing of the cost. Instead, the goal of anyone wishing to test the security of SMS implementations is to remove the carrier’s network from the equation. One way to do this is to turn the test environment into one that closely resembles testing a TCP/IP network service over an intranet. For example, when testing a newly developed HTTP server for bugs, a tester would rather set up a small dedicated LAN to conduct testing rather than testing the HTTP server over the public Internet.

The easiest way to remove the carrier’s network from the testing process is to take advantage of the Wi-Fi support modern mobile phones have. If a tester can place a mobile phone on a Wi-Fi network and deliver SMS messages to the device over this connection instead of over the carrier’s GSM/CDMA network, the testing experience can be greatly improved. For example, the Windows Mobile 5 platform offers this support by default. When Windows Mobile 5 is placed on a Wi-Fi network, it will listen on UDP port 2948 for incoming SMS WAP messages. This allows significant SMS functionality to be tested on the Windows Mobile 5 platform while circumventing the carrier’s network for greater testing speed and less cost.

An additional way to overcome this hurdle is to use an emulator instead of an actual mobile device. At the time of writing, the best mobile phone emulator to work with is without a doubt the Android emulator, which allows the tester, via use of the sms pdu command, to specify a PDU on the command line that the emulated phone will then treat as if it had just been received from the carrier’s network. This allows the tester to exercise all areas of SMS functionality. The goal of a tester on any platform should be to remove the carrier’s network from the testing equation, whether via Wi-Fi-like Windows Mobile 5 or an emulator such as Android. Although we will not go further in depth on this topic (because it is different for each version of each platform out there), the point of mentioning these challenges is twofold. First, it makes the tester aware of the significant hurdle using the carrier’s network adds to testing. Second, it makes the tester aware that often their target platform will have some functionality either built into the device or in the developer emulator that allows this hurdle to be overcome. Testers should seek this functionality out and use it to greatly improve their testing experience.

Once these limitations have been overcome, there remains the question of how to go about actually testing a targeted SMS implementation. Although “dumb” fuzzing such as generating PDUs filled with garbage data may find a bug or two, the complex structure of an SMS PDU often requires an intelligent approach to finding issues. To help the tester understand what sort of intelligent test cases to come up with, this section discusses two types of SMS messages as case studies that will show testers how to approach testing.

The first type of SMS discussed is attacking concatenated message functionality. The SMS concatenated message functionality is used when a user wants to send a message that contains more characters than can be fit in a single SMS PDU. The message is then split across multiple SMS PDUs, which are each sent to the recipient. A User Data Header is inserted into the PDU that tells the receiving mobile phone that this message is a multipart message that will need to be concatenated together before being displayed to the user. Additionally, the User Data Header for a concatenated message informs the recipient mobile phone how many segments the multipart message is split into as well as what segment number the current message is. As a tester reading about this functionality, it certainly sounds like there are a number of different attacks an attacker may try against this functionality. Because mobile devices typically have extremely limited memory, the simplest attack a tester may wish to try is simply sending the theoretical maximum number of segments that a concatenated multipart message can contain. The tester’s rationale for this attack is that the developer of the SMS implementation in use may make an assumption that the largest concatenated message a user will ever legitimately send would contain 10 or even 100 segments, but not the full theoretical maximum of 255. The developer would then define a message buffer that only contains enough space to contain the “realistic” maximum number of messages, such as 10 or 100. Therefore, by constructing an “unreasonably” large (but still technically valid) message, the tester may find a vulnerability in the target SMS implementation when it tries to reassemble multipart concatenated messages with a greater number of message segments than the developer anticipated.

The second type of SMS discussed is one of the many background MMS messages that occur during the involved process of one mobile subscriber sending rich content (such as a picture) over MMS to another subscriber. The MMS message type that has been chosen for this study is the MMS delivery report. The delivery report is a message sent from the carrier’s MMS server to the mobile phone of the subscriber who originated the MMS in order to confirm that the message has been successfully delivered. The delivery report message contains five different fields: MMS Version, Message ID, To, Date, and Status. As discussed in the SMS concatenation example, the tester should look for fields where the SMS implementation developer may have made assumptions about the likely use case. In the case of the MMS delivery report, the first such field that springs to mind is the To field. The reasoning for this is that a developer could quite easily assume that the To field will only ever contain a telephone number, and therefore the maximum size it will ever need to be is the length of a large international number. However, there is nothing stopping a tester or attacker from putting in an extraordinarily large number or string in this field. The only requirement for this field actually stated in the MMS specification is that it be a NULL-terminated string. Therefore, it would be possible for a tester to create a string much larger than any international telephone number and place it in the To field. When testing MMS implementations, the tester should look for a field such as To due to the assumption that can easily be made about the field (limited to the size of an international phone number) which in reality differs from the actual definition of the field (unlimited size string).

Unlike previous sections, which discussed specific known attacks against SMS and MMS implementations, the goal of this section has been to teach those testing implementations about the challenges they face and the methodology that can be used during testing. It is hoped that by applying these approaches, testers will be able to find and remove issues from SMS implementations being shipped in current and future mobile devices.

  •  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)