如何用一部手機打開隔壁王大爺家的智能門鎖？

新聞 11-04

攔截BLE的通信

由於各種原因，在現實生活中，大多數BLE設備（包括智能鎖）都還沒有實現藍牙鏈路層安全性的配對、綁定和加密，這就意味著BLE設備（包括智能鎖）的通信協議是在未加密的BLE鏈路傳輸的。這使得藍牙鏈路層上的數據包不但可以輕易被攔截，而且還能利用它們實施攻擊。

一般來說，攔截無線傳輸時首先想到的是利用專業的嗅探器，不過這不是我的首選方案，因為除了特殊硬體外，被動的嗅探並不是很可靠，通常都是雜亂的數據包，並且分析傳輸的數據（例如在Wireshark中）並不是很簡單。

所以我利用了我自己開發的GATTacker來對無線傳輸信號進行捕捉，GATTacker是一種低功耗藍牙中間人攻擊代理工具。而GATTacker所需要的硬體配置也僅僅是價值5美元的Bluetooth 4.0適配器。

只需簡單地輸入scan命令，即可開始查詢，如下所示，你會發現你附近的所有設備信息。

可以看出，信息很短，一般來說，BLE設備會通過不斷廣播的來證明它的存在。所以，如下所示，可以很容易發現了我所使用的一款智能鎖，以及它所使用的mac地址和設備名稱。接下來，就要對智能鎖的服務特點進行掃描。

你可以簡單地把BLE的服務特點想像成存儲在設備中的一個簡單的uid變數，可以進行讀寫。

在掃描後，模擬原始設備所需的所有數據都被存儲為json文件。這樣，我就可以準備啟動攔截代理了。GATTacker將作為原始設備的軟體模擬器，欺騙移動應用程序進行連接，然後將可交換的數據來回交換。在本文中，由於智能鎖的移動應用程序會檢查掃描設備的BT MAC地址，所以我必須欺騙它。

注意：大多數內置在筆記本電腦中的Bluetooth 4.0適配器是不允許更改MAC地址，所以我會使用一個CSR8510 USB加密狗，還有一個簡單的腳本。

現在只需重新插入USB加密狗即可填充新的MAC地址，並啟動中間人攻擊代理了：

如果你看到紫色的「初始化」文本，則意味著中間人攻擊代理已經正確建立了與原始設備的連接，啟動軟體設備模擬器，並準備攔截。

由下圖可以看出，一旦攻擊目標的移動應用程序連接到我的模擬設備，代理就會開始來回傳送數據：

上圖中的藍色寫入部分就是從移動應用程序發送到設備的數據，可以看出括弧中的ascii值被解碼，其中， ffe0 - > fff1是服務id。

通信以一些較長的二進位數據包開始，接下來會有幾個相同的寫入和讀取過程，大約每秒一次。這些過程完成後，我通過點擊移動應用程序中的「解鎖」選項，就會得到一些各式各樣的數據包。

明文登錄

如果是這樣的話，那本文就可以到此結束了。現在，讓我假設密碼不是以明文的方式進行傳輸，看看會發現什麼。

重播

如上所述，最初移動應用程序很少與設備交換複雜的數據包。

每隔一段時間，數據都會有所不同。

你可以通過各種方式檢查這個協議的細節，並進行反向操作，並理解來回發送的每個位元組。你可能已經注意到重複的十六進位編碼「741689」了，稍後我會對它進行詳細解釋。

以下是移動應用程序發送的第一個數據包（藍色部分）：

雖然開頭部分相同，但結尾每次都不同。接下來，設備會對這些數據進行再次響應：

可以看出，反應取決於初始值：

這看起來像是一個簡單的挑戰響應方法，類似的方法在應用程序層非常常見，它是BLE設備的專有身份驗證方式。在最流行的硬體模塊中，只有簡單的AES才有加密支持。因此，當一個開發人員試圖提出自己的加密協議時，他通常會使用AES和靜態的加密，在設備和移動應用程序之間共享一些東西。而對於那些複雜的部分，就像對於對稱密碼，共享和驗證密碼都會進行明文傳輸。由於沒有公共密鑰演算法的支持，開發人員就只能想辦法進行解決。

由上圖可以看出，最初的挑戰是由手機發送的，而不是智能鎖設備。所以，如果設備僅基於挑戰來計算響應，那對於相同的挑戰，響應將始終是相同的。這就使得解決方案容易受到簡單的重播攻擊，攻擊者在記錄所交換的數據後，簡單地進行重播，而不需要深入分析數據包：

於是,我嘗試執行這個重播攻擊，此時，GATTacker工具記錄了轉儲子文件夾中的所有攔截數據，文件名只是設備的MAC地址，文件如下所示。

