For the record, Dylan won’t actually remote-wipe your device without permission. Indeed, he won’t wipe your device at all. He just shows you if it might be possible for a web page to do so. The Kiwis probably already thrashed your country at rugby, even after two of their players got sent off. They don’t need to rub it in by wiping the floor with your phone, too.

The details of the disaster are absurdly simple, so allow me to explain at some length.

It all starts with RFC 3966, which defines a special sort of URI for telephone numbers. You use these URIs, which start with tel:, like this:

The "tel" URI is a globally unique identifier ("name") only; it does not describe the steps necessary to reach a particular number and does not imply dialling semantics. Furthermore, it does not refer to a specific physical device, only to a telephone number.

So telephone URIs don’t instruct your browser, or your tablet, or your phone, to dial. They just suggest that it could, if it wanted.

What’s got Dylan Reeve hot under the collar is that in some browsers, on some builds of Android, on some phones, the dialling semantics of telephone URIs are: load the default dialler or “phone” application, insert the number as if you’d typed it, and wait for you to press the magic green button to initiate the call.

Waiting for the green button is a security measure. It prevents a website calling out without some sort of user interaction. That would be insecure and could be expensive.

In short, some browsers treat tel: URIs almost as a special, and tolerated, form of cross-site scripting (XSS). Visit one site at an innocent-looking URI, and end up redirected to a different URI in a different application for a different purpose.

So far, so good. But what’s got Dylan’s smoking collar on the verge of bursting into flames is this: automatic in-band signalling.

In-band signalling is when some special character combinations, appearing in your regular data stream, are treated as control sequences.

As you can imagine, this is the sort of compromise implemented to bring convenience at the cost of security.

The inherent risk of in-band signals is one of the reasons that FTP was designed to use two TCP connections, one outbound and one inbound – so that the data and control channels were kept separate. It was also one of the reasons why FTP withered for data transfer in favour of HTTP, which uses a single channel and thus works more easily.

Mobile phone numbers support a raft of in-band codes with the grandiose collective name of Unstructured Supplementary Service Data (USSD). As Wikipedia notes, in its uniquely uneven yet informative style:

The user composes a message — usually rather cryptic — on the phone keyboard. The phone sends it to the phone company network, where it is received by a computer dedicated to USSD. The answer from this computer is sent back to the phone. The answer could be seen on the phone screen, but it is usually with a very basic presentation. The messages sent over USSD are not defined by any standardisation body, so each network operator can implement whatever it finds suitable for its customers.

Sounds like a recipe for confusion, if not actually disaster, doesn’t it?

So, what does a USSD look like? Perhaps the best-known, and the one used by Dylan on his demo page, is to enter *#06# to pop up your phone’s official identification number, better known at the IMEI.

If you type *#06# into the dialler on your own phone, you may very well see that the IMEI pops up as soon as you press the final # key.

Although some diallers warn you that you’re on the verge of triggering a USSD code – and give you an out-of-band warning so you can prevent it, which is handy – others do not. They recognise USSD codes as you type them in, on the grounds that you’re not making a call, so there’s no need to wait for you to press the green button.

This means, if you browse to Dylan’s test page and your IMEI pops up without any further interaction, that you are at risk of a potentially lethal combination – lethal to your data, anyway.

This is because many phones offer a USSD command for “factory reset”. It’s meant to be hard to type by mistake – impossible, more or less. But it’s not impossible for a miscreant to type into a tel: URI on a malevolent web page, and there’s the rub. Or, in fact, the wipe.

What to do?

If your phone is vulnerable – and if Dylan’s page says it is, it probably is – then Mr Reeve suggests installing a third-party dialler application which is known to provide safety against the auto-activation of USSDs. That’s good advice.

Your current browser or dialler might be safe already. On my Google Nexus phone, for example, running Android 4.1 with the Firefox browser, visiting Dylan’s page does pop up the phone dialler. But the *#06# USSD code is not auto-triggered – it just appears as a number you haven’t dialled yet. As far as I can see, the dialler only processes the in-band USSD codes if they are typed in by hand. That’s good.

(Before you install a brand new dialler app – and you knew I wouldn’t resist a little advertising somewhere in the article, didn’t you? – you might also consider a trip to the Play Store to install Sophos Mobile Security. Completely free, you get anti-virus, anti-malware, anti-spyware, anti-adware, loss and theft protection, plus a pair of really easy-to-use security and privacy advisor tools.)

The bottom line here is this: get into the habit of backing up your phone. Whether you choose to trust the cloud, or synchronise to your laptop, or just copy important files to removable storage, don’t take the long-term data integrity of your phone for granted.

