Hacker News Reader

All of those could be done much more stealthily server-side, though, I don't get what the QR code modification would add here? Also, neither use case makes use of the hack described in the OP. Where I could see an attack based on that hack would be where an attacker plasters their code over a legitimate one. It would be kind of random which code gets read, so they could send some %-age of users to the original destination, hence possibly delaying detection. But it doesn't seem a given that this would compensate for the reduced traffic to their link.

Some sort of MITM attack by someone who owns the display but not the server, maybe. Like a malicious ad company.

Ok, but then I'd still prefer a method that sends users to a unique URL. OP's method may help with obfuscating the changing of the code, but I'm sure there are ways to better achieve that without having to introduce this quasi-randomness. The simplest would probably be to just to regularly hide/show the code (which would happen anyway on a typical digital ad display that cycles through a number of ads).

But hypothetically, the owner of the ad might pop in and make sure

1. the ad looks correct, and

2. the URL is the one they expect

So there may be a use case for a QR code that looks almost identical but goes somewhere else, allowing them to swap it out while someone is looking at it without them realizing.

A niche use case, to be sure, but being able to exploit a niche vulnerability is a skill.

But if you own the display, you can send the user to whatever server you want.

> All of those could be done much more stealthily server-side, though, I don't get what the QR code modification would add here?

Even if the adversary controls the server side as well, you need to tell the server the information needed to make a decision If you control everything that is easy enough too, but perhaps you want to keep the decision-making process local – for plausible deniability server-side, just to reduce server & bandwidth load, or because you are sending people to completely different destinations not just altering link parameters.

Replacing the QR code more statically sends everyone to the new address, not just the target(s), altering the QR code by a bit or two (and the relevant error correction bits too) in response to a pile of information available at the QR reading site (feeds from cameras, and such) would be how the server knows to react differently without having access to that collection of information itself. You might want to use some clever analysis to minimise the visual effect if you are altering the QR code while it is already displayed – the two examples here look very different, but the change could be much more subtle. If sending to very different destinations, so the codes for the URLs will look very different, then adding a link anonymiser between would keep the change minimal.

> Also, neither use case makes use of the hack described in the OP.

True.

There are actually attacks based on changing public QR codes already!

They don't need anything as sophisticated as this dual QR code, though - the attackers just go to a car park with a "pay by phone" sign, slap their own QR code over the "scan to pay" code, and wait for the credit card details to start coming in.

Hmmm, there might be some criminal utility in capturing <100% of visitors, so that the true owner doesn't easily realize that activity for that location has ceased. In other words, giving up a certain number of victims in order to keep the attack going for longer.

That said, it'd probably be easier to implement that in software, where the phishing site redirects a certain portion of visits back to the legitimate one.

P.S.: There's also the physical stealth aspect, but I think a lenticular design would probably be easier for a human worker to notice, compared to a regular flat sticker which just happens to encode a typo-squatting URL.

I almost got taken in by a fake parking ticket scam, perfect ticket/envelope, the url printed on the ticket led to a 404 on the legitimate city website, the QR code led to a very convincing website/url, especially on mobile.

The only reason I caught it was that I had gotten a legitimate ticket a month prior for parking too close to the fire hydrant and had marked the curb with chalk at the correct distance. So I tried to dispute the fine and discover that the ticket didn’t actually exist. And the city had no interest in the fake ticket whatsoever. They were just like “yeah, it happens all the time”.

I guess similarly you can carefully craft a poster with a QR code and put it on a wall in a room with two LED bulbs. The bulbs will have different color temperature and the decoding will be dependent on which bulb is lit.

Another idea would be a poster that's not quite flat: Each pixel that is different is slightly raised (pyramid shaped) and the sides of the pyramid is colored differently. So the QR code scans differently from different sides.

One of the dominant banks here in Tbilisi allows sharing of IBAN number as QR codes. In theory, the trick could be used to steal money, but in practice, there are many safeguards such as the banking app displaying the name of the beneficiary before completing the process.

> banking app displaying the name of the beneficiary

and the scammer make an account with a name that look similar at a glance (e.g., swap the l with a 1, or something of the sort).

Most likely, they have <1s bank transfers, too, like pretty much all of Asia. That way, if you pay someone with a QR code, they'll immediately get the notification that they received your payment. And if they don't, you immediately know that something went wrong.

But then it’s too late, you have to find out before send the money.

Most scammers will try to avoid situations where you can punch them in the face. => If scams usually get notified before the perpetrator can run away, that will discourage scamming. => In practice, it might be "good enough" if you know immediately after sending money.

you could use glossy/matte or metallic finish, then the reflected light could appear brighter than the white parts

> alters the QR code based on information it has about the current user, without appearing to change significantly.

I doubt many people would notice if your average QR code was to change significantly. Most machine readable formats are just indistinguishable white noise to most people.

I appreciate you laying out malicious use-cases instead of just having the setup section; I would have struggled to think of those!

FWIW the place my brain went was some kind of magic trick, since having control of this could function kind of like a forcing a specific card or something

Static a/b testing?

> pretend to offer some form of probabilistic chance to win a prize, but bias winning to some identifiable characteristic. e.g. race, age, "beauty"

Do a facial recognition lookup against the RealID database (I'm sure someone must be selling a leaked or hacked copy by now) and make the prize depend on the first letter of the person's last name.

Identifying this should be relatively easy in the core libraries; finding alternate valid QR codes using "less optimal" grids.

Of course the API confusion here becomes non-trivial, which hampers securing against it. And with existing libraries being widespread, its going to linger as an attack for a long time.

You don’t need any of this if you control the app doing the scanning (or the website/app handling the result).

You wouldn't control the app doing the scanning.

The attack is that a user looking at a QR code cannot determine that they are being served a different code to another person.

In a public setting a user would have no idea they are even capable of being targetted and treated differently.

You don't even need to change the QR code to treat users differently, that's the point. You just send users to some fixed URL, which is by far the most common use for QR codes (hence completely unsuspicious), and you decide who gets served what there, based on whatever data you gathered about them. And the users that would care are already acutely aware that that's how a majority of the web works nowadays, QR codes or not.

The value of an attack vector is not negated by there being other ways to achieve it.

This particular vector has the strength of being able to manipulate things other than URLs; QR codes support WiFi credentials, contact details, call, text (with content), email (with content), calendar events. Additionally, many app specific URIs never leave the device.

It has the significant downside of being plainly visible as a possibility to those in the know.

However, I suspect it may still be desirable to do this on the device rather than the server.

The other properties it varies are the obvious lack of reliance on a server. The improved "transparency" of showing the target URL for trust. The removal of the need for an internet connection.

But for an implementer I'd imagine the most beneficial upside is not needing to manage a timing-attack, and gaining additional targetting accuracy in the common case of a picture. There may also be organisational complexity reduction in pushing all the decisioning to the display/camera system.

Its fun to think about, with the significant weakness in both its visibility and its probabilistic nature I wouldn't expect widespread use.

Static Qr-Code but serve different content? If you are targeting by the camera, you can try to link the person to the time the QrCode was scanned and have each QrCode print identified.