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 led 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 based on 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 attempted to replay the packets from the HCI dump log captured on an Android device. Next, we used gattacker running on a Raspberry Pi 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 pinning 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 the pentesting, we obtain the MAC address of the smart device via basic Bluetooth scanning in the vicinity. We captured the following request and received a lot of device information in the response.

From this, we took 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 received a significant amount of user information. Now, we are going to use the user ID from this response. 

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.

As shown, we successfully unbound 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.

We then successfully bound the victim’s smart lock to the 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
• 27^th June 2019: Vendor notified about the issue
• 2^nd July 2019: CVE-2019-13143 reserved
• No response from the vendor till 2nd August 2019
• 2^nd 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