Beware the Hackable Google Beacons Made by Estimote

Manufacturers have been quick to pledge support for Google’s new beacon standard, Eddystone. But the rush to offer support may have consequences, as basic security considerations are being ignored.

In the wake of the Eddystone announcement, we’ve taken a deep dive into the Estimote SDK to investigate their support using the same sorts of techniques we used when we looked at beacons at the start of last year.

Why the Estimote? It is one of the leading beacon manufacturers and has been quick to support the new standard. Unfortunately, our analysis shows that it’s possible to reconfigure any Estimote beacon running their current developer firmware to broadcast an entirely different URL. The vulnerability allows you to update beacons you don’t own, and theoretically at least, are not supposed to have authorization to access.

Being able to push unauthorized updates to beacons in the field means that a physical version of the classic email ‘phishing’ scam is possible. And while we may be used to ignoring scam emails, scam notifications on phones are something new; apps and people who receive the notifications may be more easily taken in.

With Eddystone, we could well be facing a new and dangerous vector for malware.

The Eddystone Beacon Standard

Eddystone is a cross-platform, open source alternative to Apple’s iBeacon standard. Support is built into Google Play Services’ Nearby API on Android, with library support available for iOS.

As well as advertising a unique identifier, similar to Apple’s iBeacon, Eddystone offers a second type of advertisement, a URL. With Eddystone-URL, Google has effectively created a broadcast version of the QR code, one you don’t have to point your phone at. Instead, it can be passively consumed by everyone within range of the beacon.

The new URL “frame type,” as beacon services are called, is a lot more flexible than the standard frame type, which simply broadcasts a unique identity code. Since, instead of being a pointer to a back end database, uninterpretable by anyone except the company and the app that the beacon is associated with, a URL can be interpreted by any piece of software that can see the beacon.

As one of the first of the beacon companies to spring up in the wake of Apple’s iBeacon announcement Estimote was, unsurprisingly perhaps, quick to announce support for Google’s new standard.

The Estimote Beacon and Security

At the beginning of last year, while the Estimote beacons were in developer preview, we took a hard look at the Estimote beacon software and hardware and came away with the conclusion that their beacons were vulnerable to being reconfigured in the wild.

The implications of that were far-reaching. For instance, if someone maliciously changes the characteristics of an iBeacon, any consumer application configured to use that particular beacon will stop working — as the beacons must be configured with a pre-defined identity to trigger the correct behavior inside the consumer’s own application when their smartphone comes into proximity of the beacon.

In response to our security concerns we received the following response from Jakub Krzych, the CEO and Co-Founder of Estimote:

As you also know current version of beacons’ firmware doesn’t implement any beacon authentication method. It means that anyone can connect and change beacon’s settings. At the end of the day these are evaluation kits, so we wanted to ship them into developers’ hands as soon as possible…

…we are already running many real-world pilots and beacons configured for the commercial application use the industry standards like private/public keys to secure authentication and perform sophisticated UUID encryption algorithms to prevent monitoring and events hijacking or spoofing you mentioned.

The secure mode I mentioned…will be available in the new firmware version in approximately two weeks.

About three weeks later, Estimote released version 1.3.0 of its SDK, which somewhat surprisingly given the response we’d received, did not implement any increased beacon security.

However six months after that, Estimote released version 2.0 of the SDK, which did make some changes to their security model. The release notes had this to say:

Each and every beacon that leaves our high-capacity production line is automatically registered in the cloud and associated with its owner, based on the email and personal details we asked for during the purchase process.

With the new version of the Estimote app you will be able to detect all the Estimote Beacons around, but you can only connect to and configure the beacons you own.

Once you’ve authenticated within the app, you can access and configure all your beacons.

What this announcement means is that the Estimote SDK will check with their cloud service to ensure that your username, or application token, is associated with the beacon. That means, in theory, that you can only reconfigure a beacon using the SDK if the beacon belongs to you.

Unfortunately, the way the SDK talks to the beacon hardware itself was left completely unchanged. That means the same authentication process we reverse engineered six months previously could still be used to update the beacon, and no cloud authorization was actually needed or required to update the beacon.

However in March this year, Estimote released version 3.0 of their SDK, and the release notes say that it “…brings some changes to the beacon authorization procedure.”

