Your Beacons Can Be Hijacked (If You Don’t Do It Right)
Estimote beacons can be ‘hacked’ and coders with malicious intent could change the advertising packet data in the devices. If the devices were being deployed on a large scale the exploit would mean that the beacon you put up in your store could, in theory, be changed and made useless – or even worse, made to work for your competitor’s app instead of your own.
While at first glance this might seem to put iBeacon technology at risk of hacks and exploits, the news should be put in the context of two larger observations:
- While Bluetooth LE might seem like a simple thing to deploy and use, it will quickly fall to developers with advanced expertise to do it right
- Estimote is not yet a production-ready product and is still classified as a developer kit. The company has yet to release its security measures, cloud control panel, or full specifications around security, connectivity and pairing. So the beacons shouldn’t be evaluated based on the reverse engineering of a developer preview device.
Depending on the use case and security requirements, developers will put in place monitoring, layers of security and device-specific measures that are appropriate to the use case being explored.
Take the CES Scavenger Hunt – an iBeacon event that’s getting a lot of attention because of its association with the major consumer electronics show of the year. Here’s a use case that doesn’t need a lot of security – it’s meant to be fun, there’s not much at stake, and giving some backdoors to industrious coders might not be such a bad thing.
But the same authors also ‘hacked’ the CES app – completing the Scavenger Hunt without even getting on a plane to Vegas. Hardly a world-breaking security issue and actually of a completely different nature from the Estimote work.
Understanding The Estimote Vulnerability
But the news about Estimote will inject a note of caution into those who believe that the popular beacons are ready for mass market (rather than a developer preview). Following a long description of how they reverse-engineered the beacons, the authors concluded that:
Whilst the Estimote developer preview kit and SDK are still in their early stages if Estimote sticks with their currently security model—although there are signs that they might not do that—anyone who creates an application using their SDK will be able to reconfigure any Estimote Beacon in the wild.
The implications of that are fairly far reaching. If someone maliciously changes the iBeacon Major or Minor characteristic of a beacon, any consumer application configured to use that particular beacon will stop working—the beacons must be configured with a pre-defined identity to trigger the correct behaviour inside the consumer’s own application when their smart phone comes into proximity of the beacon.
Beyond that you could configure a “fake” beacon to act as an impostor of another beacon belonging to a retail chain, potentially gaining access to promotions, gift cards and other location dependant goodies tied to the beacon you’re impersonating.
While Estimote was arguably the first Bluetooth LE beacon company to ride the wave of publicity surrounding Apple’s launch of iBeacon, there seems to be a new beacon coming out every week. Estimote’s advantages have led to a rich ecosystem of 10,000 developers playing with the turtle-shaped beacons.
This has given what I think is a mistaken impression that Estimote are ready to act as a prime time beacon solution. Until we see their security protocols, management tools, back-end dashboards and (not least of all) pricing for all these services, the beacons are still just fun things for developers to play around with.
Its what Estimote does next that’s important – not how secure their beacons are today.
iBeacon and Bluetooth LE: Steps We Need To Take
There is significant misinformation and misunderstanding related to iBeacons. There are perceptions, for example, that beacons:
- Somehow deliver “content” such as coupons or videos (they don’t)
- Because they deliver content, someone can hack your beacon and send your app content that you weren’t expecting (they can’t)
- That beacons are somehow “secure” out of the box
- Or alternatively, that all beacons are somehow insecure – which I suppose is true to the same degree that ALL technology is to some degree insecure
The trick to beacons, like any technology, is to develop solutions where you build layers of security that are appropriate to your use case. In theory, if you were looking to develop a highly secure transaction system, for example, you’d probably want to use things like a fingerprint scanner (like Apple has deployed) along with multiple layers of authentication and monitoring.
But run a scavenger hunt at a local festival and I doubt you’re going to want PIN and fingerprint authentication – you’ll build a solution appropriate to the use case.
Sonic Notify Gets Real About the Challenges of Deployment
We reached out to Sonic Notify to get their take on some of the security challenges with beacons. Their experience in deploying both Bluetooth LE and audio beacons extends well past a few months of work into millions of transactions delivered and thousands of beacons deployed. We thought they’d give us some good insight into how experienced developers are deploying beacons.
Aaron Mittman, CEO of Sonic Notify, commented on their experience with the issue:
We have given much thought to security. For the last two years we have refined this very issue. With our Secure Beacon solution, the major and minor values (aka payload) of our transmission changes frequently. The payload is encrypted to obscure reverse engineering the major and minor values.
Securing the UUID is much more difficult (as has been seen in the case of Estimote). Its is true that the UUID is open and must be searchable by the application. Advanced beacon solutions will need enterprise caliber CMS functions to coordinate changing UUIDs over time. Not to say that servers are uncrackable, (see Snapchat for the latest example) but the task of securing a server is much better understood.
Aaron suggested that the Sonic Notify approach to security will likely be echoed by beacon makers (and perhaps by Estimote): a randomly timed encrypted payload that changes (i.e. the advertising packet cannot be easily read) and a synchronized rolling UUID and payload (i.e. more secure because it’s partly server based).
We expect to see a similar deployment by Estimote when it comes time for them to release the “production ready” version of their beacons.
The CES Scavenger Hunt Solved: And It Hasn’t Even Started Yet
The same folks who “cracked” the Estimote also took a look at the Scavenger Hunt for the Consumer Electronics Show, a beacon-powered app that’s getting a lot of press, and which they managed to complete not only before the show started but without even getting on a plane to Vegas.
While at first glance it might seem like a major exploit, there actually isn’t much news here: the application file wasn’t encrypted, and so the ID numbers of the beacons were easily found and spoofed. The app was developed by Core Apps of Maryland.
Radius Networks provided technology to support the beacons. We reached out to them and David Helms responded:
The most important thing to bear in mind is that when developing proximity solutions, the security model employed has to be appropriate for the application scenario. In many cases a minimal security model is appropriate if the assets at risk are minimal or if you have other compensating security mechanisms in the supporting systems.
For other scenarios, a more stringent security model may be required, but you always have to balance the cost and complexity against the solution requirements. When deploying Bluetooth Low Energy proximity solutions you always have to bear in mind the inherent risks of man-in-the-middle interception, device spoofing and untrustworthiness of the mobile devices participating in the solution and including compensating security mechanisms in the supporting systems to address those limitations.
Where some see an exploit, I see a super clever winner: sure, they might not have gone to Vegas, but they’ve managed to not only promote the channels at the CES but have had some fun seeing if they could game the system. And, being a game, what’s the harm in that? If this was some kind of super secure banking application I’d be worried – but it isn’t, and it seems to me like the ‘security’ was appropriate to the use case.
And that’s the point: the use case will inform the approach to security.
But what we need to clear up first is confusion about what Bluetooth LE is, how to secure it, what “secure” really means, and how to manage and monitor beacons once they’re in the field. If these sound like tasks you can do on your own or which you can trust to a brand of beacons that don’t have a ton of market exposure yet, then more power to you.
But where this gets really exciting is that it makes us aware that there’s a deep level of expertise needed to get any new technology “right” – and so these early stories and reverse engineering efforts are a reminder of how much fun (and sure, how many sleepless nights) we’ll have as we connect up a world of beacons.
Let’s Have a Discussion
Throw your comments and questions into the discussion below – I’d like to hear what you think, what impression this gives, and what questions you have about Bluetooth LE and iBeacon security. What do you think? What worries you? Let’s discuss.