一部手機就能打開隔壁王大爺家的智能門鎖

02-10

攔截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。

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

明文登錄

在上一部分中，你可能已經注意到了「6666666」（十六進位編碼為363636363636）不斷在重複，其實，這就是設備的當前密碼，且以明文形式發送。順便說一句，你還可以使用Ubertooth進行遠程嗅探。獲得密碼後，攻擊者就可以很容易地實施攻擊了，通過在他們自己的設備上輸入其他人的登錄憑證就可以完全控制智能鎖了。

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

重播

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

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

與設備初始握手後，就可以發送命令了。在該設備的情況下，如果你嘗試在連接時直接發送命令進行解鎖，例如，a136363636363601，則無需事先握手。所以這種握手就是認證的一個形式。

你可以通過各種方式檢查這個協議的細節，並進行反向操作，並理解來回發送的每個位元組。你可能已經注意到重複的十六進位編碼「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 ( )

該文件的格式非常簡單，「<C」表示寫入命令，「> 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攔截的數據包進行匹配：

至此，我就知道了這個包的核心是十六進位編碼的密碼（在十六進位的ascii中為666666 = 363636363636）：

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

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

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

「CANCER」攻擊

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

此時，我會用到SUPER_PASSWORD，它會在初始握手時使用。如果我直接在OpenLock命令中使用這個SUPER_PASSWORD，那隻會對轉儲文件進行編輯，並且在初始握手後發送寫入的a1 373431363839 01命令（OpenLock的標頭+ SUPER_PASSWORD +命令ID），然後像之前那樣進行重播：

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 | a137343136383901

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

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

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

接著，我會把用於重播的輸入文件進行重新修改，過程很簡單，只需將OpenLock命令01更改為ResetPassword 08，不過此時，仍然使用的是「741689」 – 373431363839 SUPER_PASSWORD）：

(...)2017.10.24 10:50:55.610 | < C | ffe0 | fff1 | a137343136383908

想不到，竟然成功了！智能鎖現在的默認密碼已經變成了為「123456」。接下來要做的就是修改腳本對智能鎖實施最後的攻擊，過程很簡單就是在原來的腳本後加個 OpenLock命令，且使用默認密碼（十六進位中為313233343536）：

詳細解釋如下所示：

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

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

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

供應商的緩解措施

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

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

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

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

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

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

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

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

總結

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

1.攔截通信，

2.重播，

3.逆向專有協議，

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

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

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

本文翻譯自：https://smartlockpicking.com/tutorial/how-to-pick-a-ble-smart-lock-and-cause-cancer/ ，如若轉載，請註明原文地址： http://www.4hou.com/mobile/8301.html 更多內容請關注「嘶吼專業版」——Pro4hou