第一隻WiFi蠕蟲的誕生：完整解析博通WiFi晶元Broadpwn漏洞（含EXP／POC）

新聞 08-06

過去的幾個月里，Android 和 iOS 數十億台設備中都曾出現過可怕的 WiFi 遠程代碼執行漏洞 BroadPwn。谷歌 7 月初發布了修復補丁，而蘋果則是在 7 月 19 日發布的更新。而此次開得熱火朝天的 Black Hat 2017上安全研究員 Nitay Artenstein 也針對這個漏洞進行了詳細剖析。

Broadpwn 漏洞甚至還能進化成 WiFi 蠕蟲，如果你的移動設備沒有及時更新，只需置身在惡意WiFi範圍內就會被黑客捕獲、入侵、甚至被轉化成惡意AP、繼續感染附近的手機終端…

目前漏洞雖然已經得到修復——但這個漏洞的研究過程也許能給安全研究和防護帶來深層次的思考。所以，本文按照黑帽大會上進行的分享及分享者的博客內容進行了整理，希望能給大家帶來幫助！

不需要用戶交互、完全遠程利用的漏洞，已經消失匿跡了一段時間了。這種漏洞在一些不夠安全、或者說未能及時更新的設備上找到，（如路由器、IoT設備或者舊版 Windows 上），但在 Android 及 iOS 上，實際並沒有可以遠程利用並繞過 DEP 及 ASLR 保護機制的漏洞。如果想要侵入 Android 或 iOS設備，攻擊者一般還是通過瀏覽器漏洞進行。從這個角度切入的話，我們可以從攻擊者的視角進行思考，也就是說，有效的漏洞利用需要用戶主動點擊可疑鏈接、連接到攻擊者的網路、或者瀏覽不受 HTTPS 保護的站點。然而，警覺性高的用戶就不會上當。

隨著現代的操作系統不斷加強安全防護，攻擊者很難找到全新而有力的攻擊向量。當然，遠程漏洞利用絕非易事。常見的本地漏洞利用都會利用各種特定系統上的介面（如本地的系統調用或者Javascript ），通過各種交互操作觸發，這樣攻擊者可以獲取涉及目標的地址空間以及內存狀態的信息。而遠程攻擊者，在與目標的交互手段上會有很大的限制。為了成功實施一次遠程攻擊，攻擊者所使用的漏洞需要在各種情況下都具有普適性。

本研究的目標在於揭示這種類型的攻擊以及漏洞利用—— Broadpwn 是一種完全遠程的攻擊，它通過博通 BCM43xx 系列 WiFi 晶元組的漏洞在 Android 或 iOS 的主應用程序處理器上進行代碼注入。

本文的敘述將會如下流程展開：首先是按照思考流程解釋我們如何選擇適合遠程利用的攻擊面，接著解釋為了避免需要用戶交互的觸發，我們如何在特定程序塊中進行調查、最後是如何形成一個可用且完全遠程的漏洞利用。

文末還會有個

[ 彩蛋 ] ：

在二十世紀初期，自傳播的

蠕蟲

惡意程序很常見。但隨著 DEP 和 ASLR 的出現，這種遠程 exp 逐漸消失，2009 年的 Conficker 成為了歷史記載中最後一個自傳播的網路蠕蟲。而利用當前的

Broadpwn

我們可以延續傳統（:P），將其改造成第一個針對移動設備 WiFi 的蠕蟲、同時也是近八年內的第一隻公網蠕蟲。

一、攻擊面分析

DEP 和 ASLR 是攻擊者最恐懼的兩個詞。一般為了利用漏洞進行代碼注入，我們需要獲取涉及地址空間的信息。但自從有了 ASLR 機制的存在，這些信息就很難獲取，有些時候需要通過單獨的信息泄露漏洞才能獲得。以及，普遍意義上遠程利用信息泄露漏洞，會比普通情況更難，因為目標與攻擊者的交互十分有限。在過去的近十年來，有數百個漏洞因此凄慘「死去」。

當然，嵌入式系統中不會存在這樣的問題，路由器、攝像頭、各種IoT設備都不會有專門的安全防護機制。但談及智能手機，情況就又不一樣了：

Android 和 iOS 都很早就應用 ASLR 機制了！

但直接這樣說其實還是有不準確的地方的，因為這些機制只是針對主應用處理器進行保護——然而智能手機本身是一個複雜系統！於是我們在進行研究的時候開始思考，手機上還有哪些不受 ASLR 保護的處理器呢？

