Service Loading primer (with related attacks)

During the same days of our Hijacking attack presentation at BH EU ’09, we read of “a-sort-of” SMS hijacking attack performed on Windows Mobile phones. On the demonstrating video here a binary SMS is sent to a Windows mobile phone, and the browser suddenly pops up, opening an attacker specified URL. That’s the typical behaviour of an handset receiving a Service Load (SL) message, and actually this type of attack had already been discussed (here and here). We feel that this might still be a somewhat underestimated risk in the mobile environment, as Service Loading is supported by many platforms apart from Windows Mobile; but before going deeper into that, let’s explain what Service Loading messages are and what are they for.

Service Loading is a part of the WAP Push protocol suite for OTA (Over The Air) provisioning of mobile handset. It is often cited together with Service Indication: like Service Loading, Service Indication is used to carry URL addresses to the handset in a binary SMS message; but it is rather meant to notify the user of a certain URL in order to be, for instance, added to the bookmarks, and not necessarily to open it at once.

Let’s see the basic structure of a SL message:

Service Loading DTD

As any other WAP protocol element, it uses an XML representation; the actual SL element have only two attributes: an URI (commonly said to be URL) and an action; the latter can be “execute-high”, meaning the content is executed in an user-obtrusive (visible) manner, “execute-low”, meaning the content is executed in a non user-obtrusive (invisible) manner, and “cache”, meaning that the content should simply be put in browser’s cache, not executed neither displayed. The default is execute-low. In order to be sent, this document must be converted to WBXML format (a compressed binary representation), then stuffed in an SMS message according to WSP protocol.

Upon receiving such a message, if the URI is an HTML page, the phone will load and show it with the default web browser; if it is an executable program, it will download and execute it, possibly in a silent way. The risk associated with this feature, especially without user’s awareness, should be obvious also for non tech savvy readers; that’s why most handsets come with some sort of security policy associated with WAP Push messages.

We have conducted a test on two largely used devices, a Nokia N95 and a Sony Ericsson C905, to check how they deal with Service Loading messages.

On Sony Ericsson C905, the user can choose on preferences whether to accept or refuse WAP Push messages altogether, or to be asked every time.

C905 Push Menu C905 Allow Push Message

If “Always ask” is chosen, an incoming Service Loading message will be shown as a “new event” and the user can load the content by pressing “go to” button.

C905 Push Message Info C905 Push Message Information

Unfortunately, details include nothing more than the complete URL; the source phone number is missing, so a message from an unknown source would be indistinguishable from one sent by network operator; not that it would be so hard for an attacker to spoof the source, but it would be still better than nothing. Moreover, the event isn’t stored as a message, and disappears once you’ve open the target link; if you don’t pay enough attention then, there’s no way to reconstruct exactly what you’ve done later, or even demonstrate you’ve received it.

If you chose to allow all push messages, no confirmation is requested; the address is loaded without any user intervention!

Nokia N95 also have an option to disable or enable processing of Push messages; however, it doesn’t seem to affect SL messages, as regardless of what you select an user confirmation is requested to open the link.

Nokia Service Message Settings Download Messafe Manually Download Messages Automatically

Upon receiving a Service Loading message, user is asked if he wants to open the associated URL; the source phone number isn’t show by default, but it is accessible under “message details”, together with many other informations that unfortunately cannot still determine if it can definitely be trusted…

Download Message Notification Download Message Selection Message Details

The SL message then remains in “Received” SMS folder, and can be accessed or viewed later.

As a final note, both devices seem to ignore “action”, as they behave exactly the same way regardless of “execute-high”, “execute-low” or “cache” value.

These two examples demonstrates how Service Loading could potentially be a security risk on several major mobile platforms, especially because the user interface around it isn’t so refined, as to the security, like other more common events. Maybe you’re wondering whether is it a real risk: after all, simply loading an URL appears more annoying than dangerous; if a program is to be executed, that would probably trigger some other user interaction, involving an installation, permissions and certificates… And a device allowing to run any program by simply visiting a link have a security problem by itself, indipendently from SL. True, but executing programs isn’t the only risk. Here are some example scenarios of how an attacker may take advantage of SL messages:

  1. Point the victim browser to XSS vulnerable sites: that could ultimately lead to the building of an interesting form of mobile botnets.
  2. Make the handset perform websites attacks on behalf of the attacker, eg: ‘mobile-proxied’ SQL injections could be quite hard to track down.
  3. Give the victim an hard time by making its mobile browser visit questionable websites: <your_own_list_here>.
  4. Attack internal Mobile Operator websites: if victim is provided with a private IP address, internal network resources may be indirectly accessible by an attacker.
  5. Exploit browser specific weaknesses: that could lead to mass owning of vulnerable handsets.
  6. New vector for mobile viruses spreading.

We are not exploring the details of each scenario here; most of them are nothing new, and simply require an adaptation of known attack schemes to the SL specific vector.

But an attacker may additionally be provided of some advantages with using SL messages:

  • SMS can be spoofed: that could make attacker tracking down even more difficult. Some handsets do not even show the source of SL messages.
  • Some handsets could be able to process WAP Push messages (including SL) over IP.
    • UDP is the typical transport protocol: it is spoofable and IP packets are cheaper than SMS

Because of these reasons (feel free to add more), we think that security aspects of SL messages should be carefully considered by anyone in the mobile environment. Final suggestions to mobile phones users are:

  • Check that your phone is configured to ask you what to do on receiving WAP Push messages; this should be the default setting, but it’s better to check – especially when dealing with mobile operator customized firmware.
  • Never allow or open unrequested or unknown links or any other content, even if the request appears to come from a trusted source.
  • Check carefully the message details, and discard it if any suspect arise.

Leave a Reply