2017.10.24 10:50:54.531 | < C | ffe0 | fff1 | a137343136383905789a3b246c6c17164f0121 ( 741689 x ;$ll O !)2017.10.24 10:50:54.702 | > R | ffe0 | fff1 | a20500f0c77f162e8bd21110841e641e641480 ( . d d )2017.10.24 10:50:54.980 | < C | ffe0 | fff1 | a137343136383909bcaafbae83b5babc02b8f7a0 ( 741689 )2017.10.24 10:50:55.156 | > R | ffe0 | fff1 | a20900 ( )2017.10.24 10:50:55.610 | < C | ffe0 | fff1 | a136363636363606 ( 666666 )2017.10.24 10:50:55.735 | > R | ffe0 | fff1 | a206002c010000 ( , )2017.10.24 10:50:56.645 | < C | ffe0 | fff1 | a136363636363606 ( 666666 )2017.10.24 10:50:56.769 | > R | ffe0 | fff1 | a206002c010000 ( , )2017.10.24 10:50:57.277 | < C | ffe0 | fff1 | a136363636363606 ( 666666 )2017.10.24 10:50:57.400 | > R | ffe0 | fff1 | a206002c010000 ( , )2017.10.24 10:50:57.951 | < C | ffe0 | fff1 | a136363636363601 ( 666666 )2017.10.24 10:50:58.076 | > R | ffe0 | fff1 | a20100 ( )

該文件的格式非常簡單，「R」表示設備的讀取響應。接下來的運行都會尊徐這個特點，並以十六進位形式發送數據。括弧中的時間戳和解碼的ascii十六進位值僅供參考，不會被解釋為重播。

如果要重播，只需使用此轉儲文件作為輸入參數，來調用replay.js輔助腳本：

這樣，智能鎖設備就會被解鎖。

你也可以使用你的手機實施同樣的操作， nRF Connect應用程序有一個非常有趣的功能：macros。它可以提供特殊格式的XML輸入文件，之後，nRF Connect就可以重播任何BLE通信序列，而我只需將GATTacker轉儲轉換為nRF macro XML格式：

# node gattacker2nrf.js -i dump/f0c77f162e8b.log > dump/f0c77f162e8b.xml

你可以在點此查看生成的文件，並將文件導入nRF Connect。接下來，只需連接到設備，然後按重播按鈕進行重播：

你可以稍後利用該技巧與你的設備進行交互，且無需任何其他硬體的支持，當然，你也可以根據你的需要修改XML輸入文件。

不管哪種嗅探和重播攻擊，都需要具備一個攻擊條件：攻擊者的嗅探或重播攻擊的藍牙範圍必須覆蓋受害者的解鎖設備。同時，這也是許多用戶懶得更改默認密碼的原因，他們總以為他們的設備處於安全範圍，無法被人嗅探到。

所以，我接下里，我會繼續進行一個更有挑戰性的攻擊，即不需要事先嗅探就能發起攻擊。

專用協議（proprietary protocol）

我將會用到這種專用通信協議，不過前提是逆向移動應用程序。

逆向移動應用（mobile application reverse）

關於逆向移動應用的教程，網上有很多，本文就不贅述了。基本上這些方法都依照獲取應用程序的apk二進位文件，然後將其進行反編譯，最後再檢查java源代碼的步驟進行的。大多數情況下，生成的反編譯代碼都是可讀的。

可能打開的第一個類就是「SmartLock」：

我很確定SUPER_PASSWORD（上圖右邊第4行）引起了你的注意，它在移動應用中是硬編碼的，所以很可能也嵌入到了硬體中。看到其中的「741689」，你會想到什麼呢？你是不是以為這是登錄密碼，那讓我試試，看在初次握手中會發生什麼？

簡單的反編譯源代碼會允許你找到特定的代碼片段，並告訴你這個握手過程是如何工作的:

一開始，移動應用程序會生成隨機數據，並根據MsgRequestVerify格式將其附加到「741689」。在MsgRequestVerify類的源碼中你還會發現以下代碼段：

於是，我嘗試將其與剛開始捕獲數據包進行匹配：

如上圖所示，我已經知道它已經嵌入了十六進位編碼的SUPER_PASSWORD：

在經過多次的挑戰之後，我已經可以指出隨機數據了：

如果你還記得MsgRequestVerify通信格式，那應該能想起MSG_STX = 161;，在十六進位中，161的十進位值等於a1，這是數據包中的第一個位元組，似乎是一個消息頭。所以我有必要對另一部分數據包進行解碼：

MsgRequestVerify再次出現MSG_CMD = 5，以下是是命令ID：

剩餘的靜態部分也在MsgRequestVerify類中定義：con1 = 120（在十六進位中為78），con2 = -102（在十六進位中為9a）。至此，我已經解碼了整個數據包結構：

接下來，從設備接收到的數據包的驗證就是基於簡單的CRC：

這個挑戰是根據該響應（mFirstReceiver）計算出移動應用程序發送的數據包：

事實證明，在某些情況下智能鎖在質詢響應中交換的數據是不需要密碼的，僅僅使用靜態硬編碼的「SUPER_PASSWORD」就夠了。這一方法適用於目前所有的智能鎖，這意味著，它是一個嚴重的漏洞。但就如你在上文中了解的那樣，我的設備實際上是按照以下命令發送密碼的。不過，我不確定為什麼要引入握手機制，可能只是為了「身份驗證」(不管我們是否是合法使用)。

