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
