Security in Integrated Circuit 
Company 
Blog
Contact us
Back to all articles
Software Security

The Bluetooth smart lock which spoke too much

6 min read
Edit by Vinet Guillaume Jun 8, 2020
Share

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

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.

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

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

lock.png

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.

code_1.png

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

logcat.png

A chatty application.

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

exception.png

The first URL page raises an exception.

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

json_1.png

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

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

json_3.png

Smart lock password.

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

json_4.png

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!

map.png

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

Categories

All articles
(14)
Company news
(2)
Integrated Circuit Security
(5)
Product
(0)
Software Security
(7)
Technical
(0)

you might also be interested in

Software Security

Mobile App Shielding Market Intelligence

6 min read
Edit by Thiebeauld Hugues May 12, 2021
© eShard 2021. All rights reserved
Privacy policy | Legal Notice
Bâtiment GIENAH
11 avenue de Canteranne
33600 PESSAC
France
7 rue Gaston de Flotte
13012 MARSEILLE
France
#04-01 Paya Lebar Quarter
1 Paya Lebar Link
SINGAPORE 408533
eShard GmbH
Lebacher Str. 4
66113 Saarbrücken
Germany