In a previous post I discussed the Bluetooth pairing issue that means anyone with a sniffer and access to your lock can open it. However, this is not the most concerning aspect of the device. I’m a big fan of static analysis tools, and use a few when investigating IoT devices; they generally provide useful starting points for further investigation, and so it proved here. In this instance, MobSF produced a report that pointed at a couple of insecure Firebase databases (I’ve redacted some of the information below to casual readers from investigating further; of course, it is perfectly possible to recreate exactly what I have done. I have tried reaching out to the manufacturer on a number of occasions regarding this and the Bluetooth issue but have had no response).
eGeeTouch Firebase Databases
Digging down into the data returned from the URL, I had the (mis)fortune of finding my own details, captured as I tested the lock (redacted, although of course the above applies).
The author’s information
The information captured includes the GPS coordinates and approximate address of where the lock was accessed, the time of access, the email address of the user, and whether the device was locked or unlocked. Nowhere in the EULA is it stated that this information will be collected. Aside from why this information is stored at all (I’m assuming some sort of audit trail), it is clear that this represents a severe privacy intrusion. Not only is the device collecting personally identifiable information (PII) about the user, but it is storing it in a location that can be accessed without requiring any authentication. PII, of course, is subject to GDPR regulation in the UK and other, similar restrictions elsewhere in the world. This would seem to be, then, a significant concern for anyone tempted to buy the lock.
IoT security devices, such as smart padlocks, need to perform at least as well as their non-smart counterparts if consumer trust is to be gained. Unfortunately, many such devices are fundamentally flawed, with poor design meaning they are simple to subvert. Once such device is the eGeeTouch 3rd Generation Travel Padlock.
The eGeeTouch 3rd Generation Travel Padlock
Available in the UK for £19.90 from Amazon, the lock boasts a number of features, including Bluetooth operation via the companion smartphone app, RFID tag support, and a TSA manual override. So far, so good. However, digging deeper, it is clear that the device should be used with extreme caution. Access to the device is handled via a password set in the app:
eGeeTouch app – password management screen
This password is required when initially pairing the lock with the app; without that the two can’t talk to each other. Setting the password to 080379, we can then look to see how the lock communicates with the app, and vice versa. To do so, we can use btlejack, a Python tool that leverages the Bluetooth LE chipset in the BBC micro:bit development board to hijack the connection and dump the output to a Wireshark format dump file (download it here). Looking at output from a successfully captured session, we can see the following in packet 78:
Authentication capture
The capture indicates a write to the 0xfff8 attribute of the letter a plus our secret code, 080379. The lock then replies with a range of other information, for example the Model Number in packet 89 :
eGeeTouch model number
and the firmware revision in packet 92:
eGeeTouch Firmware
Triggering an unlock event via the app sends the following (packet 95):
Unlock event
whilst a lock event sends the following (packet 101):
Lock event
It seems clear therefore that the operation of the lock, at least via the companion app, is controlled by these three commands; an initial authentication, followed by the relevant lock or unlock code. All three use the “secret” code that was set in the app. How much access can we get knowing that?
The app is currently logged in using the following account:
User account
Let’s then log out and try signing up with a brand new account:
Attacker account
Logging in, we can see that no devices are currently registered:
No devices registered
Clicking the Add Lock button brings up the following:
Lock choice screen
Select the correct device and we are asked for the pairing password. Enter that and:
Success!
The user now has full admin rights over the lock, including, crucially, the ability to change the pairing password and so lock the legitimate owner out. No notification is provided to the original user that their password has been used on another account, so they are none the wiser that the lock is compromised.
The exploit relies on the attacker having the ability to capture the data flowing between the device and the companion app. There are a number of different ways of doing this in addition to the btlejack method; for example, the image below identifies the same back and forward communication as in the PCAP, though in this case it was captured using the Gattacker tool:
Gattacker output
The attack does require a small amount of contact with the device, amounting to a push of the power button on the side of the lock. In a busy environment such as a railway station or airport it is not an impossible obstacle to surmount. In short, the eGeeTouch Travel Padlock should be passed over if you are looking for a reliably secure device.
I will be returning to this lock in a later post, as there are a number of other serious issues that greatly impact its desirability as a consumer product.