Vulnerability Still There

Unfortunately the changes aren’t major, and it essentially still boils down to the same authorization procedure, but with a new fixed key being used. By using the techniques we utilised to hack the CES Scavenger Hunt, and peek inside their app, you can just as easily peak inside the Estimote Android SDK and extract the new fixed key.

Beyond that, if we look at the Estimote iOS SDK, and use a technique called method swizzling — which allows you to modify the mappings from a method name to an implementation, allowing you to “patch” methods in libraries where you don’t have access to the source code — it’s possible to remove authentication entirely by modifying the ESTBeaconCloud class to disable the cloud authentication check inside the SDK.

This allows you to update any Estimote beacon using their own SDK, whether you own the beacon or not. Effectively, the additional Cloud authorization in Estimote’s SDK does not add sufficient protection for their beacons. With this method, you can still update beacons in the field whether they belong to you or not.

This update also implemented what Estimote called ‘Secure UUID,’ in an attempt to thwart ‘false flag’ operations — where you discover the UUID of a group of beacons and build an application to hijack them en masse. Krzych has this to say on Secure UUID:

…one of the strongest risks behind production beacon deployments was a possibility that anyone can scan for beacons around, discover their UUIDs, and then build an app which can scan for the same UUIDs that could result in hijacking the user experience and pushing notifications from competing apps (e.g. ecommerce site could motivate you to buy goods online when you are inside beaconfied brick-and-mortar retail store). We have reduced that risk introducing last year Secure UUID.

Secure UUID does this by rotating the beacon’s UUID, requiring the SDK to look it up using their cloud service to resolve it to a “real” beacon UUID for the application. However due to the way in which beacons are registered with the operating system for ranging or monitoring, Secure UUID is limited to a small number of iBeacon UUIDs. A list of these UUIDs is shown below:

The beacon will rotate through 3 UUID + Major + Minor combinations when in Secure UUID mode, with the SDK querying the cloud for mapping to “real” UUID, and caching the results. Interestingly however, the Android version of the Estimote SDK doesn’t seem to support Secure UUID.

This technique is a somewhat similar tactic to that used by Qualcomm’s Gimbal, which used the trick of rotating the Bluetooth LE MAC address and advertisement data with each packet — once every 0.8 seconds — and as a consequence regularly crashed Android’s Bluetooth stack.

While using UUID rotations does prevent you from knowing the UUID scheme for a set of broadly distributed beacons, it doesn’t really prevent mimicking individual beacons. Since it’s all table-based lookups, you can still fake one advertisement rotation and trick the accompanying application in the same manner as before. It doesn’t change anything.

Which brings us to the present day.

Eddystone Support in the Estimote SDK

Following the announcement of Eddystone Beacon standard by Google, Estimote was quick to follow up with their own announcement of compatibility and the release of version 3.3 of their firmware and SDK.

Unfortunately there was no security update in this initial Eddystone release.

Looking inside the Android version of the SDK we do see some class names that might hint that a “real” Cloud authorization layer might be in the works. But it’s been a year and a half since our initial look at the Estimote security model, so the timescale for implementing that sort of additional layer of security isn’t clear.

However right now you can reconfigure any Estimote beacon running their current firmware — including ones not advertising themselves as ‘Eddystone’ beacons — into Eddystone-URL mode with an arbitrary URL.

The following code makes use of the Node.js bleacon library to do just that, and will discover all the Estimote beacons in range, and configure them to broadcast the ‘example.com’ URL, and it’ll do so whether they were originally in Eddystone-URL mode or not.

Being able to update beacons in the field, bypassing any authorization, opens up an alarming vector to spread malware and one that, at least potentially, the user may tend to falsely trust.

Scott Jenson, Google’s Project Lead for the Physical Web, had this to say,

Eddystone is a broadcast format that specifies what is sent over the BLE advertisment packet. If a beacon can be upgraded in the field (not all of them are) it is up to the beacon vendor to implement security. 

We also talked to Krzych again about the continued vulnerability we discovered and he responded that,

All the large scale production deployments utilize our new beacon firmware that enables factory-level beacon configuration synced with the cloud and prevents non-owners to re-configure beacons.

