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.
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:
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.
The Android application shares the same level of security. The analysis is straightforward:
Method to build the authentication command.
Thanks to this code, we can now translate the data in the frames we identified earlier:
And, the second one to open the lock:
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!
Indeed, if we continue to analyze the application, a simple logcat gives a lot of information, especially two URLs:
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:
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:
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.
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: