Dangerous Texts: Preventing SMS Cracking

The very first SMS (Short Messaging Service) message was sent on December 3^rd, 1992. As cellular phone technology exploded since then, now your average person sends and receives many SMS text messages each year. In a world where the overwhelming majority of adults (and some children) carry a smartphone or a ‘feature phone’, texting is an easy way for me to keep in touch with people, in my work and in my personal life. I’m far from alone.

If you have a medium or large office-based workplace, chances are that your employees use SMS in their work- quite often on corporately owned smartphones. The technology is really convenient, and sending texts takes less work than sending e-mails. But if your company uses SMS texting, it’s vital that your IT department is aware of the possible dangers of that medium. It’s possible to make your texting more secure, especially when you understand the features of that technology.

When an SMS message is sent from a device, it’s received by a Short Message Service Center (SMSC). Most SMSCs are provided by one’s wireless service provider, such as AT&T, Rogers, or Vodafone. If the recipient’s device is turned off or out of service range, the SMSC will be held in a queue until the message can be delivered. Usually the message will be held in queue for up to a few days, but the queue time limit varies according to the service provider. The MAP (Mobile Application Part) of the SS7 protocol acts as an application layer for SMS between GSM, UMTS, CDMA, and TDMA networks, allowing for SMS transport between different wireless networks and technologies worldwide. SMS messages can also be sent to a variety of types of devices, including PCs, via various TCP/IP ports, including port 80 for HTTP, and port 25 for SMTP.

SMS messages are limited to 1120 bits in length. Depending on the character encoding being used, a conventional SMS message could use up to 160 7-bit characters, 140 8-bit characters, or 70 16-bit characters. But SMS is used for more than simply encoding text to create conventional SMS messages, and therein lies the possibility for the technology to pose certain security risks.

The SMS protocol is used for many other functions in addition to sending and receiving messages. SMS is also used as a transport for WAP, Wireless Application Protocol. WAP is especially useful on ‘feature phones’, older cellphones and other phones which lack 3G or 4G data technology. On data-less phones, WAP allows for WML web surfing. On phones with or without data, WAP via SMS allows phones and other wireless gadgets to communicate with other classes of devices, such as the electronics in your car.

A User Data Header (also known as UDH) in an SMS message allows it to become a WAP push- data input for applications and devices which use WAP. WAP pushes usually, but not always, use TCP and UDP port 2948. The UDH is used to direct an SMS message to that port. A WAP push is an SI, a Service Indication which can direct an application to a specific URL. WAP pushes are classified as ‘binary SMSes’. A binary SMS is formatted with XML using WBXML to encode XML with fewer bits. For example, under WBXML, ‘0C’ is ‘http://’ and ‘0D’ is ‘http://www.’ Therefore, one security risk with SMS is WAP pushes that could direct devices to malware infected webpages.

There have been some significant IT security threats identified with SMS over the past few years. IT security experts and hackers have found vulnerabilities, and some of the possible consequences may be surprising.

In July 30^th, 2009, security researchers Collin Mulliner and Charlie Miller of Independent Security Evaluators publicized that they found a memory corruption bug in the Apple iPhone’s iOS operating system. The flaw involves sending specifically crafted SMS messages. In an interview with Tom’s Hardware, Miller said:


"The iPhone bug has to do with telling the phone there is a certain amount of data, and then not sending it as much as you said you would. The function that reads the data starts returning -1 to indicate an error, but the other parts of the program don't check for this error and actually think the -1 is data from the message. This shows how complex it can be to write secure code, as separately, each part of the program looks correct, but the way they interact is dangerous!

Anyway, depending on what you send, different bad things can happen. At one point, you can get it to exit because it is about to allocate -1 bytes (which is viewed as 0xffffffff–a very large number). This is a denial of service that will knock the phone off the network temporarily.

During my BlackHat talk, we kept sending this denial of service message every 10 seconds to a volunteer from the audience to keep him off the network. As an unfortunate consequence, the messages were getting cued up on the network and his phone was still getting knocked off hours after the talk. He has since gotten back up and running.”

The main vulnerability involves how iOS 2.0 to iOS 3.0 handles concatenated SMS messages. Although one SMS is limited to 1120 bits, sequenced messages can be linked together in iOS’ SMS application to assemble a string of data which is much longer. Miller’s exploit used over 500 messages. None of the messages sent would be noticeable to the recipient phone’s user because the UDH definition would assign the messages to a port and program outside of iOS’ SMS application. SMS reception in iOS, including UDH defined WAP pushes, use the CommCenter process, which runs as root, therefore it requires no user notification or authorization. Miller’s exploit was essentially a DoS (denial of service) attack. Once an attacker obtains control of the targeted iPhone with that technique, it can execute the same DoS attack on other iPhones.

Apple moved quickly, and by the next day, July 31^st, they released iOS 3.0.1 via iTunes. The OS update included a patch to harden CommCenter from that particular DoS exploit.

That isn’t be the only time an SMS vulnerability has been discovered that affects iPhones. Another exploit was discovered by Vincenzo Iozzo of Zynamics and Ralf Philipp Weinmann of the University of Luxembourg during CanSecWest Pwn2Own 2010 in Vancouver, Canada. This exploit uses the URL direction ability of XML encoded binary SMS WAP push messages I mentioned earlier.

In the exploit, a WAP push directed an iPhone’s web browser to a website with malicious code. The website grabbed the SMS database from the iPhone, which even included deleted messages. The SMS database was then directed to a web server under the exploiter’s control.

The attack was assisted by well known security researcher Halvar Flake. Flake said that the greatest challenge was bypassing the code-signing mitigation used in iOS. On the Zynamics blog, Flake said:

"The payload used chained return-into-libc (return oriented programming) on ARM to execute in spite of code signing. As far as we know, this is the first public demonstration of changed return-into-libc on the ARM platform."


What’s especially alarming is that the exploit could then gather photos, music files, e-mails and phone contacts from the targeted iPhone.

SMS vulnerabilities have also been found in the other most popular smartphone OS, Google’s Android.

On August 10^th, 2010, Kapersky Labs found the first SMS trojan to target the popular mobile platform. The trojan program is called ‘Movie Player’, a 13KB download from a website, not on the Android Market. Once installed, ‘Movie Player’ sends SMS messages to premium rate numbers which charge the user several dollars each, without the victim being notified in any way before or during the action.

That first Android SMS trojan discovered wouldn’t be the last. On May 11^th, 2011, the AegisLab blog reported that a developer that was on the Android Market published apps that also maliciously sent SMS messages to premium rate numbers. The malware were released by ‘zsone’ and included iBook, iCartoon, LoveBaby, 3D Cube Horror Terrible, Sea Ball, iCalendar, iMatch, Shake Break, ShakeBanger, iMine and iGuide.

In iCartoon, when the user clicks to shift images for the fifth time, an SMS message could be sent to 1066185829 which would invoke premium charges unbeknown to the user. It was programmed in a way designed so that the user wouldn’t notice, with the following code:

Courtesy of blog.aegislab.com

The premium numbers the ‘zsone’ published trojans used could only be accessed via Chinese networks, and the premium numbers the ‘Movie Player’ trojan used could only be accessed via Russian networks, still there’s no reason why future trojans won’t be developed which could use premium numbers for other countries around the world. Android applications list which phone services they’re designed to use upon installation. Therefore, users can prevent being victimized by these types of SMS trojans by being careful to not install applications that request permission to send SMS messages, when such a function wouldn’t seem relevant, such as in a ‘Movie Player.’ Antivirus applications such as Lookout may also prevent such trojans from being installed. The Lookout antivirus application is a free download on the Android Market, and I use it on my Android smartphone.

As I mentioned, SMS messages can be used with devices other than wireless phones. These abilities have wider reaching implications which can be surprisingly disturbing. Some computerized systems in recent high end cars and other motorized vehicles, such as General Motors’ OnStar RemoteLink, can receive wireless messages to trigger certain functions, such as unlocking doors and starting engines. In July 2011, Don Bailey and Mathew Solnik of iSec Partners identified an exploit which targets such systems.

First, they used ‘war texting’ to identify vehicle devices which use mobile phone interactivity. Then, Bailey and Solnik intercepted messages from a car starting mobile application. By intercepting those messages, they found a vehicle devices’ unique secret numerical keys for authentication. In an interview, Bailey said:

"We reverse-engineer the protocol and then we build our own tools to use that protocol to contact that system."


By spoofing the SMS messages that the mobile application was designed to send to the vehicle’s computerized device, the researchers could trigger the car door unlocking and car starting functions from a laptop.

Bailey and Solnik were careful to not identify further technical details about the exploit, including the mobile phone applications and vehicle models that were affected, so that the manufacturers could patch the bug before a cracker tries the exploit with malicious intent.

Other types of devices that could be affected by similar SMS triggered exploits include security cameras, home control and automation systems, urban traffic control systems and A-GPS enabled devices.

SMS cracking can be prevented by being mindful of overall security practices for corporately owned smartphones and other mobile devices. IT departments can reduce the likelihood that such devices are subject to unauthorized access by limiting the functionality of corporate phones to what’s required for business.

In an article published by ComputerWorld magazine, Gartner analyst John Girard identified ten common smartphone security risks.

1. No configuration management plan.
   Tip: Responsibility for managing smartphones should be given to the same staffers who provision and manage PCs.
   
2. No power-on password, or a weak password policy.
   Tip: Several vendors’ device management consoles allow you to configure password complexity rules and password reset questions and answers.
   