Which seems to imply that for bulk orders of their beacons the cloud authorization layer we see inside the iOS SDK may be already up and running, and that beacons in a production environment are being treated in a different way to the beacons they’re shipping to developers. Krzych went on to say that,

We also offer to our customers sophisticated cloud-based beacon network fleet management and monitoring tool where we report not only missing beacons, battery usage, but also misconfigurations. Since we keep the copy of all the beacons’ configuration in the cloud, beacons that are misconfigured are not only reported, but can be self-repaired simply by being in the proximity of users with compatible apps. That technology makes it really impractical for visiting different venues and hacking beacons.

Although it’s not exactly clear how this would work in practice as it takes a minute or two to update the beacon firmware — and you must be on site with proximity to the deployed beacon hardware to do that.

It also leaves some lingering questions for Estimote. If there are added security features in a separate bulk order build of the Estimote firmware, why haven’t they been merged into the developer version of the beacon? Further, is there an alternative version of the iOS and Android SDK to go with this firmware? Because unlike the iOS SDK, we see no mention of a cloud authorization layer in the Android SDK.

Why it Matters

The implications of being able to update beacons you do not own, if all the beacon transmits is a UUID, while annoying, were not catastrophic.

At worst you could carry out a Denial of Service (DoS) attack. By updating the UUID of the beacons deployed in the field you could stop the user’s application from recognizing them. Beyond that you could run a False Flag operation, changing the UUID of the beacons to be those of a competitor. For instance, you can imagine a scenario where, walking into one store, you’re told about the great deals in another store owned by a competitor by the store’s own beacons.

But, while the owners of the beacon hardware probably wouldn’t be impressed by this sort of hack, it didn’t really pose much threat to the end user. Being able to do this with a beacon broadcasting a URL is another matter.

With a URL it is much easier to trick a user into visiting a malicious web page, which could then automatically download and install a root kit onto their device.

Behind the scenes on your phone, the new Eddystone functionality is implemented by Google’s Physical Web project. This provides a Physical Web Service to fetch the title and description of a web page when a Eddystone-URL beacon is discovered — as well as cutting down the parsing the app needs to do, this service provides some anonymity between the user and the web server.

The Physical Web app is designed with safety in mind. On discovering a beacon, and looking up the metadata using the service, a passive notification showing that metadata is displayed. It’s only then, if the user taps through on the displayed notification, that the URL loaded into a web view on the device.

The Physical Web Service is integral to the scanning service in the Chrome app on iOS, and the Nearby Service on Android, which right now is the only way to detect Eddystone-URL broadcasts.

While there are no third party frameworks taking advantage of the new Eddystone standard, in the wake of Apple’s iBeacon announcement third party support for beacons on Android was quick to appear, so it’s possible that similar frameworks may also start to appear around Eddystone.

If such third party support does start to appear instead of using the Physical Web Service developers, for any number of reasons including laziness, it may open the URL directly and pull the data from the page directly into their code.

That’s bad, because in the past, zero day vulnerabilities have meant that just visiting a web page can be a vector to install a rootkit on your device. While this has been used for good by sites like JailbreakMe to provide an immediate one-step jailbreak for your iPhone, it’s equally possible to exploit this to root your handset.

That could mean that just by walking by an “infected” beacon, a root kit could be downloaded and automatically install itself on your phone. Although as Ktzych notes,

There is no app at the moment that automatically fetches Eddystone URLs and turn them into actions, so the attack you mentioned is not possible at the moment…from the practical perspective these hacks can achieve their goals only where the density of users with compatible apps is high. And in order to get there, apps must go through the App Store approval process where beacons’ misuse might be blocked.

At the moment at least this worst case isn’t possible. Hopefully developers will be sensible enough that if they’re going to roll their own scanning service, they also implement a metadata proxy similar to Google’s Physical Web Service.

Beacons Need to Be Fixed

Device-level security for the Internet of Things is a nightmare, and it’s probably going to get worse before it gets better. And due to their nature, beacons are particularly vulnerable to security exploits. Unfortunately, their integration into both the Android and iOS operating systems means they are also a target.

Ignoring basic beacon security could have far-reaching consequences, allowing not just widespread scattershot attacks similar to recently disclosed MMS vulnerabilities, but geographic and demographic targeting of malware against certain groups or even specific individuals. It is bad news for everyone.