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