FB50 Smart Lock Vulnerability Disclosure (CVE-2019-13143)

Executive Summary

Our security engineers found vulnerabilities in the FB50 smart lock mobile application. An information disclosure vulnerability chained together with poor token management lead to a complete transfer of ownership of the lock from the user to the attacker’s account.

Product Description

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 e-commerce sites, and has over, an estimated, 5000 users. Judging by the download count on the Play Store, for its app. This is excluding the iOS App Store downloads.

Approach

Our initial attempt was to perform a replay of the captured Bluetooth packets. Two attempts at this were performed. First, we tried replaying the packets in the HCI dump log, captured on an Android device. In the second try, we used gattacker running on a Raspberry Pi, in an attempt to spoof the lock’s MAC address and make the app communicate with the Raspberry Pi instead.
We soon realized that the data being written during the “unlock” requests, was encrypted, and hence the replays were unsuccessful. We then decided to take a crack at the companion app instead, in which we ended up finding the information disclosure and token related bugs.

Findings Overview

• No SSL pining used for the android application
• IDOR in the user ID, exposing user data
• Knowing just the MAC address of the lock alone, a series of requests
  can be chained to unbind the existing user to the lock and bind a new one

Technical Description

Getting the Lock’s QR Code and lock ID

During Pentesting the device, we obtain the MAC address of smart device via simple Bluetooth scanning in the vicinity. We captured the following request and we got a tone of device information in a response.

From these all, we take two measure values i.e. the QR code and the MA address

Use the barcode and fetch the user ID

Now, we moved to another request, here we just passed the QR code into the request and we got the following response.

In response, we got the much of User’s information.we are going to use the user ID from this.

Unbinding the lock from victim’s Account

So we obtained the User id and lock id. Using these two values we try to tamper the Unbind request which we captured at a time of unbinding the targeted device from the owner’s account.

So as you can see we successfully unbind the victim’s device remotely from his/her mobile application.

Bind the targeted device to the attacker’s account.

So now it’s time to connect the attacker’s application to the victim’s device.

We just provided a new name, attacker’s user ID and the MAC address. we already have the bind request having above values.

So here, we did with binding the victim’s smart lock to our(attacker’s) mobile application. Now just unlock the device with the mobile application. For unlocking the device via mobile application attacker should present in the Bluetooth range of the device.

View here the video PoC here

Disclosure Timeline

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

Researchers

1. S. Raghav Pillai [@_vologue] https://twitter.com/_vologue
2. Anirudh Oppiliappan [@icyphox] https://twitter.com/icyphox
3. Shubham Chougule [@shubhamtc] https://twitter.com/shubhamtc
4. Akash Kandhare [@BhagajiAkash] https://twitter.com/BhagajiAkash