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.
55 comments on “Are Android phones facing a remote-wipe hacking pandemic?”
FWIW, I just went to that test site using a Windows 7 phone and saw the same dialogue as when I went to the site using an Android phone… are Windows phones vulnerable too?
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.)
I have sophos mobile security on my galaxy nexus, but it did not prevent the code from being executed. Installing the telstop app did, however.
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…
Yes, it did just come up as a number. I wasnt able to dial it either, and it took a bit to be able to get rid of it off the screen. So yes, you are right, whilst it does come up, it isnt vulnerable.
I tried it on Sybmian 3, it complains about invalid phone number which means it was actually processing it.
Entering the code on my iPhone resulted in the phone's MEID being displayed (iOS 6).
On my Wildfire running 2.2, using the Opera mobile browser, the IFrame did not render. But if I click the link, I'm vulnerable.
For some reason, the Telstop app is coming up as incompatible with my phone, so I'd be interested to hear of any good workarounds!
G'day folks – please let us know in the comments whether your OS/browser/dialler combo is vulnerable or not. We've already got varying answers for Android 4.1, Windows 7 and Symbian 3 (see above). Would be fun to know what you found.
The weirder the combo, the better…
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.
iOS6 appears to bring up the MEID so it is dialing the number automatically
Really? You don't have to hit the "call" button or something first?
Not on mine it doesn’t. It opens a prompt with *#06# shown, and the options to Dial or Cancel. It doesn’t display the actual phone ID though I’m sure it might if I went ahead and clicked Dial.
I have just run the test using Firefox for Android on my HTC Desire S (Latest available firmware), and I got the IMEI popup so I am vulnerable.
I installed the TeleStop app, which appears to mitigate the problem.
I am now off to raise a bug against Firefox for Android, as they clearly ought to be filtering such urls.
I have filed bug 794383 against Firefox for Android.
Answer is going to be – not a bug.
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!
I agree the first port of call ought to be the dialler, however I can't see HTC rushing out a fix for a device that has been in the market for nearly 2 years, and is now discontinued.
Even if they do get a fix out, then I doubt the manufacturers of all affected phones will do so, or the networks will approve those fixes and push them over the air to affected end users.
Firefox on the other hand have a rapid release cycle. If they choose to, they can get a fix out in a few weeks, and protect the majority of their users within a couple of months.
OK. Get your point. I imagined an element of criticism in your words "clearly they ought to be filtering such urls."
Perhaps you meant that "they may as well filter such urls because the handsets aren't getting around to it."
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.
HTC Desire HD
Customer Sense 3.5 Rom
Automatically loaded the IMEI number not good
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).
SE Xperia Ray +
Android 2.3.4 +
stock browser +
On Orange in UK =
SE have released Android 4.0 (ICS) for this phone months ago – but Orange are taking their their sweet time releasing the update … don't know if that will fix it or not.
Tried this using a Nokia Windows Phone 7.5 & it displayed the code but prompted to call or dismiss it so I guess I'm safe.
Blackberry 9780 with system software 6.0 Bundle 905 – same result as @Duncan on his Windows 7.5.
Dialog pops up saying "Call *#06#?" and offering [Call] or [Cancel]. If you [Call], then it processes the USSD and the IMEI appears.
Not willing to see what happens if I put a heavier-duty USSD command in the iframe 🙂
HTC One XL
IMEI window popup.
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.
Please read my reply to @George Gummer above…
Sophos Mobile Security scans download apps for malware (amongst other things) but isn't a URI-checker.
That's why I carefully advise you to get some other app to protect against the "tel:" thing, and _then_ promote Sophos Mobile Security just as an app scanner.
Apologies if it was unclear. (If Sophos Mobile Security could block the tel: URI I'd have mentioned it right at the top of the article and said, "Sophos Mobile Security can block the tel: URI" 🙂
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 🙂
HTC Desire A8181
*#06# called and IMEI displayed.
Windows XP SP3
Microsoft Lync 2010
*#06# appeared in a Call window, user interaction to complete call though.
On my Samsung Galaxy II with ICS 4.0.4 the IMEI number is automatically displayed.in a little window with OK.
Using a Droid4 with a custom ROM I tried with the native and Dolphin browsers and the IMEI appears. Using the Roboform browser error displaying the URI.
My Droid X running it's browser on Android 2.2.1 was vulnerable. I installed Telstop and it worked
Chrome browser – popped the imei with an ok button.
Windows Phone 7.5 on Samsung Omnia 7
Pops up with a dialogue asking me to edit the phone number and offering call or cancel buttons.
Safe, but worrying
Samsung Galaxy Nexus
Visiting page popped up the dialler with *#06# entered.
Tapping Dial gave an "Unknown Application" popup.
On my Samsung Galaxy SII, with Android 2.3.3, the inbuilt browser dislayed the IMEI but when I went to the site using Opera, it was blocked.
Samsung Galaxy SIII
OS: CyanogenMod version 10-20120926-NIGHTLY-d2vzw
Browser: Dolphin Browser version 8.8.2
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.
I should note that the stock browser exhibited the same behavior as I noted in my previous post: namely that the dialer appeared by the IMEI didn’t.
That is the correct "fixed" behaviour bill. It was listed as an issue in andorid 2.2 and has been fixed in 4.1 (which CM10 is based on)
Galaxy s2 running Cyanogen mod 10, displayed the code in dialler but hitting call just got an error hurray for android 4.1
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.
Rooted HTC Desire
Visiting web page immediately displayed IMEI number with an OK button. No option to cancel. Clicking ok displays number keypad. Telstop fix works.
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
Huawei Sonic from Woolworths with Android 2.3.5 is vulnerable.
Installed "Auto Reset Blocker" from the google play store which blocks it.
Also running Sophos 🙂
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.
Do my eyes deceive me or is the article reported today on the BBC news website not the same thing?
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.