Are Android phones facing a remote-wipe hacking pandemic?

Is the sky falling?

Are Android phones about to be wiped off the face of the earth?

Will hackers be triggering a factory reset on your phone whenever they feel like it?

Are you going to wish you’d got one of those iPhone jobs after all? (No pun intended. Rhetorical question.)

That’s the worry going around since self-confessed Kiwi geek Dylan Reeve put a “test your mobile phone for imminent disaster” page on his website.

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:

As the text of RFC 3966 points out, unromantically but importantly:

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.

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.

(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.

–