The Bluetooth smart lock which spoke too much

The Bluetooth smart lock

A few years ago, looking for something fun to do, we stumbled upon what seemed to be a nice Bluetooth Smart Lock on Amazon. It was controlled by a mobile application (Android or iOS), supposedly compliant to lock anything (from your scooter to your dungeon’s cave) and cost around 30€ with possible refund without any question asked. We thought this could be a nice project to look at its security, especially at the communication level.

Android application main screen

First thing first, we have to register the device and set up the app. To do this, you have to wake up the lock by pressing a button. It then waits for incoming connections. Using the mobile application, you create an account on the vendor’s website and then send the default password (000000) to the lock. And that’s it! You’re done! You can now do anything: change its password, query log information (with dates and location), rename it, etc. We set our lock password to 123789.

Communication analysis

The communication is based on Bluetooth 4.0. We used BlueFruit LE Sniffer to intercept it, and Wireshark/tshark to display the capture.

We recorded the communication when we opened the lock with its password. The frame analysis enabled us to spot precious information: our password value in hexadecimal: 0x01E38D. The command delivering the password to the lock is likely to be identified: 0x554101E38D7B.

We can quickly identify the frame sending the password.

We examined the frames after this one, and found a potential candidate for the command opening the lock: 0x55100144.

The frame opening the lock.

We did this multiple times and each time the password was sent in clear and the opening command was the same. It seemed to us that no cryptography was implemented at the communication level. This allowed us to replay the frame sequence to authenticate and open the lock, or pair another mobile with it since we can intercept its password.

Well, that’s it! If we come back to our analogy with physical locks:

• Opening it with cutting pliers lets an obvious sign of a break-in, while we can open the smart lock without leaving any trace.
• Another option would be to lockpick it, but it requires skills, and above all if someone sees you, it is difficult to say that you are the legitimate owner. The smart lock communication can be sniffed cheaply within a few meter range. So, it can be recovered quickly without drawing attention.

As we were a little disappointed by this part, we then analyzed the Android application, desperately looking for a security mechanism we would have missed.

Android Application

The Android application shares the same level of security. The analysis is straightforward:

• There is no anti-tampering or anti-hooking mechanisms,
• The code is not obfuscated,
• The protocol can be easily inferred, and it confirms our previous observations.

Method to build the authentication command.

Thanks to this code, we can now translate the data in the frames we identified earlier:

• 0x55: REQUEST_ID
• 0x41: COMMAND_AUTH_PASSWORD
• 0x01E38D: PIN
• 0x7B: Checksum

And, the second one to open the lock:

• 0x55: REQUEST_ID
• 0x10: COMMAND_OPERATE_LOCK
• 0x01
• 0x44: Checksum

The code analysis confirmed our hypothesis with the sniffed frames. So, crafting and installing a malware targeting the password thief is straightforward.

I can see you coming! “Meh, just another IoT device with no security!” But that’s not all, folks! Just out of curiosity, we went a little further and checked the communications with the server. And oh my! We were not disappointed!

Server Privacy Data Leakage

Indeed, if we continue to analyze the application, a simple logcat gives a lot of information, especially two URLs:

• http://XXX/list
• http://YYY/getLogs

A chatty application.

Why not check them? If we open the first link, we see a page with a raised exception:

The first URL page raises an exception.

If we go further in this page, juicy information appears in a JSON format:

The first URL page contains a juicy JSON structure.

As we can see, the server leaks a lot of data, including the passwords of every device without requiring any authentication from us.

JSON structure caption.

So, information about lock of each user is recorded:

• we can get the password. Quickly, we can see that 85% of the users do not change the default password (000000).

Smart lock password.

But also, we can know each time that a lock was opened and exactly where!

The latitude and longitude fields.

With a straightforward script, you can pinpoint them on a map:

• you know exactly the location of the locks all over the world!
• with each of their passwords and you just need a mobile to use it!
• No onerous hardware or dedicated skills are required!

A worldwide crime syndicate could coordinate a cheap and massive robbery without leaving any traces!

It highlights one of the biggest IoT challenges. A risk is characterized by its likelihood to happen and the severity of the consequences if it occurs. But, a third item must not be missed: the scalability. Devices communicate between them or with a server by design. A security flaw impacting a device is more likely to be exploitable remotely, thus affecting concurrently all the deployed devices. Also, hardware or software not designed to be upgraded might let it unfixed forever. A risk requiring to be physically near the device is much less dangerous than another one you can execute remotely.

How to mitigate all these issues?

You must consider the new risks induced by the connectivity. First, start with identifying all the assets of your product and their associated threats that could affect them, with a risk analysis like EBIOS. It lets you better understand which protections shall be implemented. For the smart lock, a message could be sent to the owner each time it is opened to warn him about suspicious activity.

Second, find the correct balance between the risks that must be prevented and the cost to implement the required level of protection:

• For the lock communication, cryptographic algorithms must be implemented to create a secure channel before exchanging sensitive commands such as the authentication or the lock opening. Use random counters in the frames to prevent replay.
• For the Android application, obfuscate the code and detect instrumentation or modification. Critical operations shall be implemented in native code, or even better from the server side. Sensitive strings, as the server URL, must not leak in a simple logcat: either you delete them in production, or you encrypt them.
• For the server, implement secure authentication and access rights. Check the available APIs and make penetration tests.