Hello. I'm the guy who put this collection together. I've since tried to update it, and to hit 'delete' on it to avoid spreading misinformation, but Exquisite Tweets is still caching the original version. Mea culpa: I didn't do the research before passing it on.
There's been a lot of back-and-forth over whether it's true or not (check @pof's timeline for such), and a hell of a lot of people sending it on without double-checking. Myself included.
There is clearly a big security bug here (see the video linked), but it's extremely questionable as to whether it can be activated from a web page or whether it requires a bit of social engineering too!
[Edited to add: and just as I write this, @jwheare has cleared the cache and fixed the bug in Exquisite Tweets. Hopefully that should nip this in the bud.]
I tried reproducing it using a "USSD" that works on my venerable Nexus One (radio debug - * # * # 4636 # * # *), but on entering dialler app the input box is empty. This might simply mean the debug activity was started and got focus before the dialler app had its focus set, so if another such code triggered factory reset, might definitely still work.
I wrote a trivial webpage (using the show IMEI USSD * #06#), served from my desktop with Lighttpd. It certainly can be executed via a simple web page using a frameset on both Chrome & Browser, and there's no prompt. Works on a Huawei running 2.3, a Galaxy S2 running ICS, and an HTC.
1. Open the above link on your phone
2. Install the application (it requires no special permissions)
3. Try this IMEI test: http://jsfiddle.net/kKFn8/
4. Check the box to make "Auto-Reset Blocker" the default action
5. Auto-Reset Blocker will show you the malicious number
6. Open this safe telephone number test: http://jsfiddle.net/tLHpw/
7. Auto-Reset Blocker will show the safe number and you will be asked which dialer to use
8. Select your normal dialer
9. Your normal dialer will open with the safe number
Again, please give it a try. If people like it, I will see about setting up an Android Market account to distribute it.
I tested it with my S2 and it works, but I had to put the files in a local web server because for some reason, the malicious code didn't work from jsfiddle.net
So I did the following:
1- I tested the link provided by kristofferR (http://kristofferr.com/samsung.html).
2- Made 2 local copies
3- Edited one of the copies, replaceing the IMEI code with a normal phone number.
4- Placed both files in a local web server.
5- Accesed the files from my phone, and got the expected results with your App.
Works great. However, the immediate select app popup if it's "safe" means that the "This phone number appears safe" text is shadowed on my phone. Perhaps add a "dial" button?
Still, please set up a Market account, this would be great!
I don't have a Galaxy S3 to test this, but my experience with the Galaxy S and Galaxy S2 is that for normal phone numbers, you need to specifically confirm that you want to dial the number. For the code to factory reset the phone, though, simply typing in the code is sufficient, you don't need to press dial. It might be the same here, so that only that specific USSD code can be triggered without a confirmation from the user.
Yes, this is how it works. I tested a Galaxy S2 and HTC with Chrome and the stock Browser - both spawn the dialler and pass the code which triggers automatically on the terminating '#'.
The special feature of these "pseudo USSD" codes on Android is that you don't have to press the call button. Simply typing the digits is enough. Note I have no idea if this particular attack actually works.
This predates Android by years. Special "phone number" codes have been used to control firmware since the very first compute went into a phone. The reason is fairly clear: in the early devices, dialing a number was the only UI metaphor available. USSD itself is actually a standard, such as it is: http://en.wikipedia.org/wiki/Unstructured_Supplementary_Serv...
Now, of course, it's just a bit of legacy nonsense that gets left enabled simply because it's part of an existing workflow and serves mostly as a hidden gotcha for people doing security analysis.
In this case, the USSD is not the bug. The fact that it can be triggered from HTML and cause a factory reset without user interaction is the bug. At least with older phones, after entry, it was necessary to hit dial before any effect was taken.
That's true, but sort of missing my point. Security bugs are very rarely "security bugs" in isolation. They're far more often unexpected interactions between subsystems. Here, the expectation of the browser is that it can fire a "phone number" Intent securely, because the dialer app will handle it. But the phone number intent also happens to hook to the USSD layer. It's not USSD's "fault", as the check needs to be in the browser according to the architecture. But USSD remains a booby trap because it's an unexpected legacy feature with surprising security behavior.
I don't think it's "android feautre", I've seen this on a few non-smart phones in the past. I don't know which one though as I owned few of them over the years.
It's not the end of the world though. You're browsing on your android phone and suddenly it dials an unexpected number and you can see that it starts 900XXXXXXX or 976XXXXXXX. Most people are going to hang up pretty quickly. Sure, you might be out of pocket for up to $10 (I don't actually know how much mobile carrier charge for the connection charge), but it's not the same as losing all your data.
A more common attack vector to make money on compromised accounts would be setting up a call forward to an international number and then dialing the subscribers phone number. Illegal low cost calling cards often steal service by doing this. If there was a way to also retrieve the user's phone number, I can imagine a system where you dial the calling card company, input your code and the number you want to dial.... It tells you that it's trying to connect you and that it may take a couple of minutes... It snares the next person caught out on the website, sets their call forward to the number you want to dial, then dials that subscriber for you and connects. So then it's charging the wireless subscriber for your international call, and even if they then disable the call forward on their account, until you hang up, it's still charging them for the call forward.
If I was really bored and feeling malicious, printing QR codes to point to this "exploit" and then pasting them over QR codes on random advertisements in the streets seems like a terrible idea.
My 6 year old daughter is absolutely fascinated by QR codes. I've been nagged into scanning ones on posters, in magazines, and even one that showed up in the middle of a TV show...
I have a six year old son with this same fascination. Sometimes I'll walk into my home office and find some mailer with a QR code sitting there waiting for me. His inquisitive mind just has to know what the phone will do with the code.
I've got some somewhere, but I don't think they did QR codes and they certainly didn't launch a link - that's what she enjoys. No idea why, but I'm not going to discourage her from anything that gets her interested in technology. We're going to get a t-shirt printed for her with a QR code saying "If found, please ring [phone number]".
I do mountain bike (and thus indirectly hiking) trail development, construction, and maintenance as volunteer work. This has shown me a surprisingly useful place for QR codes: on trailhead map boards. The code just links to a (well optimized) PDF of the map itself, along with some text that says "Scan this with your phone to download a copy of the map.".
It amazes me how many people I see scanning the QR code to get a copy of the map before they head out on the trails.
I actually found them quite useful as a bookmarking tool when comparison shopping appliances at retail stores. They usually had code to the retailer's page for the appliance, and another for the manufacturer's page.
I was in a British train station the other day and saw a poster containing 20 QR codes, one for each of a set a possible journeys from the station. Since I'm techy and had time to kill I scanned it, waiting to see the timetable information. Sadly the company who installed the posters was having some downtime, so it just errored. The annoying thing was that they were really just a URL shortening company, forwarding you on to the correct mobile friendly page of the trainline website. I really don't know why the trainline couldn't have just made some nice short, typing friendly short URLs of their own, and posted these on the poster. Or just posted the actual time tables like they used to. In the olden days.
Whilst scanning it and trying to figure out what was wrong, the station master approached me to see what I was doing - since the poster had been installed he'd yet to see anyone use it, and had been waiting to ask someone what on earth it was for.
Still - if there is someone out there that wanted to hack me, they just have to place a qr code in a place where I am likely to have nothing to do for a while... At least with this poster it was actually easy to scan the codes, unlike those on billboards or posted on the tube here in the UK.
My local bus company has failed to grasp QR codes in a mind-bogglingly thorough way.
Every stop has a poster with a QR code on it, advertising that you can now look up when the next bus will be here by scanning the QR code. The first thing you might notice is that the poster is actually a photo of a QR code on a poster, and is taken at an angle sufficient to render scanning the QR code impossible.
The second thing you might notice is that all the posters are identical - they are, in fact, an advert for the QR code you are meant to scan and not the QR code itself.
So where are these QR codes? Somewhere else on the bus stop? On the post for the sign? No. Reading the smaller print on the poster reveals all: You simply visit their website on your PC and go to a specific URL, which delivers you a page full of QR codes. You then scan the QR code corresponding to the bus stop whose schedule you wish to view.
Maybe they got the idea from Google Code, which helpfully shows me a QR code for the tarball I'm about to download, for all those times I'm using the browser on my desktop and the IDE on my phone.
uh what? So I download the file, hash it, then pipe that into some program that's going to show me another QR code? And then eyeball that for differences? Who does that? I already have programs to compare two text strings, easily, accurately, remotely. Comparing two pngs is way more work. I was just assuming the QR code was the URL, but hash QRs make even less sense than my IDE on the phone scenario.
Actually, looking at the URL of the QR code image itself, it is for the download URL.
Lothian Buses in Edinburgh has done the right thing: they've stuck QR codes to each of their information signs, which direct you to the correct page on their mobile site, and the official Android app is registered for the URLs too.
The only semi-useful QR code I've ever seen in real life was on one of those little reminder cards in a parking garage to help you locate which floor you parked on. I say semi-useful because the QR code took you to a webpage that told you the same exact information the card had on it, and none of my friends or I could get reception inside the garage, so we all had to wait until we were out of the garage before figuring out what was on them.
I can see the usefulness of QR codes, but I don't think I've ever seen one implemented in a non-trivial or non-gimmicky way. They're a solution to a problem no one outside of marketing had.
I once saw a QR code advertised in a Buenos Aries subway station that was just a QR code and nothing else. No graphics, logo, or ad copy around it. So having some time, I scanned it. It was just text, not a URL. (I don't remember what the text said. But it was basically just "buy slurm!"
Seemed pointless to me. This is how the public interacts with QR codes - they can't do anything that can't be done by pasting TEXT where the QR code would be.
This sort of thing is common from what I've seen. More traditional businesses (like phone companies) don't know how to "do a QR code" (as it were), so they pay a company to make them for them. Such companies are just selling a glorified URL shortener, but the other businesses don't know that.
At FTF (Freescale Technology Forum) in 2011 at least (didn't go this year), used them on everyone's name tags and booths, so rather than passing out business cards, you used the iPod to scan them and it would send you a nicely formatted email along with the contacts for easy importing into whatever contacts you used. It was about the only time I felt they were done right.
And if you scanned the codes that were given in the different tracts, you were also sent the PDFs and slides of that tract.
Oh yea. If you paste an image into OneNote, it'll auto-OCR things and index them.
If you record audio into OneNote, it'll index the audio, synchronized to any other notes. I've used this on multi-hour meetings, to jump right to places where I think one party said something. Amazing.
COULD do that, or you could have all the information that they already submitted (it was more than just a vCard). I would rather not have to proof read all the OCR (there are hundreds of people at FTF)
The Heartland Developers Conference did the same thing this year. The QR code included more info than just the text on the badge so OCR would not have gotten the email address.
I would guess the opposite. QR codes are too early. They need to be scannable by a device that doesn't require reaching into your pocket, fumbling with your phone and then trying to get the right angle.
Combining a couple projections, I see them going from utterly useless to gimmicky cool for a particular crowd within 2 years.
Personally I think they would take off if we had some sort of large plastic dedicated device that plugged into your computer to scan these things. Perhaps shaped like a cat; people like cats.
Imagination. moe's got it. If as Brin suggests, Glass is available next year then scanning QR codes is one of the brain dead obvious launch apps for it. QR codes will be less variable and more reliable (under arbitrary conditions) than OCR at that point as well as being able to hold more information per square inch. They will be quickly translatable and displayed as human readable information floating in front of your face - with little to no effort required on your part.
The information density of QR codes is much higher.
In a few years many people will also be walking around with AR-glasses (e.g. google glasses) which may very well scan the codes automatically and overlay them in the viewport with whatever they want to represent.
This is pretty darn dangerous already, but I would note you may not need a website at all for this. From my understanding, the problem is in the stock dialer, and it automatically executes when the number is entered. I will quietly note here that, as part of the standard, QR codes can embed phone numbers. I do not have a samsung phone to test this with. Anyone?
Used a QR code scanner on http://qr.kaywa.com/?s=8&d=tel%3A%2A%252306%2523 (QR Code of tel:*%2306%23) - was picked up as a telephone number QR code by some barcode scanning app I have. Clicked dial number. Showed IMEI.
Check the html in your desktop browser first, for all you know I might as well be a malicious douchebag.
The exploit seems to require a stock Samsung Galaxy dialer, works fine on my cheap Samsung Galaxy Y but not on my friend's modded S3 with a vanilla Android dialer.
To people reporting that this works on other devices such as HTC phones, this doesn't mean your phone is vulnerable: First, the hash-star code to display the IMEI number is standard, while the reset code is device specific. Second, as I understand it the problem with the Galaxy S3 is that it doesn't ask for user confirmation after the reset code is entered.
Can anyone confirm that this is not only a safe USSD, but that it triggers the exploit? I am not an owner of a S3, but would love to be able to help show some of my non-tech friends whether they are vulnerable to this or not
I've tested this using both a galaxy S2 and S3. On the S2 the above page is safe and triggers the exploit to view the IMEI. On the S3 it launches the dialler however, the dialler is empty and does not display the IMEI.
After investigating further, the S3 does not launch codes that begin with * # but will trigger the factory reset code which is in the format of * 1234 * 1234 #
Edit: Those with an S3 can confirm this by visiting http://no.tl/s.html in which I've embedded * 1234 * 1234 # (which is not the reset code, but is the same format)
Works on a stock Galaxy S2 with Samsung ICS, and a random stock HTC (colleague's phone). Triggers IMEI display via dialer from both Chrome and Browser :(
The approach of prompting the user "Do you want to call this number?" is far simpler and safer. After all, you could probably use tel: links or tel: redirects or something if the frame didn't work.
That's a pretty big flaw, there's plenty of companies with QR Codes printed on posters etc, only takes one malicious reprint or sticker overlay. I imagine Samsung will probably take fast action on it. Well, hopefully fast action.
I have an S2, And I'm reading this from it. I was like "woow", then clicked the link that says "the code" instinctively and a sec later realized the stupid thing I just did (not smart reading that code from a vulnerable device). luckily, I pressed the back button before the page loaded.
As far as I can tell, the problem is with the Samsung Dialler application that's part of TouchWiz.
If you install a second dialler application via the Play Store, you'll initially be asked which dialler app you want to use before the code is executed - which can prevent execution.
There's a strong possibility that other dialler applications aren't affected (i.e. stock / 3rd party).
I just tested it on a Samsung Galaxy S3, in several forms (as src in link, script, img, video and object elements, as well as the href in an a element). Nothing happened here.
Hah! A friend of mine back in the BBS days had a last name that ended in a certain pair of characters that would trigger a zmodem download. Those were fun times, weren't they?
That is the modem hangup string. You could send a icmp packet to a person containing just that and their modem would drop the connection. So it was common in IRC for people to ping a whole channel with that and have a bunch of people quit right after.
IRC pings don't use ICMP, but that could work if IRC clients would repeat data received without escaping first. Or if unaware users saw it come over the channel and tried to type it themselves.
Considering a CTCP request is just a PRIVMSG with ^A wrapped around the "command word", and a CTCP reply is just a NOTICE with the same ^A thing, you can make them "say" just about anything. It's unclear why an IRC client would need to worry about "escaping" +++, except if it's specifically been designed for people with bad modems.
Those of us with good modems back in the dialup days just laughed at this insanity. Hayes used to put "+++AT" in their press releases after a certain point just to trip up any noncompliant systems which may have passed it along.
Sorry, I should have been more clear. The modem could also guard the sequence by requiring interstitial pauses, but I believe this was patented by Hayes in the 80s.
Indeed it was, as the referenced Wikipedia article notes; Hayes charged $1/unit for a patent license. As soon as the primary application of modems became Internet access, IP encapsulation protocols like PPP could have worked around the problem, but, AFAIK, never did.
Not a vulnerability, really. And the redial was a separate process, possibly automatic. (Edit: OK, yes it is. It's more a protocol vulnerability and a data handling weakness -- the modems just implemented the protocol, but that's just semantics.. )
+++ is the Hayes command set string to enter command mode. AT is the prefix for commands, and H0 means "set switchhook to zero", i.e. "hang up". (H1 means "go off hook", DT means dial using touch tones, DP means dial, using pulses, etc).
The first two components (+++ and AT) are configurable, but no one ever changed them.
This is really just a weakness of in-band signaling. For this to work, you need a human on the modem side to type the escape and command strings -- or a program on the modem side that takes unfiltered data from the network and sends it back out without escaping.
That's the vulnerability. Accepting data from untrusted sources will always take you somewhere bad, and there are much worse things you can do to modems than make them hang up. If IRC clients would parrot tainted data back up the serial line, great havoc could be caused.
This is for real. Just confirmed the auto-execution of an USSD code on a Samsung Galaxy Mini II. Try the link below to see whether your device is vulnerable:
Works with my HTC Desire if I use the info code, the dialog for showing battery status etc pops up.
Raises interesting consumer protection questions, this is a 2010 phone with no updates recently. The law says the dealer has to fix or make up for manufacturing defects that show up years later.
Are software defects considered manufacturing defects?
BTW, read elsewhere that if you are using the Chrome browser instead of the Samsung browser this doesn't affect you. Haven't had the guts to test it myself.
I've just implemented this as a Rack middleware, meaning it can be added to every page in a Rails/Rack app with 3 lines of code. A bit of hacker fun, albeit scary hacker fun.
Classic case of a developer putting a backdoor in (for testing) and forgetting to take it out. I'm curious as to how long it will take to patch it and if there will be any fallout over this (they are the number 1 phone producer in the world).
The page no longer works (I clicked it about 30 seconds ago, it loaded successfully then I accidentally hit ctrl-w and then tried to reopen it: and now I get "404 Page Not Found")
Does this trigger a confirmation dialog before typing the number? if not, installing another app that hooks up the dialer intent should work as a workaround.
Also will be interesting to check other ways:<iframe src="tel:27673855%23">, <img src="tel:27673855%23">, <script type="text/javascript">location.href="tel:27673855%23";</script> and so on.
iFrame works, direct link too. I tested also things like URL encoding via # = %23, * = %2A etc. - but does not really matter, the target is the dialer, not the browser.
There's been a lot of back-and-forth over whether it's true or not (check @pof's timeline for such), and a hell of a lot of people sending it on without double-checking. Myself included.
There is clearly a big security bug here (see the video linked), but it's extremely questionable as to whether it can be activated from a web page or whether it requires a bit of social engineering too!
[Edited to add: and just as I write this, @jwheare has cleared the cache and fixed the bug in Exquisite Tweets. Hopefully that should nip this in the bud.]