Man hacks Android app to get free beer
Here’s a great one for a Friday afternoon: FREE BEER!
Actually, before we start, let’s make two things quite clear.
The man in the headline, security researcher Kuba Gretzky of Poland, isn’t a hacker in the pejorative sense of the word, and he paid for all the beer that was necessary in the course of his research.
(Before you get any ideas: he did this in his own time, so you will not find any hints on how to get this sort of thing through on expenses.)
Gretzky very nobly didn’t identify the app that he used in his article, but if you’re a mobile developer, that doesn’t matter, because the lessons are clear even if the app is anonymous.
Gretzky just referred to the app in question as EatApp, and we’ll do the same.
How secure is that?
Gretzky noticed that EatApp offered bars and restaurants a low-fuss, app-based way of using mobile phones in their loyalty programmes.
He wondered, as anyone interested in mobile security might, “How secure is that?”
We’re all used to those loyalty cards that the barista stamps every time you buy a ristretto, so that when you’ve clocked up ten coffees, the eleventh is free.
You’ve probably thought, “If I went to the stationery shop, I could buy the same stamp that he’s got and stamp my own card, so that’s not very secure.”
Indeed, it isn’t secure, but it doesn’t really need to be: the card only works in one coffee shop; the barista knows his regulars anyway; and the sort of person who would game the system for one free cup of coffee at his local would probably decide that it was easier and worth more just to steal the crockery instead.
But when you have an app that lets an account holder accumulate points across many venues, and then effectively spend them later, there’s a lot more at stake.
The risk of systematic fraud is definitely of concern if it’s possible for a crook to help other people to charge up their own accounts in private, and then redeem their ill-gotten gains all over town.
Gretzky’s article is an excellent tutorial of how to investigate the network behaviour of mobile apps, and worth reading for that alone (it’s like a HOW TO guide, but based around a real project, which makes it much more fun to read than a conventional user manual).
But here, we’re only going to focus on what he found out, why it’s bad, and how to avoid falling into the same hole as the EatApp coders.
Stamping the card
Very greatly simplified, Gretzky realised that EatApp’s digital equivalent of stamping your coffee card was based on the merchant, for example a barista, waiter, baker or chef – waving a dedicated Bluetooth beacon over your device.
That’s a similar sort of beacon to the ones we wrote about in a recent article about a Google project to to track you and serve you targeted ads.
The thing is, those beacons are stripped down to basics in order to keep them tiny, cheap and super-frugal on power.
Loosely speaking, all they do is identify themselves to you (or to an app on your phone) when you’re around; the app then calls home and says, “I just saw beacon XYZ at GPS co-ordinates LAT/LONG, what next?”
The idea is that the owner of beacon XYZ registers it with the back-end servers, for example by saying, “Today, beacon XYZ is in the men’s clothing department; if the user of the app that just encountered the beacon is a male aged 40-65 from Oxford who’s shopped with us before, message him to say we’re having a special on tweed jackets: 15% off, with free elbow pads.”
That way, the beacon itself doesn’t need reconfiguring every time, and it doesn’t need the sort of processing power and memory to deal with data specific to any marketing campaign.
The idea is that the beacon performs the same sort of function as a dedicated QR code sticker on the wall, or one of those “SMS this code for the time of the next bus” plaques that you often find on bus stops.
There’s a crucial difference in that the beacon is active, and pushes its details on you instead of waiting for you to scan it or type
The problem is that the beacon is a one-way device, just like the plaque at the bus stop: it tells you who it is, and that’s all.
And because the transaction is handled by an app on the customer’s device, the merchant doesn’t get a look in during the protocol, for all that it might feel that way because of the part where the beacon is waved near the customer’s phone.
And, as Gretzky points out, with a range of up to 70m, a Bluetooth “here I am” beacon isn’t terribly discreet about shouting its identity, so a crook might not even need to conduct a genuine transaction to get close enough to read it.
It’s even easier than cloning the barista’s rubber stamp: you don’t need to get a close look at it, and you don’t need to go to the stationery shop to find one that looks the same.
("Based on Gretzky’s article, we are assuming the beacon hardware tokens used by EatApp are iBeacons, Apple’s take on the Bluetooth beacon market that was launched in 2013. Each beacon emits a 128-bit UUID (universally unique identifier), a 16-bit “major number” and a 16-bit “minor number”, giving it a 20-byte identity marker. Google responded in 2015 with Eddystone, named after a famous British lighthouse, The technology is very similar, but Eddystones use a 128-bit UUID for a 16-byte identity marker."!)
What to do?
The dilemma here is that swiping a Bluetooth beacon over someone’s phone is a friendly and “frictionless” way to award them loyalty points for low-value transactions…
…but the protocol is so friendly and frictionless that it’s one sided, because the crooks can replay the data from the beacon over and over again, without you even realising, let alone getting a chance to prevent it happening.
If we were creating an app of this sort, we’d involve both parties in the process
For example, the merchant might choose a loyalty award from an app on his own device, which would connect to the loyalty award server and retrieve a one-time “award token.”
The merchant would pass the token to the customer’s app, which would bank it in the system.
Passing across the token could be done in any number of ways: by NFC (the technology used when you wave your phone to pay), by Bluetooth, by email, by QR code from screen to camera, or even by the merchant typing in a string of digits off his screen into the customer’s phone.
Using the unchanging beacon identity data as some sort of one-time code is definitely not the way to do it.
WhatsApp famously made this mistake in its first attempt at secure messaging, using IMEIs (electronic serial numbers programmed into every mobile phone) and MAC addresses (electronic serial numbers assigned to every network card) to create encryption keys.
IMEIs and MAC addresses are much like Bluetooth beacon UUIDs – indeed, UUID is short for Universally Unique Identifier – in that they exist for everyone to know, but only one person to use.
Don’t use a publicly-visible identification strings as if they were secrets.
