安全文库

【技術分享】逆向分析Aura睡眠鬧鐘


【技術分享】逆向分析Aura睡眠鬧鐘

WisFree

【技術分享】逆向分析Aura睡眠鬧鐘

譯者:WisFree

預估稿費:200RMB

投稿方式:發送郵件至linwei#360.cn,或登陸網頁版在線投稿

寫在前面的話


在前幾天,我收到了一款名叫Aura的設備。這款設備由Withings設計、生產和銷售,根據介紹,Aura是一款聯網睡眠鬧鐘。但是Aura並不單純是一個鬧鐘,它的內部設計非常棒,它介入了Sporttify音樂流服務,你可以選擇官方推薦的歌單或根據自己的喜好來選擇睡眠和起床音樂。

除此之外,Aura的內部還集成了各種感測器,並能夠對用戶周圍的環境和睡眠參數進行檢測和分析。設備的上方有一個LED等,且整個上半部分都支持觸控操作,因此Aura就可以通過這套聲光系統來模仿日出的亮度變化,併發出悅耳的音樂來減輕人們起床的痛苦。

【技術分享】逆向分析Aura睡眠鬧鐘

在了解到這些信息之後,我打算對這款設備進行逆向分析,理由如下:

1.       首先,這肯定會非常有趣,而且這個過程中我還可以學到很多新東西。

2.       我想要真正「控制」這台設備,我想讓我自己的代碼在這台設備上運行。

這篇文章記錄了我對Aura進行逆向分析的完整過程,其中包括固件鏡像的獲取以及遠程緩衝區溢出漏洞的利用方法。

註:我已經與廠商取得了聯繫,並將本文所要描述的安全問題告知了廠商的安全技術人員。實際上,他們之前就已經知道了本文所要介紹的部分安全漏洞,並且正在努力修復剩下的問題。本文不會給大家提供Aura的固件鏡像、完整代碼文件以及腳本,本文所介紹的內容純粹出於教育目的。


初次分析


首先,我得先了解更多關於Aura硬體的信息。因為Aura其實並不便宜(1200元人民幣左右),所要我現在還不想拆開它。所以我打算先查閱一下網上的公開文檔【FCC驗證報告】,然後對Aura的硬體情況有一個基本的了解。

從內部電路板的圖片來看,Aura是由一塊Freescale處理器驅動的,並且設備運行的是一種嵌入式的Linux操作系統。

【技術分享】逆向分析Aura睡眠鬧鐘

由於Aura一直會保持聯網狀態(WiFi),這也是其配置所要求的,所以我使用nmap對該設備進行了一次掃描,最後得到了以下掃描結果:

【技術分享】逆向分析Aura睡眠鬧鐘

埠22貌似是一個過濾埠,但這裡的SSH伺服器仍然是可響應的。當然了,如果沒有有效的密碼或SSH密鑰的話,這台SSH伺服器還是沒辦法正常訪問的。

從藍牙端來看,Aura是可以通過藍牙發現的。它運行了一台SDP伺服器,並且會告知我們下列服務正在運行之中:

【技術分享】逆向分析Aura睡眠鬧鐘


固件獲取


為了對Aura進行更深入的分析,我需要拿到設備的固件文件。正如之前所說的,我現在可不想拆開它。為此,在固件的更新過程中,我設置了一個MITM代理來嗅探Aura和其伺服器之間的網路通信數據。

隨後我便發現,該設備似乎使用了HTTP來下載固件鏡像文件:

GET /wsd01/wsd01_905.bin HTTP/1.1 Host: XXXXXXXXXXXXXXXXXX Accept: */*


固件鏡像分析


文件系統提取

下載的鏡像文件內容如下所示,文件數據的開頭部分貌似是一個header,我們之後會將其轉換為FPKG文件:

【技術分享】逆向分析Aura睡眠鬧鐘

接下來,我們可以使用binwalk迅速找到有價值的比特位數據:

$ binwalk wsd01_905.bin | head   DECIMAL       HEXADECIMAL     DESCRIPTION -------------------------------------------------------------------------------- 28            0x1C            UBIFS filesystem superblock node, CRC: 0xBF63BF7E, flags: 0x0, min I/O unit size: 2048, erase block size: 126976, erase block count: 171, max erase blocks: 1000, format version: 4, compression type: lzo 127004        0x1F01C         UBIFS filesystem master node, CRC: 0x8D8C5434, highest inode: 1265, commit number: 0 253980        0x3E01C         UBIFS filesystem master node, CRC: 0x81BCA129, highest inode: 1265, commit number: 0 1438388       0x15F2B4        Unix path: /var/log/core 1444812       0x160BCC        Executable script, shebang: "/bin/sh" 1445117       0x160CFD        Executable script, shebang: "/bin/sh" 1445941       0x161035        Executable script, shebang: "/bin/sh"

由此可以看出,Aura下載的文件中包含一個UBIFS鏡像(偏移量為0x1C)。有了jrspruitt的腳本【下載地址】幫助,從UBIFS鏡像中提取出文件相對來說還是比較簡單的。

【技術分享】逆向分析Aura睡眠鬧鐘

你會發現,原來這個嵌入式Linux系統中的所有文件我們都可以訪問到!我做的第一件事情當然就是檢查/etc/shadow文件的內容啦!我首先嘗試用John the Ripper來破解密碼,但幾分鐘之後我放棄了,因為我感覺密碼十分的複雜。

FPKG文件格式

既然所有的文件我都能夠訪問到,所以我們應該可以了解到FPKG結構。跟固件更行以及FPKG文件有關的函數存在於兩個共享庫中,即libfpkg.so和libufw.so。在進行了一些反編譯工作之後,我得到了如下圖所示的文件結構。

【技術分享】逆向分析Aura睡眠鬧鐘

關於此類文件結構的介紹可以參考這份【ksy文件】。

將這種文件結構應用到之前我所獲取到的文件中:

【技術分享】逆向分析Aura睡眠鬧鐘

這份文件是經過簽名的,所以我還無法用它來更新我的固件。


拿到Root SSH訪問權


在得到固件鏡像之後,接下來就是要拿到SSH訪問權了。我對代碼的運行狀態進行了觀察,然後嘗試從中尋找到安全漏洞。

目錄遍歷攻擊

其中有一個名叫seqmand的守護進程引起了我的注意。seqmand負責從遠程伺服器自動下載音頻文件,它的工作機制如下:

1.       設備啟動時,seqmand會下載一個csv文件:

GET /content/aura/sequences-v3/aura_seq_list.csv HTTP/1.1 Host: XXXXXXXXXXXXXXXXXXX Accept: */*