實際上，大多數的 Android 和 iOS 智能手機都還有兩個額外的處理晶元，這是考慮遠程攻擊的極好的突破口——

基帶晶元

和

WiFi 晶元

。

基帶晶元

涉及的領域很寬泛也很奇妙，毋庸置疑會吸引很多攻擊者。但是，攻擊基帶也是相當有難度的事情，因為生產廠家各不相同，攻擊不得不變得非常零碎。基帶市場目前也面臨著巨大的轉折：多年之前，高通是一覽眾山小的領先者，但現在的市場已經被多個競爭者佔領。三星的Shannon modem在新一代三星手機中得到普及；英特爾的

Infineon

晶元已經接替了高通，成為 iPhone 7 以上版本的基帶；而聯發科技的晶元已經成為低成本 Android 設備最受歡迎的選擇。當然，高通仍然佔據高端非三星 Android 中基帶市場的主導地位。

WiFi 晶元組

則有著另一段故事：但在最主要的智能手機中，包括三星 Galaxy 型號，Nexus 以及 iPhone 在內，博通對它們來說都是最主要的晶元廠商。在筆記本設備中，WiFi 晶元組管理 PHY 層，而

kernel driver

負責處理第三層及以上——這被稱為

SoftMAC 框架。然而在移動設備上，由於對電源的考慮導致設備設計人員選擇應用 FullMAC WiFi 實現方式，這樣 WiFi 晶元是自行負責處理 PHY，MAC 和 MLME ，並自行傳輸準備好的內核驅動程序數據包，這也就是說

WiFi 晶元是會自行處理可能被攻擊者控制的數據輸入

。

在選擇攻擊面的考慮時，還有一個因素影響了我們的選擇。在博通晶元上進行測試的時候，我們欣喜地發現，它不受 ASLR 保護，而整個 RAM 都有 RWX 許可——這意味著我們可以

在內存中的任何地方進行讀，寫和運行代碼的操作！

但是在 Shannon 、

聯發科技、以及高通的基帶中存在 DEP 機制的保護，所以相對而言，更難進行漏洞利用。

二、博通晶元分析

博通的 WiFi晶元是高端智能手機 WiFi 組的主要選擇。在不算特別詳盡的研究中，我們發現以下智能手機的型號使用的是博通的 WiFi 晶元：

部分三星 Galaxy 系列的 S3 至 S8

所有三星 Notes 3，Nexus 5, 6, 6X 和 6P

所有 iPhones 5 之後的型號

晶元的型號則是從 BCM4339 到 BCM4361型號。

晶元固件的逆向工程和調試相對簡單，因為每次晶元重製後的主 OS 都將未加密的固件二進位程序載入到晶元的 RAM 中，由此，只是通過手機系統的簡單搜索就足以定位博通固件的地址。但如果在 Linux 內核上，這樣的路徑通常會在配置的變數 BCMDHD_FW_PATH 中定義。

我們之後又發現了另一件讓人高興的事情，固件上並不會對完整性進行檢驗，也就是說攻擊者可以輕鬆地對原始固件進行修改，添加 hook 進行列印輸出調試或者其他行為修改，甚至修改內核來調用我們自己的固件。我們在研究的過程中就經常地放置 hook 並觀察系統的行為（更有趣的是系統的不正常行為）。

我們調查中的博通晶元都運行的是

ARM Cortex-R4 微控制器。這個系統的奇怪之處在於，大部分代碼都是在 ROM 上運行的，大小為 900 k。而後續的更新都是存放在 RAM 中的，也占 900 k 的大小。在執行更新或修復的時候，在 RAM 中會有一個附加的 thunk 表，然後在執行的特點位置進行調用這個表。如果有錯誤需要進行修復，則可以對 thunk 表進行重定向指向新代碼。

而在架構方面，將 BCM43xx 視為 WiFi 片上系統（SoC）應該是正確的，因為這裡有兩個不同的晶元在處理包數據。主處理器

Cortex-R4 在將收到的包數據交給 Linux 內核之前，會先處理 MAC 和 MLME 層的數據；

但使用專有博通處理器架構的單獨晶元則可處理 802.11 PHY 層。SoC的另一個組件是應用處理器的介面：早期的博通晶元使用的是較慢的 SDIO 連接，而 BCM4358及更高版本使用的 PCIe。

WiFi SoC 中的主要 ARM 微控制器運行著 HNDRTE 這個神秘的專有實時操作系統（RTOS）。雖然 HNDRTE是閉源的，但也有地方可以獲取到之前版本的源碼。之前的研究人員提及

