Jump to content



Photo

Are Android phones facing a remote-wipe hacking pandemic?


  • Please log in to reply
18 replies to this topic

#1 Haggis

Haggis

    Neowinian Senior

  • 2,755 posts
  • Joined: 13-June 07
  • Location: Near Stirling, Scotland
  • OS: Debian 7
  • Phone: Samsung Galaxy S3 LTE (i9305)

Posted 26 September 2012 - 08:42


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 doesn't actually remote-wipe your device without permission. He just shows you if it might be possible. 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.

There's a special sort of telephone number URI, detailed in RFC 3966, which can be used like this:

Posted Image

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 just 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 were to 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. It's automatic: you're not actually making a call, so the green button isn't needed. Some diallers warn you that you're on the verge of triggering an in-band signal - and give you an out-of-band way to prevent it, which is handy - but some do not.

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.


Source: Naked Security



#2 Nick H.

Nick H.

    Neowinian Senior

  • 11,818 posts
  • Joined: 28-June 04
  • Location: Switzerland

Posted 26 September 2012 - 09:24

Aren't they overplaying the problem a bit in this article? I thought the issue was specifically with TouchWiz?

Anyway, just tested the website on my S3. The first time I got asked which dialer application I wanted to use. Once I had set a default dialer and tried the site again, the dialer appeared with *06 ready to dial, but it was waiting for me to push the call button. I guess that means I'm safe from this particular attack?

Anyway, Android won't crumble because of this. Now that it's public knowledge I'm sure someone will find someway of officially stopping this kind of thing from happening.

#3 OP Haggis

Haggis

    Neowinian Senior

  • 2,755 posts
  • Joined: 13-June 07
  • Location: Near Stirling, Scotland
  • OS: Debian 7
  • Phone: Samsung Galaxy S3 LTE (i9305)

Posted 26 September 2012 - 09:33

yeah bound to just be a way in the software to make it by default wait for the call button to be pressed no matter what is typed in

i will try mine soon lol

#4 Simon-

Simon-

    Neowinian Senior

  • 10,724 posts
  • Joined: 04-November 02

Posted 26 September 2012 - 09:40

It is not a remote attack, requires user intervention to go to malicious page

#5 OP Haggis

Haggis

    Neowinian Senior

  • 2,755 posts
  • Joined: 13-June 07
  • Location: Near Stirling, Scotland
  • OS: Debian 7
  • Phone: Samsung Galaxy S3 LTE (i9305)

Posted 26 September 2012 - 09:45

It kinda is because if that sites link that initiates the wipe thus its being done remotely

Balls

not just Touchwiz

my phone is a custom sense rom and it displayed the IMEI directly

#6 ichi

ichi

    Akihabara Style

  • 5,011 posts
  • Joined: 20-December 04

Posted 26 September 2012 - 09:48

Are USSD codes somewhat standard for all phones on all carriers?

I tried the exploit with the IMEI code, it didn't work but then even if I actually pressed the call button it would just throw an error about "invalid USSD code".

#7 OP Haggis

Haggis

    Neowinian Senior

  • 2,755 posts
  • Joined: 13-June 07
  • Location: Near Stirling, Scotland
  • OS: Debian 7
  • Phone: Samsung Galaxy S3 LTE (i9305)

Posted 26 September 2012 - 09:51

not sure if for all phone but it is a standard RFC 3966

#8 OP Haggis

Haggis

    Neowinian Senior

  • 2,755 posts
  • Joined: 13-June 07
  • Location: Near Stirling, Scotland
  • OS: Debian 7
  • Phone: Samsung Galaxy S3 LTE (i9305)

Posted 26 September 2012 - 10:01

Remote USSD Attack - Prevention

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 2: Samsung is not alone in being vulnerable to this issue.
Update 3: An app has been created specifically to catch these URL calls, if you don't want to install another dialer: TelStop (by @colimrm)
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.




I have uploaded a test page to my webspace as the one above is very slow

It will display your IMEI number if your dialer is exploitable

http://haggistech.co.uk/USSDtest/

#9 ichi

ichi

    Akihabara Style

  • 5,011 posts
  • Joined: 20-December 04

Posted 26 September 2012 - 10:02

not sure if for all phone but it is a standard RFC 3966


"tel" URIs are a standard, but I don't think the USSD codes you'd be using to exploit this are. I haven't tried many codes but *#06# (the USSD used on the exploit demo that shows your IMEI) is definitely not working on my phone.

I don't know if that's because of the phone model or because of the carrier.

#10 OP Haggis

Haggis

    Neowinian Senior

  • 2,755 posts
  • Joined: 13-June 07
  • Location: Near Stirling, Scotland
  • OS: Debian 7
  • Phone: Samsung Galaxy S3 LTE (i9305)

Posted 26 September 2012 - 10:26

just in case anyone wondering this is the html for the site i uploaded just so you know nothing dodgy lol

<html>
<head><title>USSD Exploit Test</title>
</head>
<body>
<p>If your phone is vulnerable to the recently disclosed tel: URL attack then this website will cause your phone to open the dialler and display the IMEI code. With other USSD codes it could do any number of other things, including wipe all phone data.</p>
<p>You can find some more information and a simple workaround here: <a href="http://dylanreeve.posterous.com/remote-ussd-attack">http://dylanreeve.posterous.com/remote-ussd-attack</a></p>
<iframe src="tel:*%2306%23" />
</body>
</html>


#11 firey

firey

    F͎̗͉͎͈͑͡ȉ͎̣̐́ṙ͖̺͕͙̓̌è̤̞͉̟̲͇̍̍̾̓ͥͅy͓̍̎̌̏̒

  • 8,071 posts
  • Joined: 30-October 05
  • Location: Alberta, Canada
  • OS: Windows 7
  • Phone: Android (4.4.2)

Posted 26 September 2012 - 12:13

tested on my phone a custom CM10 rom with 4.1.1. Put *#06# in the dialer box, but it didn't call and when I tried to dial said it was an invalid code.

#12 ShMaunder

ShMaunder

    Neowinian

  • 1,045 posts
  • Joined: 15-December 06
  • Location: Wiltshire, UK
  • OS: Ubuntu 12.04
  • Phone: Nexus 4

Posted 26 September 2012 - 12:29

Motoblur with Atrix 4G on Gingerbread is dialling the IMEI code automatically.

#13 Boz

Boz

    Neowinian Senior

  • 7,480 posts
  • Joined: 21-October 03

Posted 26 September 2012 - 12:36

It's already fixed by Samsung.. so add this one to the garbage bin of all Android doomsday crap.

#14 OP Haggis

Haggis

    Neowinian Senior

  • 2,755 posts
  • Joined: 13-June 07
  • Location: Near Stirling, Scotland
  • OS: Debian 7
  • Phone: Samsung Galaxy S3 LTE (i9305)

Posted 26 September 2012 - 12:40

If you bothered to read some of the comments and actually research it you will find its not been patched fully

People with the latest S3 firmware are still reporting it working

#15 Boz

Boz

    Neowinian Senior

  • 7,480 posts
  • Joined: 21-October 03

Posted 26 September 2012 - 12:45

https://twitter.com/...591062480003072

http://www.engadget....-vulnerability/

and btw, there are apps that prevent this in case you are not on the latest fixes

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


So the workaround is found and those who are not patched will probably be patched soon.

I was just referring to the whole doomsday headlines not that the problem doesn't exist.