2.       aura_seq_list.csv文件大致如下所示:

【技術分享】逆向分析Aura睡眠鬧鐘

3.       對於csv中的每一行,seqmand都會將相應的文件下載到一個臨時目錄中:

download "http://XXXXXXX/content/aura/sequences-v3/WAKEUP_4/v3_audio_main_part_2.mp3" to "/tmp/sequences/WAKEUP_4/v3_audio_main_part_2.mp3" download "http://XXXXXXX/content/aura/sequences-v3/WAKEUP_4/v3_audio_main_part_1.mp3" to "/tmp/sequences/WAKEUP_4/v3_audio_main_part_1.mp3" download "http://XXXXXXX/content/aura/sequences-v3/WAKEUP_3/v3_audio_main_part_2.mp3" to "/tmp/sequences/WAKEUP_3/v3_audio_main_part_2.mp3"

4.       臨時文件最終會被移動到/usr/share/sequences文件夾中。

我將seqmand的HTTP請求重定向到了我自己搭建的HTTP伺服器,然後提供了一個自定義的aura_seq_list.csv文件。接下來,我迅速發現了目錄遍歷攻擊也許是可行的。

比如說,如果我使用下列csv文件,其中包含一個test文件以及有效的MD5值:

【技術分享】逆向分析Aura睡眠鬧鐘

seqmand將會完成以下任務:

download "http://XXXXXXX/content/test" to "/tmp/sequences/WAKEUP_42/../../../test"

我使用一個靜態編譯的qemu在筆記本電腦上模擬了一個守護進程,並創建了一個/test文件。首先,我想要用我自己的密碼重寫/etc/shadow文件:

【技術分享】逆向分析Aura睡眠鬧鐘

目錄遍歷PoC

在分析的過程中我發現,操作系統運行在一個只讀分區中,但其他的部分還是可寫的。下面的代碼來自於/etc/init.d/prepare_services腳本:

【技術分享】逆向分析Aura睡眠鬧鐘

/var/service/sshd/的內容如下所示:

【技術分享】逆向分析Aura睡眠鬧鐘

運行的文件算是一個啟動腳本,當服務啟動之後該腳本也會被執行,而supervice/目錄下的所有程序都將能夠與服務進程交互。接下來,我準備重寫/var/service/sshd/run腳本。但是這還遠遠不夠,因為該腳本只會在設備啟動時運行,所以我根本來不及重寫它。我的想辦法強制SSH守護進程重啟,比如說這樣;

$ echo k > /var/service/sshd/supervise/control $ echo u > /var/service/sshd/supervise/control

此時我就可以終止並重啟sshd服務,並再次運行腳本了。

接下來,我所使用的csv文件如下:

【技術分享】逆向分析Aura睡眠鬧鐘

我的伺服器託管了下列運行文件:

【技術分享】逆向分析Aura睡眠鬧鐘

不出所料,攻擊是成功的,我也拿到了root SSH訪問權,我所使用的腳本可以點擊【這裡】獲取。


藍牙與遠程代碼執行


通過進一步的分析之後,我在Aura的藍牙功能中發現了一個安全漏洞,攻擊者將能夠通該漏洞並利用Aura的藍牙協議來觸發緩衝區溢出漏洞,並對設備實施攻擊。

攻擊PoC視頻:

視頻地址:https://courk.fr/wp-content/uploads/0x00_packet_replay_demo.webm

如需了解完整的測試過程以及實驗結果,請觀看下面的演示視頻:

視頻地址:https://asciinema.org/a/44cmj41uh1q7lwkp9lrc9clc5


總結


多虧了Aura的HTTP流量是明文數據,因此我才可以如此輕鬆地獲取到Aura所使用的系統固件,從而我才有可能獲取到Aura的root許可權並發現了其中的兩個安全漏洞。

首先是第一個漏洞,我通過MITM(中間人攻擊)獲取到了SSH的root訪問權,並成功運行了我自己的代碼。另一個漏洞則更加嚴重,在該漏洞的幫助下,攻擊者將能夠通過藍牙直接在目標設備商運行自己的惡意代碼。

不過別擔心,正如本文前面所說的,這裡所介紹的漏洞都已經被成功修復啦!由於篇幅有限,詳細的漏洞分析過程請參考原文。


【技術分享】逆向分析Aura睡眠鬧鐘 【技術分享】逆向分析Aura睡眠鬧鐘

本文由 安全客 翻譯,轉載請註明「轉自安全客」,並附上鏈接。
原文鏈接:https://courk.fr/index.php/2017/09/10/reverse-engineering-exploitation-connected-clock/