Are Android phones facing a remote-wipe hacking pandemic?


Recommended Posts

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:

tel-uri-eg-500.png?w=494&h=33

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

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.

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

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

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/

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.

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>
[/CODE]

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

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.

Its nice to see that the Apple users and fanboys dont need to come here to bash and take-over an Android security flaw. I wish Android fanboys learn a bit with this and behave better in future in Apple topics.

Nice that Samsung secured that, every system has flaws the trick is to acknowledge and secure them fast enough.

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.

My AOKP 4.1.1 (are they still based on CM?) does the exact same thing. Guess we're safe for now.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Simple answer is yes, you will still get the Windows updates and as long as browser is up to date, you will be good. Only thing secure boot does is protect you against boot level threats and make it harder to install other OS's. I've been looking into this pretty thoroughly lately myself as wifes computer has secure boot disabled plus my other, older computers that run Linux, don't have secure boot enabled. Have seen all kinds of questions about this on the Linux Mint and MX Linux forums. Just don't suddenly enable secure boot now.
    • How many other companies will follow Ford's lead? Or, have they already gotten lazy and become enslaved to AI--and now can't figure out how to get out of that mess.
    • Why would any self-respecting intelligent person follow any recommendation by Donald's GOP administration? With almost two years of fabrications, deceit, and blatantly illegal behavior, why believe them now? They had best be gone after the November 2026 election, so we'll wait and see.
    • AltSendme 0.4.1 by Razvan Serea AltSendme is a minimal, cross-platform application designed for fast, secure, and private peer-to-peer file transfers. It allows users to send files or entire directories directly between devices without relying on cloud servers, accounts, or any personal information. Everything is encrypted end-to-end using modern protocols like QUIC and TLS 1.3, ensuring both strong security and low-latency performance. Transfers are verified with BLAKE3 for data integrity, and interrupted downloads automatically resume, making the experience reliable even on unstable connections. You can transfer anything—images, videos, documents, and more. Integrity checks are performed on both ends, so your files are automatically verified for correctness during both sending and receiving. AltSendme works seamlessly across local networks or long-distance links, capable of saturating multi-gigabit connections for extremely fast delivery. With built-in NAT traversal and encrypted relay fallback, it connects devices almost anywhere. The app integrates with the Sendme CLI and will soon support mobile and web platforms. Fully free and open-source, AltSendme offers a lightweight, privacy-first alternative to traditional cloud-based services, removing size limits, upload costs, and unnecessary data exposure. AltSendme 0.4.1 changelog: Release Highlights Self-hosted relays: Run your own iroh relay so transfers don't rely on public infrastructure. Includes a full deployment template in deploy/relay/ with Docker Compose for a VPS and configuration examples for production use. Fly.io support: One-click deploy template for Fly.io, including a quick-start config (fly.dev.toml) for testing without a custom domain, plus production setup with Let's Encrypt and your own hostname. Relay settings UI: New Settings → Network panel to choose how AltSendme connects: automatic public relays, custom self-hosted URLs (with optional auth token), or disabled. Test connections, verify latency, and see live relay status in the footer. Disable relays: Turn off relay servers entirely when you only need same-network transfers (e.g. LAN). Direct connections only. No relay hop required when devices can reach each other. Android graduates from beta: Android is now part of the regular release cycle alongside desktop. APKs ship with each version (universal, arm64, and armv7). Other improvements Private relay access control via shared auth token Relay fallback notifications when a custom relay is unreachable Broadcast mode toggle in sharing settings Android release build fixes (split-per-ABI APKs, universal APK preservation) UI polish: mobile safe-area insets, dropzone layout, transfer progress animation Bug fixes for minification-related serialization issues and system tray icon loading What's Changed feat(relay): add relay status functionality and settings UI (a120cdf) feat(relay): implement custom relay server configuration and verification (51276c7) feat(relay): add configuration for private relay access and enhance observability features (48fbabf) feat(relay): enhance relay URL validation, display connection status (d4fffa0) feat(relay): add RelayChangeGuard component and enhance relay-related translations (16ba514) feat(broadcast): add toggle setting for broadcast mode in sharing UI (ca6d977) fix(relay): correct QUIC discovery port, pin image, templatize fly.dev (52a2ba5) fix: More broken serialization due to minification (67491a9) fix(android): preserve true universal APK across per-ABI builds (e9f256f) fix(ui): conditional safe-area insets padding on mobile (1182f0e) refactor(transfer): CircularRing component animation fix (944572b) chore(android): drop x86 and x86_64 release APKs, keep universal+arm64+armv7 (34ada0b) Download: AltSendme 0.4.1 | ARM64 | ~9.0 MB (Open Source) Download: AltSendme for MacOS | Android Links: AltSendme Home Page | GitHub | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • You are mostly right about the ephemeral nature of it. As I mention in the article, if you dont add a second device or take a backup of your account before uninstalling it, then yes you will lose access to your account. That said, in terms of actual user experience when you sync multiple devices your message history carries across and there's also a Saved Messages chat like there is on Telegram to send messages and attachments between your installs. But yh, what you point out are correct and its not trying to emulate Messenger or Telegram.
  • Recent Achievements

    • Week One Done
      flexorcist earned a badge
      Week One Done
    • One Month Later
      Woland13 earned a badge
      One Month Later
    • Week One Done
      Woland13 earned a badge
      Week One Done
    • One Year In
      bernmeister earned a badge
      One Year In
    • Week One Done
      Scoobystu earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      495
    2. 2
      +Edouard
      225
    3. 3
      PsYcHoKiLLa
      149
    4. 4
      Steven P.
      75
    5. 5
      FloatingFatMan
      71
  • Tell a friend

    Love Neowin? Tell a friend!