Linux brcmsmac 驅動程序——它是

SoftMAC WiFi晶元的驅動程序，只會處理 PHY 層的數據，並讓內核去執行其他操作。儘管這個驅動中卻是包含HNDRTE的常用源碼，但我們發現數據包處理的驅動程序代碼（我們希望找到漏洞的部分）與固件中的還是明顯不同，因此這樣的嘗試並沒能幫上我們。

最有用的資源則是

VMG-1312 的源代碼，

VMG-1312 也是使用博通晶元組的路由器，雖然這個產品早已被人們遺忘。儘管之前的

brcmsmac 驅動中包含博通開源使用在 Linux 上的代碼，但在

VMG-1312 中居然包含有博通專有的閉源代碼，可以看到代碼上標註了「這是博通未公開的專有源代碼」警示信息。顯而易見，這是博通代碼不小心混在 VMG-1312 源碼中錯誤公開了！

這些泄露的代碼片段包含我們在固件 blob 中找到的大部分功能。但這部分還是有些過時，沒有包含最新的 802.11協議的相關處理方法。但我們找到的這部分對於此次研究已經非常有用，主要的數據包處理功能並沒有發生大的變化。我們通過將源代碼與固件進行比對，能夠快速地獲取數據包處理代碼部分的整體概念，幫助我們尋找到值得關注的代碼區域，並將關注點移到下一個階段上——如何找到合適可用的漏洞。

三、漏洞在哪

在此確認一下「合適可用的漏洞「的定義，我們認為，當前所需要尋找的漏洞應當滿足以下的要求：

1. 這個漏洞不需要攻擊目標進行交互觸發

2.不需要我們了解系統的當前狀態，因為遠程攻擊並不能了解足夠多的信息

3.成功利用後，這個漏洞還是能讓系統保持在穩定狀態

從那裡開始思考呢。我們可以先簡單回顧一下 802.11 連接過程。這個過程從客戶端發起，在 802.11 lingo 中稱為移動工作站（STA），會對附近所有的接入點（AP ）發送探測請求（Probe Request）來進行連接。然後探測請求中會包含兩種數據，其一是 Supported Rates（移動工作站支持的速率）；其二是該站點之前連接上的 SSID 列表。而在下一個過程中，支持對應速率的 AP 會發送一個探測響應（包含支持的加密類型等數據）。之後，STA 和 AP 都會發送身份認證信息數據包。而在最後一步中，STA 會發送關聯請求（Association request ）給選擇連接的 AP 。

在上述過程中的數據包都有相通的結構：基本的 802.11 報頭，然後是一些 802.11 信息元素（IE）。信息元素都是以眾所周知的 TLV 進行編碼，第一個位元組標註信息的類型，第二個位元組保存長度，最後的位元組保存實際的數據。通過解析這個數據，AP 和 STA 都可以在連接過程中獲得對方的需求和性能信息。

任何實際認證，如使用 WPA2 的協議進行的認證，都發生在此連接過程之後。由於在連接過程之中並沒有真實的認證元素，所以攻擊者可以使用 MAC 地址及 SSID 模仿稱任何的 AP。STA 只能在下一步的認證過程發現這個 AP 是偽造的。這個特性使得連接過程的這一步中出現的 bug 是非常珍貴的。在連接過程中攻擊者如果能發現 bug ，就可以嗅探到目標設備的探測請求，偽裝成 STA 在搜索的 AP ，然後無需認證即可觸發漏洞。

博通代碼高度模塊化地處理 802.11 中不同協議及固件中函數這一點，也給我們尋找漏洞提供了便利。在

wlc_attach_module 函數中，它將不同的協議和功能抽象成一個單獨的模塊。

wlc_attach_module 調用的

各種初始化函數的名稱能夠給一些指導，下面是例子：

在模塊初始化函數之後才是相關處理操作的程序部分，每次產生或者收到數據包時都會調用這些函數來進行處理。他們會負責匹配接受到分組數據的上下文，或生成用於輸出分組的協議數據。我們會更在意協議數據，因為這是解析攻擊者控制的數據代碼，相關函數在 wlc_iem_add_parse_fn 中，具有如下的原型：

我們很快就可以發現，

wlc_iem_add_parse_fn 在

wlc_module_attach 得到了調用。通過編寫代碼來解析傳遞的參數，我們可以為連接過程的每個階段創建一個被調用的解析器列表。然後通過縮小範圍，提高研究效率，發現問題關鍵。

