I decided I should offer some clarifications about some of this USSD stuff as my blog posts and test page have become widely cited…

I didn’t discover this issue and I’m not a mobile security expert. The first place I saw details was in the YouTube clip featuring Ravi Borgaonkar (@raviborgaonkar). I recognised what was happening and set about testing it myself.

My test page uses the USSD code *#06# which is supposed to display the phone’s IMEI number. A phone is only really vulnerable if the 14- or 16-digit IMEI code is displayed with no specific user intervention.

Update: In some cases having the IMEI display doesn’t necessarily indicate a vulnerability to other (potentially more damaging) service codes. This is because it’s possible that some dialers may handled different codes differently (the IMEI code could be a special case, etc). While this is technically true it is hard to verify on a given device. In general I think that allowing the automatically handling of any special code taht wasn’t keyed in directly is a bad design and should treated with as much caution as possible.

While many Android phones are vulnerable in general to the injection of these USSD codes, only the Samsung phones are known (at this stage) to have a working “factory reset” USSD code. However, while this may mean other phones aren’t at risk of being wiped it doesn’t mean there aren’t still risks. There are a wide variety of USSD codes that can potentially do other damaging or annoying things, even interacting with a user’s carrier account.

Update: I’ve used the term USSD to describe the overall vulnerability. This is not strictly true. A USSD code is designed to communicate with the network. The other codes could more accurately be called device codes, service codes or engineering codes perhaps, as they are handled locally by the phone and have nothing to do with the network. However they do (usually) follow the same pattern, starting with * and ending with # – so I’m okay with calling them USSD codes, even if it’s not entirely accurate.

A factory reset may not be as damaging as some have suggest (to be honest, I haven’t been keen to see exactly what gets wiped) but it is, at the very least, incredibly inconvienient. It’s likely that app settings and other less obvious data will be lost even if things like images and files are retained.

Some browsers (most notably Opera) appear to offer some security by not handling the iframe injection code immediately. This is not much help as there are potentially other ways to inject the URI within the browser as well as other attack vectors (such as the QR code, SMS WAP Push and NFC methods detailed by Ravi.

While manufactuers may have issued (or be issuing) new firmware to address this issue, the frequently cited issues with Android fragmentation and carrier customisation both appear to hamper this. The best workaround for the majority of users, I believe, is to install an alternative dialer or one of the applications that has been designed to catch potentially harmful tel: URIs.

Please read: Remote USSD Attack – Clarifications

The remote USSD vulnerability I detailed in my last post (and now covered widely in the tech media) is not just a Samsung problem. The same general vulnerability (executing a USSD code without user intervention from a website, or other delivery vector) affects many phones. I’ve personally verified it on an HTC One X (running HTC Sense 4.0 on Android 4.0.3) and a Motorola Defy (running Cyanogen Mod 7 on Android 2.3.5).

I’ve also heard reports of the proof of concept working on a Sony Xperia Active. 

The potential impact of the issue is limited only by whatever USSD codes can be executed on a given phone. It’s not clear if all manufacturers have Factory Reset USSDs on but at least some do.

I have only been testing with the IMEI code and have no intention to test with anything more damaging, but it is possible that in some cases different USSD codes could be handled differently. So while the IMEI code may work, it’s possible that other more damaging codes would not. This is, however, very speculative and there’s no safe way to know without testing.

Regardless it is very poor design to allow a passed value to execute as if it were keyed in interactively.

Update: It would appear that the root of the problem is probably the standard Android dialer – the vulnerability was identified and patched three months ago. For this reason it’s likely to affect any phone using the standard dialer (as it existed three months ago) or a dialer based on it.

It would be fairly trivial to weaponise the vulnerability to detect phone model with browser User Agent and tailor the response to suit.

As I mentioned in my earlier post – the simplist to mitigate the risk from this issue is to install another dialer. Either setting one that exhibit the risky behaviour as default, or simply having more than one installed to force a “Complete action using..” choice.

Please read: Remote USSD Attack – Clarifications

An interesting (and potentially devestating) remote attack against at least some Samsung Android phones (including the Galaxy S3) was disclosed recently.

Update 1: Samsung have been aware of this issue for a few months and the latest firmware for Galaxy S3 (4.0.4) appears to resolve the issue.

Update 1a: While some 4.0.4 versions appear to be secure, others are vulnerable.

Update 1b: The issue has been patched in some firmware builds. It appears that all 4.1-based builds are safe, and possibly some 4.0.4 builds are also.

Update 2: Samsung is not alone in being vulnerable to this issue.

Update 3: Some apps have been created specifically to catch these URL calls: TelStop (by @colimrm) and Auto-reset Blocker

In brief it works like this:

• Phones support special dialing codes called USSDs that can display certain information or perform specific special features. Among these are common ones (*#06# to display IMEI number) and phone specific ones (including, on some phones, a factory reset code). 
• There is a URL scheme prefix called tel: which can, in theory, be used to hyperlink to phone numbers. The idea being that clicking on a tel: URL will initiate the phone’s dialer to call that number.
• In some phones the dialer will automatically process the incoming number. If it’s a USSD code then it will be handled exactly as if it had be keyed in manually – requiring no user intervention to execute.
• A tel: URL can be used by a hostile website as the SRC for an iframe (or potentially other resources like stylesheets or scripts I guess). It may then be loaded and acted upon with no user intervention at all.

A video demonstrating the process has been widely circulated – it also details some other vectors to deliver the tel: URL – including WAP Push SMS, QR Code and NFC. All of these processes have the same end result.

[youtube http://www.youtube.com/watch?v=Q2-0B04HPhs?wmode=transparent]

I created a small page to test the attack myself (using the non-destructive *#06# IMEI code rather than the very damaging factory reset one) and replicated the outcomes displayed in the video and documented elsewhere.

The fundamental problem here is the dialer. It is acting on the phone number it’s sent exactly as it would had it been keyed in directly. If it the tel: URL can be directed to an application that does not have that behaviour then the threat can be neutralised.

Thankfully Android allows for alternate dialers to be installed. I picked a popular one from Google Play – Dialer One – and installed it. Even with out making it the default phone dialer I have prevented the threat. A tel: URL will now prompt me for the application to use.

If I select the standard dialer the same issue reoccurs, but if I select Dialer One (which does not take action on the incoming USSD code) or cancel the request entire I am protected.

It’s likely that many other dialers behave in the same way, but you should test them carefully. The important thing is to avoid letting the stock dialer handle tel: URLs without direct user interaction.