3. No inactivity timeout/auto-lock.
   Tip: Timeout policies should be enforced over the air through your device management console, so that the enterprise can maintain near-real-time control.
   
4. No auto-destruct/data-wiping plans.
   Tip: Two methods should be used: over-the-air commands and locally initiated wipes. The latter should occur after a password has been entered incorrectly a certain number of times or when a device has been off the network for a predefined amount of time.
   
5. No memory encryption rules.
   Tip: Major enterprise smartphone operating systems provide settings for enforcing encryption.
   
6. No master plan for backup and synchronization.
   Tip: Use a secure, over-the-air backup-and-restore tool that performs periodic background synchronization.
   
7. No e-mail-forwarding barriers.
   Tip: Forwarding of e-mail and attachments can be regulated with server-side settings of a corporate e-mail system, and additional filtering is available through commercial data loss prevention filters.
   
8. No application certification rules.
   Tip: Private keys can be used to restrict which applications are allowed to install or execute.
   
9. No default browser permission rules.
   Tip: Choose browser default settings that comply with company policy when phones are provisioned, to avoid providing an entry point for malicious code.
10. No plan for dealing with smartphone diversity.
    Tip: Set a policy that defines what levels of support different devices will receive. Assign smartphone support to a single IT group.
    

Understanding the threats that SMS technology poses, it’s imperative that IT departments, vendors and device manufacturers around the world are mindful of such possibilities.

References:

• UK hails 10th birthday of SMS
  

  Rashmee Z Ahmed, The Times of India: http://timesofindia.indiatimes.com/articleshow/30216466.cms
  

• Injecting SMS Messages into Smart Phones for Security Analysis
  

  Collin Mulliner andCharlie Miller: http://www.usenix.org/event/woot09/tech/full_papers/mulliner.pdf
  

• WAP – Wireless Access Points and Wireless Application Protocol
  

  Bradley Mitchell, About.com: http://compnetworking.about.com/cs/wireless/g/bldef_wap.htm
  

• Binary SMS: sending rich content to devices using SMS
  

  Julien Buratto, mobiForge. http://mobiforge.com/developing/story/binary-sms-sending-rich-content-devices-using-sms
  

• Short Message Service: What, How and Where?
  

  Puneet Gupta, Wireless Developer Network. http://www.wirelessdevnet.com/channels/sms/features/sms.html
  

• Understanding SMS
  

  Michael Harrington, Mobile Forensics. http://mobileforensics.files.wordpress.com/2007/06/understanding_sms.pdf
  

• Simple Steps to Hack a Smartphone
  

  Joan Goodchild, PCWorld. http://www.pcworld.com/article/164132/simple_steps_to_hack_a_smartphone.html
  

• How to Hack Cell Phone Text Messages. http://cellphonespytextmessages.weebly.com/how-to-hack-cell-phone-text-messages.html
  
• Exclusive Interview: Hacking The iPhone Through SMS
  

  Alan Dang, Tom’s Hardware. http://www.tomshardware.com/reviews/hacking-iphone-security,2384.html
  

• Apple Patches iPhone SMS Security Hole With Software Update
  

  Brian X. Chen, Wired.com. http://www.wired.com/gadgetlab/2009/07/apple-patch-sms/
  

• Pwn2Own 2010: iPhone hacked, SMS database hijacked
  

  Ryan Naraine, ZDNet. http://www.zdnet.com/blog/security/pwn2own-2010-iphone-hacked-sms-database-hijacked/5836
  

• Android market affected by SMS Trojans
  

  Vanja Svajcer, Naked Security. http://nakedsecurity.sophos.com/2011/05/13/android-market-affected-by-sms-trojans/
  

• Security Alert 2011-05-11: New SMS Trojan “zsone” was Took Away from Google Market
  

  AegisLab. http://blog.aegislab.com/index.php?op=ViewArticle&articleId=112&blogId=1
  

• Security Alert: First Android SMS Trojan Found in the Wild
  Tim Wyatt, The Lookout Blog. http://blog.mylookout.com/2010/08/security-alert-first-android-sms-trojan-found-in-the-wild/
  
• Your Car Can Be Hacked via SMS
  Eric Limer, GeekOSystem. http://www.geekosystem.com/car-hacked-via-sms/
  
• ‘War texting’ lets hackers unlock car doors via SMS
  

  Robert McMillan, NetworkWorld. http://www.networkworld.com/news/2011/072711-war-texting-lets-hackers-unlock.html
  

• Black Hat USA 2011 //briefings
  

  blackhat.com. https://www.blackhat.com/html/bh-us-11/bh-us-11-briefings.html#Bailey

• Smartphones need smart security practices

  Mary Brandel, computerworld.com. http://www.computerworld.com/s/article/345297/Smartphones_Need_Smart_Security?taxonomyId=15&pageNumber=1