Ash Allen

The Fortessa FTBTLD smart lock is a fairly bog-standard type of generic smart lock, sold in the UK by CEF for around £100, and available on auction sites for maybe 3/4 of that price.

As can be seen on the sticker on the left hand portion of the lock above, it is configured with a default device name. The lock offers a variety of features, such as auto-locking, key sharing, and so on, and in the main they work pretty well. It’s never going to win any beauty awards, and the app interface is pretty basic, but in the main it does what it sets out to do. Unfortunately, however, there is an issue with the lock allowing unauthorized updates to config parameters that mean it should not be used anywhere outside of the lab.

The tool of choice for this investigation is HomePwn, an IoT testing suite developed by a group of Spanish researchers. It provides a similar interface to Metasploit, and is able to work with a number of different protocols such as BLE and RFID which means less switching between tools.

Loading up the Bluetooth Low Energy discovery tool, we can see that amongst a bunch of other devices, our Fortessa lock is detected (2nd from the bottom):

We can then look to run the read-characteristics tool, with the various options laid out like so:

We can then use the discovered MAC address of the lock, and the local BLE adapter, like so:

Running the command then returns the following (abbreviated):

Note that at this time we have not had to authenticate, and that is correct; the companion app needs to be able to read these fields. However, this particular service is set to READ WRITE. In general, again, this is not necessarily an issue; it may be perfectly reasonable for an unauthenticated user to write to a particular BLE service. In this case, though, the lock name is likely something that we would not want just anyone updating. Unfortunately, that is how the devices is configured. Using the ble/write-characteristics plugin, we can update the lock name without authentication, like so:

Checking again with the ble/read-characteristics plugin, we can see that the device name has been updated:

It should be noted that you don’t need to use HomePwn to do this; something like the nRF Connect app will let you do this from your phone.

So, what’s the big deal? Your neighbor may be able to give your door lock an obscene name, but this can’t do any damage, right? Right?

Well…

Once the lock name is updated, the app refuses to connect, as seen below:

In fact, it will refuse to connect until the power to the lock is cycled by removing the batteries. If you are locked outside of your house, because the battery compartment is on the inside, you can see the issue! I have reached out to the distributor and manufacturer with this finding, but have had nothing back. Whether this can be patched in a firmware update, I can’t say. It seems like something that would be pretty easy to fix, but who knows. For the moment, though, if you have a Fortessa lock, remember to take your keys with you as well…

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).

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 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.