<- back
view in plain-text

Picking the FB50 smart lock (CVE-2019-13143)

… and lessons learnt in IoT security

(originally posted at SecureLayer7’s Blog, with my edits)

The lock

The lock in question is the FB50 smart lock, manufactured by Shenzhen Dragon Brother Technology Co. Ltd. This lock is sold under multiple brands across many ecommerce sites, and has over, an estimated, 15k+ users.

The lock pairs to a phone via Bluetooth, and requires the OKLOK app from the Play/App Store to function. The app requires the user to create an account before further functionality is available. It also facilitates configuring the fingerprint, and unlocking from a range via Bluetooth.

We had two primary attack surfaces we decided to tackle—Bluetooth (BLE) and the Android app.

Via Bluetooth Low Energy (BLE)

Android phones have the ability to capture Bluetooth (HCI) traffic which can be enabled under Developer Options under Settings. We made around 4 “unlocks” from the Android phone, as seen in the screenshot.

wireshark packets

This is the value sent in the Write request:

wireshark write req

We attempted replaying these requests using gattool and gattacker, but that didn’t pan out, since the value being written was encrypted.1

Via the Android app

Reversing the app using jd-gui, apktool and dex2jar didn’t get us too far since most of it was obfuscated. Why bother when there exists an easier approach—BurpSuite.

We captured and played around with a bunch of requests and responses, and finally arrived at a working exploit chain.

The exploit

The entire exploit is a 4 step process consisting of authenticated HTTP requests:

  1. Using the lock’s MAC (obtained via a simple Bluetooth scan in the vicinity), get the barcode and lock ID
  2. Using the barcode, fetch the user ID
  3. Using the lock ID and user ID, unbind the user from the lock
  4. Provide a new name, attacker’s user ID and the MAC to bind the attacker to the lock

This is what it looks like, in essence (personal info redacted).

Request 1

POST /oklock/lock/queryDevice


      "createAt":"2019-05-14 09:32:23.0",
      "id":<LOCK ID>,

Request 2

POST /oklock/lock/getDeviceInfo



      "createAt":"2019-05-14 09:32:23.0",
      "id":<LOCK ID>,
      "userId":<USER ID>

Request 3

POST /oklock/lock/unbind

{"lockId":"<LOCK ID>","userId":<USER ID>}

Request 4

POST /oklock/lock/bind

{"name":"newname","userId":<USER ID>,"mac":"XX:XX:XX:XX:XX:XX"}

That’s it! (& the scary stuff)

You should have the lock transferred to your account. The severity of this issue lies in the fact that the original owner completely loses access to their lock. They can’t even “rebind” to get it back, since the current owner (the attacker) needs to authorize that.

To add to that, roughly 15,000 user accounts’ info are exposed via IDOR. Ilja, a cool dude I met on Telegram, noticed locks named “carlock”, “garage”, “MainDoor”, etc.2 This is terrifying.


Proof of Concept

PoC Video

Exploit code

Disclosure timeline

  • 26th June, 2019: Issue discovered at SecureLayer7, Pune
  • 27th June, 2019: Vendor notified about the issue
  • 2nd July, 2019: CVE-2019-13143 reserved
  • No response from vendor
  • 2nd August 2019: Public disclosure

Lessons learnt

DO NOT. Ever. Buy. A smart lock. You’re better off with the “dumb” ones with keys. With the IoT plague spreading, it brings in a large attack surface to things that were otherwise “unhackable” (try hacking a “dumb” toaster).

The IoT security scene is rife with bugs from over 10 years ago, like executable stack segments3, hardcoded keys, and poor development practices in general.

Our existing threat models and scenarios have to be updated to factor in these new exploitation possibilities. This also broadens the playing field for cyber warfare and mass surveillance campaigns.

Researcher info

This research was done at SecureLayer7, Pune, IN by:

  1. This article discusses a similar smart lock, but they broke the encryption. 

  2. Thanks to Ilja Shaposhnikov (@drakylar). 

  3. PDF 

Questions or comments? Send an email to ~icyphox/x@lists.sr.ht—my public inbox.

25/05/2020: This month in KISS (#2)

Welcome to the second monthly update for KISS. This post will be quite a long one, we've seen some nice changes this month and some great work by the Community.…

via KISS Linux Blog on May 25, 2020

Zoom + Keybase

There is an opportunity here to signal that Zoom is not a Chinese asset. Zoom can effectively remove itself from the board by completely mitigating passive surveillance. When no state’s intelligence agency benefits from a home field advantage with Zoom, th…

via grugq’s domain on May 08, 2020

Investigate TikTok Like A Pro!

TikTok videos have grown increasingly popular over the last few years, with short clips showing people dancing, lip syncing, doing viral challenges, and so on. This relatively new platform lets users share short video clips, and can be looped. It is simila…

via bellingcat on May 25, 2020

Generated by openring.py






Some of my friends and internet bros.


More about me and my work.