Scanning random QR codes is surely the cyber equivalent of eating random things you find on the pavement. It's another way to weed out the stupids so the rest of us can flourish.
How a QR code can fool iOS 11's Camera app into opening evil.com rather than nice.co.uk
A security researcher based in Germany has identified a flaw in the way Apple's iOS 11 handles QR codes in its Camera app. Last year, with the launch of iOS 11, Apple gave its Camera app the ability to automatically recognize QR codes. Over the weekend, Roman Mueller found that this feature has a bug that can be used to …
COMMENTS
-
-
Tuesday 27th March 2018 09:14 GMT big_D
The problem is, there are so many legitimate QR Codes around these days.
Almost every meat product in Germany has a QR code which can trace the source of the meat back to the farm it came from, for example. The same for a lot of bio / organic foods, there are QR Codes to give tracking information about the goods and where they originated.
A lot of posters have QR codes on them to help you automatically visit the advertiser's site.
Going into meetings, there is usually a QR code printed for automatically setting up the Wi-Fi connection (at least for Android).
Business cards.
And QR codes were originally invented for inventory tracking in the 90s by Denso.
So, lots of legitimate codes laying around.
When I have to put in a warranty or service claim on a server, I generally zap its QR code in the server room and mail it to myself, so that I have its details, when I return to my desk.
That said, you have to be careful. About 6 or 7 years ago, an InfoSec group went round a security conference and replaced the QR codes on many posters with one pointing to their website to point out just this sort of problem. It is amazing how many people fell for it, considering it was a security conference!
I tried the given link on Android, BTW. It recognized it as http://xxx as the domain.
-
Tuesday 27th March 2018 16:26 GMT Nate Amsden
Maybe more common on Europe, at least for me in the U.S. they are really rare. I remember now that I used one as an e ticket for entrance to a show in Las vegas recently, but other than that I can't remember the last time I interacted with one(in that case the QR code was being scanned by the venue, displayed on the phone screen). Possible they are printed on more paper tickets(99% of the time for something that needs a pass I go paper), and I just don't notice them.
I have a bunch of HP servers but don't recall them having QR codes on them. Not that I can easily scan them anyway(after installation) as my server room is a colo that is 3,000 miles away. Org I work for maintains common Wifi account info across offices, certainly no QR codes on meeting rooms.
I have spent 4 months in SE asia in the past two years or so as well, QR codes seemed a bit more common there but the locals I never saw the locals I was with ever using them. One exception would be adding a "friend" on the LINE chat program, the app can display a QR code that the other person's phone can scan to add.
This is of course excluding 3D bar codes like those used by UPS, Fedex etc, which I think the technology is similar don't believe they are QR codes(they certainly don't look the same).
Maybe I've scanned a half dozen QR codes in the past 7-8 years. Have been reading about security issues WRT to QR codes for probably the same amount of time or more.
QR sounds like a really neat idea though if deployed more widely+securely. Or maybe they are and I just don't notice them.
-
Tuesday 27th March 2018 10:27 GMT Mage
Random codes
I don't like URL shortners for this reason.
I use a separate barcode scanner app (Android) with no adverts and it previews everything. There are usually two or three options what to do with the code (displayed) as well as fact it simply creates a tab for Firefox, and only if an option selected.
-
Tuesday 27th March 2018 07:36 GMT Anonymous Coward
QR codes were never cool
You had no idea where the QR code would take you (much like those short URL's...). You could end up on a Child Pron site and then face time in chokey for your troubles.
I've never scanned one and never will. The same goes for short URL's. Yes, I know that there are ways to check them but life is too short to do it everytime.
Like Facebook, QR codes are well past their use by date.
-
Tuesday 27th March 2018 09:15 GMT big_D
Re: QR codes were never cool
QR codes were cool and very useful. They are mainly for inventory tracking purposes and they have also replaced stamps / franking of business letters, for example.
There are dozens of commercial uses for them that make a lot of sense and make them very useful.
Using them for websites was an unforeseen side-effect.
And when you scan a code, you are always presented with the deciphered information and, at least on Android, given a list of options of what you want to do with it - set up a Wi-Fi connection, add the contact information to you Contacts, send the link as SMS or E-Mail, open the website, depending on what sort of QR code you have scanned.
Also useful for server serial numbers, when the kit is hidden in a rack and you don't have a pen and paper handy...
-
Tuesday 27th March 2018 10:20 GMT Jason Bloomberg
Re: QR codes were never cool
The problem is not with QR codes themselves but scanning software which automatically takes people to malicious sites or performs some adverse action when scanned. It is effectively an 'auto-run' issue.
And compounded, as in the example here, when where the QR link actually goes is hidden.
-
Tuesday 27th March 2018 14:48 GMT Anonymous Coward
Re: QR codes were never cool
The problem is not with QR codes themselves but scanning software which automatically takes people to malicious sites or performs some adverse action when scanned. It is effectively an 'auto-run' issue.
Problem is, even if asked "are you sure you want to visit evil.com?" many users will click Yes. That includes your auntie and the "digital natives" (who have no concept of security)
-
-
-
-
Tuesday 27th March 2018 08:24 GMT Steve the Cynic
"...This leads to a different hostname being displayed in the notification compared to what actually is opened in Safari."
And this is the least comprehensible part of the whole sorry tale. Why in the name of Dog do they not use the *same* piece of code in both applications? There's this mysterious technology that might help them, called "libraries", where you can call exactly the same compiled code from two different programs. Maybe someone should tell Apple about that.
-
-
-
Tuesday 27th March 2018 08:55 GMT illuminatus
For info
I'm using the latest iOS 11.3 beta on an iPhone X
I've just tried creating a QR code url of this form
https://xxx\@www.dur.ac.uk@tees.ac.uk/
resulted in the camera asking if I wanted to 'open uk@tees.ac.uk in Safari'
Opening the URL takes you to: https://tees.ac.uk
So it looks as if a fix of sorts is in place for the 11.3 release, though I'd agree showing the full URL is probably a far more sensible precaution.
-
-
-
Wednesday 28th March 2018 13:35 GMT Frank Bitterlich
Re: For info
The "port" part (":443" or any other number) is essential for the flaw to happen.
The location where it appears makes it, technically, a "password" (http://user:password@domain.org), but it makes the flaw see this as a port number and so the NSURL sees the whole fake domain part as valid.
-
-
-
-
Tuesday 27th March 2018 09:18 GMT Anonymous Coward
QR codes are almost as much fun as shortened URL's
I received an important email from "Chase bank" yesterday that had official looking logos and a handy hyperlink embedded in it to help me log in.
I copied the hyperlink with Notepad and of course it was just an http shortened URL.
I dropped the shortened URL into urlscan[.]io and saw that the company that shortened the phishing login page link had flagged it for violating it's terms of service but for some unknown reason the bank had not been notified and the site was still up.
https://urlscan.io/result/b9ec0b7d-b780-489a-b533-117fc16312e2/#summary
-
Tuesday 27th March 2018 10:48 GMT Anonymous Coward
Re: QR codes are almost as much fun as shortened URL's
I got one from Wells Fargo yesterday. As I don't bank with Wells Fargo I simply deleted it and moved on, but it did look pretty official and probably a lot of Wells Fargo customers would click on it without thinking twice.
Unfortunately the scammers are getting smarter, but the chances of the average web surfer getting smarter don't look too good.
-
-
Tuesday 27th March 2018 09:29 GMT Dan 55
goto fail;
Technically, the example URL is problematic because the backslash character while valid is considered "unwise," according to past RFCs. The recommendation is that it should be escaped or percent-encoded, which is to say represented using the characters "%5C" in place of "\".
[...]
The issue lies elsewhere, in the way Apple's software handles the initial "@" character. It's not clear exactly where this bug lies – because the relevant Apple code isn't open source – but the notification display mechanism and Safari handle the URL string in a different way.
The problem is that the escape character (\) isn't recognised as such in the camera display so the next character is treated as normal. If you gave it a URL with the escape character replaced with two backslashes or a %5C, you'd have much the same problem in Safari too.
Why no system library for normalising URLs, Apple?
-
Tuesday 27th March 2018 14:29 GMT ThomH
Re: goto fail;
It's more a question of why Apple isn't using its system library for normalising URLs. I suspect that whomever wrote the camera application is on the same spectrum as those people that feel the need to write their own ad hoc date-handling libraries.
-
Tuesday 27th March 2018 17:04 GMT Robert Carnegie
Re: goto fail;
I believe a legitimate URI format is:
protocol://user:password@host:port/url-path
although who puts user name and password into a URI now??
(I cribbed this from the Wikipedia page on FTP, so maybe: people who still use FTP.)
So that seems to be another part of the problem here, but I don't fully follow it.
-
Tuesday 27th March 2018 21:03 GMT Deckard_C
Re: goto fail;
Back in the day this was used to obscure dodgy links in scam emails. Make the username part look like a domain the password the port. Most people used to assume the username was the domain not the bit after @.
Of course these days most people using the internet don't seem to have a clue of what a domain is in a URI. You probably get plenty of hits with saying
click on http://scam.me/ to reset your Office 365 account
even from those who don't have a Office 365 account. This is based on the number of times I've had to say that's a scam email because you haven't got a Office 365 account.
-
Thursday 29th March 2018 19:21 GMT Michael Wojcik
Re: goto fail;
I believe a legitimate URI format is:
protocol://user:password@host:port/url-path
The "user:password" part is called "userinfo", and is part of the authority portion. See RFC 3986, section 3.2.1.
(The "protocol" is actually called "scheme".)
We've known for at least 14 years that userinfo is a problem for poorly-written URL parsers and for users. RFC 3986 actually deprecated the "username:password" form of userinfo - technically userinfo consists of "a user name and, optionally, scheme-specific information about how to gain authorization to access the resource" - and warns that userinfo should be presented to the user in such a way as to make it more difficult to use it to obscure the actual resource authority. That was in January 2005.
Thirteen years later, Apple still isn't complying with that recommendation. That's what happens when you let app developers write their own versions of common system components. It's the sort of thing that should be caught in security design review.
-
-
Thursday 29th March 2018 18:30 GMT Michael Wojcik
Re: goto fail;
The problem is that the escape character (\) isn't recognised as such
Backslash has no special meaning in the authority portion of a URL. (Or in any other portion, for that matter.) It should not be interpreted as an escape character.
This is a stupid bug on Apple's part, period. We've known about issues with the userinfo portion of URLs for more than a decade - the earliest CVE I found for one was 2004 (CVE-2004-2597; a good later example is CVE-2008-0409). There's no excuse for not having a single implementation in the OS that parses URLs correctly.
-
-
Tuesday 27th March 2018 11:26 GMT Lee D
Sigh.
Cause: Failure to correctly parse untrusted input.
Fault: Whoever wrote the Camera app.
Same old story, it doesn't matter what junk they give you about "it's a secure device, we do X, Y and Z", they never, ever, ever parse untrusted output properly.
And fail in the most trivial of ways possible. It's not like some complicated overflow, it literally doesn't parse the URL correctly and consistently despite it being THEIR OS and THEIR libraries and THEIR app on THEIR hardware.
Another one to add to the bookmark folder entitled "Yeah, but my Apple device is more secure, right?" that I bring out whenever someone brings that nonsense up.
-
Tuesday 27th March 2018 12:25 GMT JeffyPoooh
Can backspaces (^h) be embedded into such codes?
If you can pack backspaces into strings (typically from outside your IDE's GUI, where backspaces tend to simply backspace live), combined with suffixed decorative comments, then you can pretty much totally separate what strings appear to be and what they actually are.
I've previously described how, many decades ago, I was able to pack BASIC code with backspaces and REMs, with the following (example) result:
LIST
10 PRINT "No No No"
RUN
Yes Yes Yes
The general concept probably has wide application even today.
Would it work on URLs and QR Codes?
-
Tuesday 27th March 2018 15:56 GMT Robert Carnegie
Re: Can backspaces (^h) be embedded into such codes?
I'd like to say no. I don't see a reason to recognise backspace in parsing a URL.
But I won't fall off my chair if in fact some system is vulnerable to this.
Very basically, if a simple parser app operates by typing the URL into Safari character by character - your bug may work.
I think more than one bug has used the international text handling that legitimately makes writing go right to left instead of left to right because some written languages work like that.
-
Thursday 29th March 2018 19:27 GMT Michael Wojcik
Re: Can backspaces (^h) be embedded into such codes?
I'd like to say no. I don't see a reason to recognise backspace in parsing a URL.
But I won't fall off my chair if in fact some system is vulnerable to this.
Such a system would not be conforming to the URL specification, if that's any consolation. The code points that can appear unencoded in a URI are specifically listed.
Backslash isn't allowed in IRIs either, but there we have the much more problematic issue of homographs - Unicode code points that (in most fonts) are indistinguishable from one another. Most of the popular browsers try to alert the user to homographic substitution by displaying IRIs in punycode encoding, though Firefox and its derivatives notably do not, by default.1
And even then we have to trust that a user looks at the address bar, sees the punycode, recognizes that something is up, and does not attempt to use the site further. That's far from certain.
1Mozilla's official position on this is that it penalizes users whose native language includes non-ASCII characters, and who would therefore like to use IRIs and see them rendered in a readable fashion. That's a reasonable argument, but it leaves all their users vulnerable to homograph attacks.
-
-
-
Tuesday 27th March 2018 13:50 GMT AndrueC
but the notification display mechanism and Safari handle the URL string in a different way.
"Well there's [part of] yer problem."
If both pieces of software are written by Apple why aren't they using a common URI parsing module/library? Of course a single implementation can still be wrong but code duplication is never a good idea and inconsistency of results is part of the reason why.
-
Tuesday 27th March 2018 14:38 GMT Frank Bitterlich
The problem may be bigger...
I just did a quick test, and it looks like Apple's NSURL class generally has that problem of not getting the host right. Using NSURL -URLWithString:, the backslash version doesn't work at all - and the one with the percent-escaped backslash produces the wrong hostname when calling NSURL -host, namely: facebook.com.
This is bad.
-
Tuesday 27th March 2018 17:36 GMT NomadUK
Only mostly sucks, not totally
Interestingly, it seems that, if one uses the Camera app directly from the desktop, the resulting dialog does display the full URL at the bottom (this is with iOS 11.12), so one can see that it's a dodgy URL (by dragging down on the dialog). But if one activates Camera from the lock screen, it doesn't.
Unfortunately, the displayed URL is also accompanied by a view of the destination URL, which rather obviates the point of displaying the URL beforehand. So, not all that brilliant.