Blueborne

2018-11-22 security CVE Android

Blueborne 為 Armis Lab 提出的八個與藍芽相關的 CVE 弱點 此攻擊無須使用者介入(接受藍芽配對、點擊連結、主動發起請求…)，只需要使用者開啟藍芽功能即可，這聽起來非常高大上好厲害的樣子。

八個 CVE 及其影響分別如下表

CVE 編號 平台 影響
2017-0781 Android DoS or RCE
2017-0782 Android Integer Underflow
2017-0783 Android MiTM
2017-0785 Android Information Leak
2017-8628 Windows MiTM
2017-14315 iOS RCE
2017-1000250 Linux Information Leak
2017-1000251 Linux RCE

Armis Lab 使用 CVE-2017-0781 及 CVE-20170785 來達成 RCE，PoC 在此，下面就描述一下我復現的過程與踩到的坑。

註：這裡的 RCE 若沒有其他 Information Leak 的弱點配合就只能 DoS

Prerequisite

  1. Google Pixel Android 7.1.2(NJH47F,Aug 2017) rooted
  2. bluetooth dongle
  3. Linux-based OS notebook

CVE-2017-0781

由上圖可看到 p_pending_data 為一個 BT_HDR 型態的指標，但在 mempyc 時卻進行了+1 操作導致 heap overflow 一個 BT_HDR 的長度也就是 8 bytes。

CVE-2017-0785

ext_len 為攻擊者可控，故可導致 ext_len 整數下溢(Integer underflow)，在之後的程式碼中rem_len被直接使用來指定回應封包長度進而洩漏了記憶體中的資訊。

Exploit

Android 5.0 之後開始使用jemalloc 相關的 exploit 技巧這裡就先不深究了，Armis lab 的 PoC 已經將這部份都處理好了，只需要將必要的資訊填入即可。

這裡我使用的實驗機是 Google Pixel 刷原廠 image Android 7.1.2(NJH47F,Aug 2017) 從這裡可以找到，並且為了查看 process 的 maps 需要 root，之後大致參考這篇來修改一些必要的 offset，大致步驟如下：

  1. 透過 adb 取得 bluetooth process maps 取得兩比載入位址
  • bluetooth.default.so
  • libc.so
  1. 透過 CVE-2017-0785 取得記憶體洩漏資訊，多做幾次會發現有一個固定的偏移位址，例如我的 BLUETOOTH_BSS_SOME_VAR_OFFSET 是 0xe3f29、LIBC_SOME_BLX_OFFSET 是 0x1a1c1，該值是否跟手機或是不同libary 有關目前不知道，雖然已經盡量使用與 Armis lab 的 demo 影片相近的環境，但手機中取得的 libc.so 與 bluetooth.default.so hash 值仍然跟他們 PoC 中註解的不相同。
  2. BSS_ACL_REMOTE_NAME_OFFSET 為一個存在 bluetooth.default.so BSS 段的資料，只要是新的 bluetooth 裝置請求配對後，裝置名稱會被 cache 在此，Armis lab 巧妙的使用這個來裝載要執行的 payload，要取得該 offset 可以搭配 gdbserver 從 bluetooth.default.so 往後開始找。
  3. 雖然攻擊途徑是藍芽，但 RCE 後取得的 reverse shell 必須要走網路而非藍芽，所以目標裝置與攻擊者必須要在同一個網段下。

Conclusion

  1. 一開始在 root 手機方面卡很久，因為每支手機的官方解鎖步驟都不太一樣所以花了一點時間，但解鎖後才發現這隻手機沒辦法成功 RCE，白皮書中有提到使用藍芽規範中的 JustWorks 可以在無須使用者介入的情況下與目標配對，但某些廠牌的手機這招沒用，手機方面一樣會出現配對提示需要按下確定或拒絕，不確定是否OEM廠有改過相關的 code 的緣故。
  2. 本來開始筆電用 docker 來建攻擊環境，但刷機需要重複開機會導致 USB 連線斷掉後 docker 裡面就接不到裝置了，所以最好都是在本機或是虛擬機上做實驗。
  3. Armis lab 的 PoC 中偏移需要改到兩個以上的地方但卻是重複操作，這邊我自己改了一點簡化流程詳情看 code 做比較就知道了。
  4. 整個攻擊需要複雜的前置準備想要變成一個通用性的攻擊難度非常高。
  5. Armis lab 的白皮書結圖與影片中手機的版本是不一樣的但應該都可以成功，我是依照影片為主。
  6. 要改的 offset 其實就是 CVE-2017-0785 洩漏出來的值扣掉 libc.so 與 bluetooth.default.so 的載入基址。
  7. 嘗試過自己刷 AOSP 但不知道為毛明明版本都一致卻連 crash 都喇不到。
  8. 這次實驗學到最多的好像是刷機 …

References

Relevant Topics


Recent Posts