四、漏洞所在

無線多媒體擴展（WMM）是802.11標準的服務質量（QoS）擴展，使得接入點可以根據不同的接入類別（如語音，視頻或其他）對流量進行優先順序排序。舉例來說，WMM 被用於在對數據流量高需求的應用（例如 VoIP 或流視頻）中使用，以確保最佳服務質量。在客戶端與 AP 的關聯過程中，STA 和 AP 都會以信息

元素（IE）

添加

WMM 支持級別標識到信標、

探測請求、探測響應、關聯請求和關聯響應分組的末尾。

在我們分析由 wlc_iem_add_parse_fn 安裝之後解析關聯數據包的函數中的 bug 時，我們偶然發現了以下的函數：

最後一行的程序調用了 memcpy()，卻沒有驗證緩衝區

current_wmm_ie 是否能容納數據

ie->len 。現在把這個問題稱為 bug 可能還為時太早：讓我們先看看現在分配給

current_wmm_ie 的大小，調查一下是否會引起溢出。然後我們可以在分配緩衝區的函數中找到答案。

current_wmm_ie 緩衝區的大小為

0x2c（44）位元組，而整個 IE 的最大尺寸為

0xff (255) 位元組，這意味著我們可以得到的最大溢出可以達到 211 位元組。

但這樣的溢出不一定會讓我們實現目標。以前的

CVE-2017-0561（TDLS 問題）很難利用，因為攻擊者最多只能溢出到下一個堆，也還需要很複雜的堆技巧

來獲得寫入原語的權利，同時破壞堆的狀態及恢復執行還會更難。據我們目前所知，現在這個 bug 可能也會這樣叫人白費力氣，所以需要先仔細看看這裡溢出的是什麼。

假設

malloc() 函數自頂向下分配內存塊，通過查看前文的代碼中搜索，我們可以發現

wlc->pm 結構體就會分配到存儲空間，緊挨

wlc->current_wmm_ie 結構體（溢出目標）之後。為了驗證這個假設，我們把

current_wmm_ie 轉換成16 進位，在

BCM4359 上進行測試的話可以發現——它總是會分配在

0x1e7dfc 位置：

看一下 0x2c ，這裡是

current_wmm_ie 的末尾，我們可以看到下一個堆塊的大小

0x7a ——這也是

wlc->pm 結構體加上兩個位元組大小的間隔所佔的大小。所以我們的假設是正確的：

溢出只能用在

wlc_pm_st 類型的結構體

wlc->pm 中。

但值得注意的是，

current_wmm_ie 和 pm 的

位置是靜態的、完全固定的。由於這些結構在初始化過程中得到了提前的分配，他們會始終被分配到相同的內存地址。這個特點可以讓攻擊者在這一步不用思考複雜策略。

五、漏洞利用 Exploit

找到漏洞還算是輕鬆的部分，寫一個可靠的遠程利用方法更艱難一些，有時發現的漏洞很難被利用。

編寫遠程攻擊的主要困難在於需要攻擊目標的地址空間信息，其次是有些小錯誤會導致不可收場：在內核遠程攻擊中，任何錯誤步驟都會導致內核恐慌，受害者就會接到警告消息。

而在博通 Broadpwn 之中，這些困難之處萬幸都能夠解決：首先，在漏洞利用中我們用到的相關結構體的地址和數據都在固件中是給定的，這樣，我們不需要進行動態地址分配的處理。其次，晶元

崩潰

不會帶來很多雜訊，用戶只會看到在用戶界面上的 WiFi 圖標消失，晶元複位時會出現暫時的連接中斷。

這樣我們就可以

針對這個固件

順利地建立地址字典，然後不斷啟動 exp 暴力破解出正確的地址集。

我們再來看下如何進行

寫入原語（write primitive）的獲取。溢出的結構類型為

wlc_pm_st 這可以改變電源的管理狀態（進入／離開節電模式）這個結構按照如下進行了定義：

這個結構體之中的四個成員變數很有意思呢，可以被攻擊者利用：pspoll_timer、 wl_timer 類型的 apsd_trigger_timer，pm2_rcv_timer 和wlc_hwtimer_to_t 類型的 pm2_ret_timer。

在處理數據包和觸發溢出之後，函數

wlc_hwtimer_del_timeout 會被調用，同時接收到

pm2_ret_timer 為參數：

我們從代碼中可以看出，通過覆蓋

newto 的值，並指向攻擊者控制的位置，

