Here is an interesting topic, everyone uses QR codes - can they be malicious?
Aye, matey, there be QR codes that can tear the VPN out of your firewall like a shark going after a bucket o' guts!
I've taken to posting my details in a QR code on the first slide of my presentations, as:
Oddly, when people find out I am a malware researcher, nobody actually scans the code ...
@rsladethey could be a little cautious - especially I wonder that COVID-19 code will take me when I register at a shop? Does your QR code take people's devices to /dev/null or to the Dark Web to an obscure place?
How can we verify a QR safely without compromise?
Are there tools available in portable mode, so one does not compromise oneself?
The biggest issue I have seen with QR codes and for that matter link shorteners like bit.ly is that today they could go to a legitimate site and tomorrow they could point you to malware.
Be very careful....
I read recently that you can add a + sign to the end of a bit.ly link, and it will preview the link safely.
https://bit.ly/1sNZMwL+, for example (and it should point to the Bitly Wikipedia article)
Can't say the same for QR codes, however...
This subject has come up previously, now they are being used to entice people to scan for their parking meters, what is next Vaccine passports?
Well time has caught up and now QR codes are used for verification purposes on COVID-19 vaccine passports and many other items these days. They are now being exploited, so perhaps some practical ways to identify whether it is safe or not to scan?
I don't think we are going to avoid, this unless better means of verification and ensuring the QR Code is strictly limited and authorised via key management for instance and digital identity systems.
No, the code itself is not a threat. However, the QR app on your phone may be.
I see little risk in *scanning* the code. Fundamentally, a QR code is just a text string with a funky encoding. I can read anything without dying (buffer overflows not withstanding).
The danger comes about when the QR app decides to automatically take action after the scan... be that interpreting the text as HTML, opening a URL in a browser or passing it off to the WiFi Settings page. Before doing anything with the "input", it needs to perform a series of validation checks (highlighting oddball/risky characters, checking cert authenticity, showing the text to the user, etc.), only if everything looks OK and after the user authorizes the action should the input be passed anywhere.
Also merchants need to earn the customer's trust by using URLs with official hostnames and clear/concise/meaningful arguments. For example:
@denbestenInteresting point of view - however the action of scanning the code, most people automatically assume it will take them to the destination expected. We are lulled into a false sense of security.
So it comes down to the developers again, with good SDLC with security & privacy by design principles?
Who verifies and checks the developers or as most assume it is secure and trusted - security awareness to the fore again? There is no legislation to support this approach, although USA is thinking about it.
Trust, but verify - but often these are rushed out the door by the requestor i.e. organisation, government etc.
... the action of scanning the code, most people automatically assume it will take them to the destination expected....
Agreed. Pretty much the same problem as "homonym" URLS (e.g. chase-bank.com instead of chase.com). The first defense may be slowing bad actors from doing bad things, but that is not enough.
As I see it, the next step is Linus' Law -- "Many eyes make all bugs shallow". Omnibar search helps because it is curated (even if just crowdsourced). As I type a URL, it continually guides me to the popular (and presumably correct) site. We need similar "3rd-party" feedback during the critical moments after scanning a QR.
Beyond that, we can take steps to protect creds from homonym sites. Password managers are a great defense because they use the URL to look up the creds. If the URL is in its database, they autofill*. Since a homonym is not in the DB, it does not autofill. This altered workflow hopefully triggers that oh-so-important spidey-sense.
* "autotype" is a bit generous. I do have to click the little shield and potentially unlock the manager.