所以，讓我來分析一下其他的命令，看看在最初的握手之後他們是怎麼通過BLE發送給設備的。

協議命令（ ProtocolCommand）

進一步瀏覽源代碼，你會發現「message」子文件夾：

「MsgRequestLockInfo」的一個反編譯片段：

我會再次嘗試將其與GATTacker攔截的數據包進行匹配：

你還應該識別MSG_STX（標頭）和MSG_CMD（命令ID）：

還記得解鎖時發送的不同命令嗎？它的結尾處是「01」而不是「06」。該命令和MsgRequestOpenLock類都匹配。

這樣，你就完成了對專用協議的逆轉。

「CANCER」攻擊

雖然上面做了很多的工作，但我仍然在尋找一種不需要先前嗅探的攻擊方法。

不過這招顯然不奏效，設備還是鎖定的。

那除了上面的命令外，是否還有其他命令可以執行呢？比如RequestAutoLock，RequestLock，RequestModifyName，RequestModifyPassword，RequestResetPassword，MsgRequestVibrate等，不過在測試後發現都不靈。這時，我發現了一個ModifyPassword (MSG_CMD = 7)命令，使用這條命令，截獲的數據包中就會包含當前的密碼以及新生成的密碼：

不過要注意的是，在使用該命令後，你依然要使用當前的密碼，如果只使用SUPER_PASSWORD則依然會不靈，因為智能鎖會對該數據包進行驗證。那麼，讓我再來試試ResetPassword命令吧，但我發現在官方移動應用的用戶操作界面中，是沒有密碼重置操作的，不過這可難不倒我，因為我會將MSG_CMD值內置其中。

詳細解釋如下所示：

首先腳本會重置智能鎖的密碼，然後自動打開智能鎖。

當然，你也可以使用nRF Connect移動應用程序來執行此操作，關於它的操作，我已經在上文的重播攻擊中進行了介紹。你可以點此直接獲取轉換好的XML宏文件。等以後你再進行解鎖時，只需在你的手機上通過導入該XML宏文件，然後進行重播時，它就會自動運行了。

現在讓我們把話題轉回到「CANCER」攻擊，在進行「CANCER」攻擊時，如果密碼被重置，則就會與移動應用程序中保存的默認密碼不匹配，這時用戶就會受到以下錯誤提示。

供應商的緩解措施

很明顯，在這個攻擊中，智能鎖本身的漏洞攻擊的關鍵。所以在確定了這個漏洞後，我就向相關的智能鎖供應商提交了此漏洞。以下是一些廠商的回復，比如2017年3月的：

你好，我們已經確定了智能鎖和移動應用程序中的這幾個安全漏洞。現在我們已經將其分類為嚴重漏洞。

顯然這是一個很負責人的回復，不過以下供應商的回復就顯得很不負責任了，甚至有些令人氣憤：

你好，我們已經修改你提交給我的漏洞，我們會繼續改進我們的產品。

但當我重新對他們的產品進行測驗時，發現他們的回復竟然是騙人的。

我也試圖聯繫了Android手機應用開發者，不過大約3個月後，我才得到了回復，回復如下：

對不起，這個和本公司的業務不相關，所以我幫不到你。

所以看到這些回復，我就對官方的修復徹底失去了信心，以我的為例，我所使用的智能鎖目前已經停產，就連其後台的密鑰伺服器也關閉了，所以為了不讓我的智能鎖失效，我試用了幾個簡單的技巧，詳情請點此詳細了解。

總結

使用手機攻擊藍牙智能鎖設備總共經歷了四個步驟：

1.攔截通信，

2.重播，

3.逆向專有協議，

4.在逆向協議中找到的漏洞。

當然這並不適用於所有的攻擊情況，我會在未來的文章中進行詳細分析。

看完這篇文章，你是不是覺得智能鎖簡直就是不堪一擊，沒有任何安全保護措施，恨不得要把你正在使用的給扔掉。其實真實的情況是，智能鎖比大多數BLE設備都安全，比如BLE性玩具，、燈泡或感測器，這些才是真正的安全炸彈，因為它們幾乎沒有任何安全防護措施，甚至連最簡單的靜態明文密碼的認證過程都沒有。所以藍牙設備的安全還得看具體的設備，另外就是你的藍牙設備保護意識也得提高，比如修改默認密碼。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 嘶吼RoarTalk 的精彩文章:

※APT組織Gaza Cybergang重出江湖深度利用了微軟漏洞
※馬來西亞大規模數據泄露：近50萬公民手機號泄露
※七大維度談NoSQL資料庫安全風險
※電信天翼客戶端攜帶病毒瘋狂「挖礦「多款軟體攜帶同樣病毒代碼
※Apache James 伺服器反序列化漏洞分析和利用

TAG:嘶吼RoarTalk |