next->timeout 所指向的

內存位置就可以增加

newto->timeout 的內容。這就是一個 - 在哪裡寫入什麼 - 的原語，但這樣做會有個限制，就是攻擊者必須知道被覆蓋內存位置上的原始內容。

還有另一種限制更少的原語寫入方法，就是通過 struct wl_timer 類型的 pspoll_timer 成員。這個結構體能在相關過程中定期觸發的回調函數進行處理：

從這個函數的末尾可以看到，在這裡其實可以更方便地獲取寫入原語。我們可以將我們存儲在field_1c中的值寫入我們存儲在 field_18 中的地址。這樣，我們可以將任意值寫入任何內存地址，而不會受到前一種方法的限制。

下一個問題就在於，如何將我們的寫入原語用於完整的代碼執行。為此，可以考慮兩種方法：一種是需要我們事先知道固件內存地址（或通過暴力破解獲取），還有一種更難實現的方法。我們先看一下前一種方法。

為了實現寫入原語，

我們需要用控制的內存地址覆蓋 pspoll_timer。

由於wlc-> current_wmm_ie 和 wlc-> ps 的地址對於給定的固件版本是已知且和一致的，我們可以完全覆蓋其內容，因此我們可以將 pspoll_timer 設置為指向這些對象內的任何位置。

為了創建一個虛假的wl_timer對象，

wlc-> current_wmm_ie和wlc-> ps之間的未使用的區域是最理想的選擇。把我們自己偽造的 timer 對象放入，然後讓

field_18 指向我們希望覆蓋的位置（減去14的偏移量），然後在

field_1c 中保存我們需要覆蓋的內容。一旦觸發覆蓋操作，我們只需要等待timer 函數被調用，就會執行覆蓋操作。

再下一步就是需要確定哪個內存的地址是我們想要覆蓋的。在上述的函數中出觸發覆蓋操作之後，立刻會調用用

j_restore_cpsr 操作。這個函數主要就做一件事情：它會在 RAM 的

thunk 表中，

從 thunk 表中提取 restore_cpsr 的地址，並跳轉過去。因此，

通過覆蓋 thunk 表中的 restore_cpsr 的索引，我們可以使我們自己的函數立刻被調用。

目前為止，我們現在已經獲得了對指令指針的控制，並且完全掌握了跳轉到任意存儲地址的權利。整個RAM是 RWX 的，也沒有對內存許可權的限制，這也就是說，我們可以從堆，棧或者任何之中執行任意代碼。但還會有存在一個問題，shellcode放哪裡比較好呢？

我們可以將shellcode寫入到溢出的那個 wlc-> pm 結構體中，但這帶來了兩個難點：首先，空間受到 211 位元組覆蓋的限制。第二， wlc-> pm 結構不斷被 HNDRTE 代碼的其他部分使用，所以 shellcode 在結構體中的錯誤位置會導致整個系統崩潰。

經過了失敗之後，我們意識能用的代碼空間很小：wlc-> pm 結構中的 12 個位元組（不會引發崩潰的唯一位置），在放 SSID 字元串的相鄰結構體中的

32 個位元組（可自由覆蓋）。總計 44 位元組的空間不能容納我們的payload，所以需要找個別的地方。

正確的方案應該是尋找某種操作方法（ spray primitive）：我們需要一種方法來在大塊內存中進行內容寫入，並給我們便利而可預測的位置來存儲我們的 payload。

WiFi 晶元都需要在給定的時間裡處理許多數據包。為此，HNDRTE 提供了D11 晶元和主微控制器通用的環形緩衝方式。包數據通過 PHY 後被重複寫入緩衝區，直到不能再容納，也就是說，新數據包只是簡單地寫入緩衝區的開始部分，並覆蓋了之前的數據。

所以，我們需要做的就是把我們的 payload 廣播傳輸過來，在多個頻道上播放。

隨著 WiFi 晶元反覆掃描可用的 AP（即使在晶元處於省電模式下也同樣如此），環形緩衝區就會被我們的 payload 填充 - 給我們提供了很好的解決方案。

因此，我們將要做的是：在 wlc-> pm 中寫入一個小型的 shellcode ，這樣可以節省堆棧幀（這樣我們才能恢復正常執行），並跳轉到我們存儲的下一個32 位元組的 shellcode 的 SSID 字元串。這個 shellcode 只是經典的 egghunting shellcode，在環形緩衝區中搜索某個數字，指示 payload 的開始，並跳轉過去。