You might suffer a hysterically-funny-to-some-childish-haxxor remote factory reset. It could happen.

But you might also leave your phone in the pub, have it nicked from your bag, or drop it catastrophically onto the only concrete surface for hundreds of metres in every direction (like I did a couple of weeks ago, on a balmy Sunday spring afternoon that was going gorgeously up to that point).

If your digital life is at risk from an unexpected factory reset, then you need to re-arrange your digital lifestyle.

Assume that all your electronic devices might break at any time, and that at least some of them will.

As mentioned in the article, exactly how any browser/OS combination handles a "tel:" URI isn't defined by the RFC. The telephone URI is just there "to tell you what to dial if you have a mind to do so."

Likewise, if the browser/OS chooses to pass the "tel:" URI to the dialler app, then it's up to that dialler app to decide what to do with it.

And if the dialler app chooses to process the "tel:" URI, it's up to the app to decide how it wants to handle special USSD codes embedded in the telephone number…

Problem is, today's mobes are all about function and convenience (and, we must admit, about form, too :-). Security is important. Possibly even very important. But, dare we say it, not the most important thing…

On the demo page, my Lumia900 popped up a message asking whether I wanted to edit the "number". That seems good enough. (The raw code from the keypad does show the IMEI upon the last #, but that doesn't seem problematic either. I've chosen not to try the factory reset code.)

Sophos Mobile Security doesn't scan URIs – its main purpose is to vet apps for dodginess as you install them, and check out their privacy settings, etc. (It would have scanned telstop for you, for example.)

That's why I was careful to mention our product only after mentioning the idea of downloading a new dialler or dialler safety tool – our anti-virus is recommended to protect you whilst downloading the other recommended protection 🙂

BTW, does the IMEI actually pop up all on your Nexus, if you allow the URI past telstop?

On my Nexus, the default dialler isn't (as far as I can see in admittedly very limited testing) vulnerable. A number in a "tel:" URI isn't handled as a USSD, _only_ as a number.

If I type in the USSD using the on-screen number keys then it's treated as a USSD. When "input" by visiting a tel: URI, It just appears as a number I want to dial. If I then press the green button (which is no longer green, but then the dial is no longer dial-shaped), it doesn't process the *#06# as a USSD. It just tries to dial it, which does nothing…

It can be a bit confusing when people don't know what they're looking for. As far as I know on the Android dialer is vulnerable. iOS and Windows Phone dialers seem to just open the dialer with the number displayed, but don't execute the code.

As it isn't a bug in Firefox. Its job is to process the 'tel' URI like any other browser and hand it over to the OS to deal with further. Its job is not to determine what is a valid USSD or a phone number, especially if the source for the browser is largely manufacturer independent.

Surely the first port of call (or app to find fault with) is the dialler rather than the browser?

Whilst Firefox can mitigate the risk by filtering tel: URIs, it's presumably the dialler that is imbued with the knowledge of which numbers trigger USSD exchange events and which are just plain old numbers.

Surely the cleanest solution is the one I think I'm seeing on my android 4.1 Nexus – only act on the USSD codes if the code is typed in on the keypad? (And even then, ask for confirmation – perhaps even explain what the code is for.)

So don't shout too hard at Firefox – perhaps call it a "most useful and well-warranted feature" rather than a bug!

The Android source code was patched against this about three months ago.

For most users the biggest issue will be that they can't easily upgrade the system software (dialler or stock browser). I guess at least if third party browsers implement some filtering then there is an easy application upgrade target for most users without being reliant on manufacturer or carrier.

A Samsung Galaxy ace running android 2.3.6 almost triggered it, but in my case a factory software load (thanks Optus) had already put a second dialer there so it asked me. When I let it go through to the main dialer, it did it's work.

Galaxy tab 7.7 (running android 3.2), and without a phone connection, it bought up the dialer window, but didn't actually finish dialing it.

In both cases with the default browser. I might spend some time going through some other browsers tonight to see what else brings it up.

From what I've heard (and tested), it's only a vulnerability with some overlays (Samsung's TouchWiz being the one receiving the most attention just now). Stock Android seems to be perfectly fine.

My Nexus S is perfectly fine, and since it's just stock Android I'd expect the same to apply to any device running the same (although I may well be wrong here). Even if you do press the dial button after visiting the tel: URI, the phone doesn't actually do anything other than complain about the code.

Yet another reason why these horrendous overlays (I'm looking at you HTC and Samsung!) are a bad thing 🙂

When I tried this from within the Facebook app (following Sophos’ Facebook posting), nothing happened. But, when I went to the site with Safari, a dialer box popped up with a choice of “cancel” or “dial”. This is on an iPhone 4S with IOS 5.1.1.

That's the expected behaviour – it requires a direct user intervention to "dial" the number it's passed. From what I've heard that's the case on iOS and on Windows Phone 7 also. And in both cases even actively choosing to "dial" the number will not actually execute the USSD and the applications are aware they were actively keyed in.

When I followed Sophos’ Facebook post from within the Facebook app on my iPhone 4S running IOS 5.1.1, nothing happened at Dylan’s site. But when I used Safari to follow the same trail, I got a dialer pop-up with a choice of “cancel” or “dial”. If I selected dial, nothing appeared to happen.

Stock Android may not understand this factory reset code, but it contained the vulnerability. It's fixed in Android 4.1: https://android.googlesource.com/platform/package… (see last 3 commits). It's not fixed in official Android 4.0, but reportedly the fix was backported to some ICS phones (including SGS3).

I downloaded Sophos' Mobile Security app to my Samsung Infuse 4G running Android 2.3.6. Visited the test URL. Sophos did not prevent the IMEI from displaying when I visited the site. Reading this article, I was left with the impression that if I use Sophos Mobile Security, the "attack" will be detected.

Yeah but you did say about halfway through the article now its time for an advertisment for sophos, those of us who are only skimming the article might be inclined to think that meant you were trying to write an unbiased peice about the issue and then suggesting in a more subtle way that the answer is to run your "mobile security" app.

Why even mention Sophos mobile security in the same article given it does nothing to help with this issue in any way shape or form?

I'm a big fan of Sophos for PC's but android phones dont need an AV product to slow them down as long as the user takes 2 seconds before they download an app to check if its legit.

I hear you. My first inclination was to fall on my sword and say, "So sorry, Sir! I deeply regret that you are confused after skim-reading my article! I apologise unreservedly for what you were inclined to think simply because you didn't read it properly! I should write with inattention in mind!"

But it's such a lovely day that I've decided to take another side here. Mine.

Firstly, I didn't suggest that "the answer is" to run our app. In fact, I suggested that "the answer" might be to download an alternative dialler app. Maybe you missed that in bits of the article you skimmed over?

Secondly, whilst Sophos Mobile Security doesn't help directly with the tel: URI issue (would that it did), it _does_ provide some very useful extra safety and security _if you decide to download a new dialler app as I suggested_. Or any other new app, for that matter.

Thirdly, instead of writing off our Android app with a blanket assumption that will "slow you down", are you willing to do me a favour? Try it out, and see if it makes any tangible difference at all to performance. If it doesn't, I'll give you double your money back.

Apologies for my adversarial stance. (Only joking. I enjoyed it.) I hope you will tolerate my wounded pride – especially when you admit that you didn't really read the article in the first place 🙂

Dialer appeared, but IMEI did not. Curiously, I tried deleting some (but not all) of the characters and retyping, but that didn’t force the IMEI to show. If I cleared them all, however, and then retyped them into the dialer, it did show the IMEI number.

I prefer this behavior so that I have to manually input the entire code for something to act.

And for all those people still running really old versions of android (2.2 I saw somewhere above, eww) you should have a look to see if cyanogen mod is supported on your phone its lightyears ahead of any of the old versions of android filled with bloatware (touchwise sence etc). Not an add for CM or anything I just really like it.

Both my Galaxy Y With Gingerbread 2.3.6 and my galaxy Tab with Froyo 2.2 were vulnerable so I downloaded Dialer One and TelStop form the Play store. I already had Sophos AV obviously 🙂 I'll check my daughters LG Optimus tonight

USSD is the wrong term here. USSD messages are ipso facto transferred directly to the network and not interpreted by the mobile device. In fact the problem is SSD (structured supplementary service data), which is interpretable by the mobile device.

How very, very interesting. My Droid 4 is not vulnerable if I use Opera Mobile or Orweb v2. The dialer is simply never called.

But the dialer is called, and vulnerable, if I use Firefox Mobile, the stock browser, or the LastPass browser.

I did not expect this behavior to differ between browsers. Between devices, absolutely. But not browsers.

Avast! Mobile Security (the latest version from the market) protects me no matter which browser I use. Or even if I just hit the Phone button on Launcher Pro… which implies protection from the attack from non-browser vectors.

It seems that Avast! doesn’t integrate into the browser for this protection, but instead intercepts the launch of the Phone app and verifies the number before the dialer comes up.

If you wonder why I’m using Avast! and not Sophos… brand familiarity. That’s it. I respect Sophos, I love this blog, and I would research using Sophos Endpoint for business protection before even installing any other AV at work. But not for personal, non-business use.