滑板車預設金鑰漏洞
今天看到篇有趣的文章，來自愛沙尼亞的資安研究員 Rasmus Moorats，標題是：《Reverse engineering my cloud-connected e-scooter and finding the master key to unlock all scooters》，逆向工程我的電動滑板車，卻不小心找到了可以解鎖所有車車的 master key。
這位研究員他有一台 Äike 出的電動滑板車，但這間公司去年破產了，而電動滑板車附帶的 app 有些功能也跟著停用，雖然還是能夠解鎖，但由於這個 app 都是連到某個 server 去，他很擔心哪天這個 server 直接關掉，就可能再也用不了。
於是作者開始逆向這個 app，想看一下背後的原理，發現手機跟電動滑板車的溝通是透過藍芽以及自訂的傳輸格式，在一開始的身份驗證流程中，會先從車車那裡拿到一串字（給一個 challenge），要能產生正確的回答才會成功。
作者觀察一下發現這個回答有點像 SHA-1，於是就 hook 了一下，發現還真的是，先從車車那裡讀到一個字串，把字串跟 private key 拼在一起丟去 SHA-1 再送回去，就可以完成身份認證。
那這個 private key 是什麼呢？答案是 20 個 FF。
為什麼是 20 個 FF 呢？因為這是某個 IoT SDK 的預設值，只要沒有改的話，你預設的 private key 就是這個。
而 Äike 的開發人員可能是忘了改，每台車用的都是同一個 private key，都是同一組。因此呢，作者不只能解鎖自己的車，也能順便解鎖其他人的。
作者後來也把整組溝通協定都逆向出來了，寫了一個自己的 app 來控制他的電動滑板車，甚至可以透過智慧手錶來控制，做到以前做不到的事情，這就是逆向的厲害之處（？）
這種「沒改預設 key」其實也不少見，有些可以自己架的網站也會這樣，或甚至有些直接 hardcode 一個 secret key，這也一直在發生。
正確做法是每一次安裝都隨機產生一個 secret key 幫你存起來，而這個電動滑板車的案例，應該每一台的 key 都要不同才對，而且要是不可預測的。
原文有附更多技術細節，包含 Frida 的腳本以及如何逆向新版 React Native（看到這篇我才知道原來新版變成 bytecode 了，我的知識還停留在整包 JavaScript 的時代）。
評論