At the tail end of last week, a couple of weeks after our post outlining the security vulnerabilities of the latest Estimote beacon firmware, the company contacted us to point towards the news of their latest firmware update.
As we’d summarised, Estimote uses a completely different beacon authentication mechanism and firmware for large scale deployments, and they have now pushed this alternative firmware out to all the developer kits.
The new 3.2 firmware release removes the previously used — and vulnerable — authentication service and characteristics, replacing it with a new service for authentication using an exclusively cloud-based API.
Looking at the new authentication scheme, the SDK reads the CLOUD_AUTH_CHALLENGE_CHAR characteristic from the beacon passing this value to a REST endpoint in the Estimote cloud. The server responds with a “beacon challenge response” which is written back to this characteristic by the SDK. If you then read the CLOUD_AUTH_LEVEL_CHAR characteristic a success value -1 (0xFF) is returned, and you are authenticated to the beacon.
Effectively Estimote have moved their fixed key scheme from the SDK, where it was exposed to anyone that had the ability to reverse engineer it, into the cloud where it is not so easily compromised.
This approach is infinitely better, but still not necessarily secure. As the debacle surrounding the Android master key proves, fixed key systems are inherently vulnerable to indirect attacks.
The question of how to recover beacons when the cloud service is down is an open question. You do have to wonder if there’s a back door in the firmware code to allow for this situation, if not then with the cloud service down you’ve got a piece of read-only hardware. But if there is, then you have another vulnerability.
There’s also the possibility of decompiling the new beacon firmware. While more time consuming, the authentication scheme can be found by doing so, as it needs to use the same algorithm as the cloud service to verify the challenge response. If the new scheme is ever reversed engineered this way, the attacker will be able to hijack any beacon running the new firmware release. Which begs the question, why didn’t Estimote opt for a user configurable password like many other beacon vendors have implemented?
That said, if you own Estimote beacon hardware, especially if you’ve deployed beacons into the wild running the developer firmware, you should download the iOS app (version 2.15.1), Android app (version 1.0.5), or the Estimote SDK 3.4.0 and update your beacon firmware to the latest 3.2 firmware release. It will significantly reduce the possibility of beacon hijacking.
Update: Jakub Krzych, the CEO and co-founder of Estimote, got back to us to say that,
As a point of clarification, we’re not using a fixed key system anymore: each beacon now has its own unique key, and the key itself is occasionally replaced (most importantly: just after firmware upgrade procedure as well). This key is stored in volatile memory, so decompilation of firmware wouldn’t help – the only thing that could be found there would be our encryption system based on industry standard algorithms like AES, which are not easy to break. Even if somebody managed to hack one of the beacons, it wouldn’t make it any easier to connect to any other beacon, as their keys are essentially random.
ADVERTISEMENT
