2021看雪SDC議題回顧 | 基於模擬模擬的藍芽協議棧漏洞挖掘

Editor發表於2021-11-01

藍芽協議棧在IoT安全中的重要性不言而喻,妥善的利用模擬技術能巨幅提高研究效率,並減少對工具、環境的依賴性。


賈舵先生的議題以NRF52平臺的模擬為案例,深入淺出的介紹瞭如何結合虛擬模擬技術對物聯網中的藍芽韌體進行全狀態的模擬,實現動態執行與除錯,並且進一步就模擬器在實際漏洞挖掘應用中的實踐經驗進行分享。


下面就讓我們來回顧2021看雪第五屆安全開發者峰會《基於模擬模擬的藍芽協議棧漏洞挖掘》此議題的精彩內容。


圖片


演講嘉賓


圖片


圖片

【賈舵-阿里安全IoT安全專家】


賈舵:阿里IoT研究團隊安全專家


專注物聯網安全、汽車安全、虛擬化模擬技術的應用。



演講內容


以下為速記全文:


各位來賓朋友大家好,我叫賈舵,目前在阿里做IoT的安全研究,今天我跟大家分享的議題是《基於模擬模擬的的藍芽協議棧的漏洞挖掘》。議題分為五個部分,首先是做一個背景介紹,第二部分是我們模擬技術的實現,然後是模擬在我們漏洞挖掘中的應用,第四部分是案例展示,最後會做一個總結。



背景介紹


首先第一部分是我們的背景介紹,這部分會介紹兩個內容:一是我們的IoT藍芽協議棧;第二是我們為什麼要去做模擬?


我們的智慧裝置目前的話是有兩個明顯的一個發展方向,一個是朝著我們功能化的方向,這裡面典型的有我們的路由器,還有智慧音響、智慧電視,以及現在比較流行的智慧汽車。


另外一個方向是我們的可穿戴的方向,它逐漸是向這種小型化的一個方向發展。這裡面典型的有我們無線的耳機,還有運動手環等。在這些裝置裡面的話,其實我們的藍芽的應用是非常廣泛的,承載我們藍芽功能的是藍芽協議棧,我們今天針對的是我們可穿戴方向的藍芽協議棧,為了區分,我們稱之為IoT的藍芽協議棧。


根據它的一個應用場景的一個不同,我們 Iot的藍芽協議棧它會區別於我們的 PC或者是作業系統,它會有一些自己的特點。


對於我們執行IOT藍芽協議棧的一個平臺,它的資源是非常有限的,體現在它的一個 CPU的資源上,還有的話是它的一個儲存限制,這樣要求協議棧往往是一個非常輕量化的實現。那麼同時的話我們iot裝置往往會要求一些實時性,那麼需要一個快速的響應的能力,同時我們無線的裝置往往是用移動的電池來供電,所以的話它會有一些低功耗的特性。


正是因為有這些特點的話,所以我們實際在做 IoT協議棧的應用的過程中,它往往會和我們的硬體去結合在一起,也就是我們的藍芽SOC。我們常用的一些藍芽SOC包括nordic的nrf52系列,還有 TI的CC系列。藍芽協議棧其實是我們物聯網中基礎的一個元件之一,它的一個漏洞的話往往會影響到一個範圍的裝置。


圖片


我們今天其實要講的是通過模擬的方法去對它做一個漏洞挖掘方法的闡述。這裡面就有一個問題,就是我們為什麼要去做一個模擬?我們模擬的一個目的其實是為了解決我們物理世界的阻礙因素,建立一個我們理想的虛擬世界。


圖片


當我們採用一個新的方法的時候,一定是傳統的方法給我們帶來一些不利的因素,實際上我們在做藍芽的漏洞挖掘的過程中會面臨一些困難,主要體現在幾個方面。


首先的話是一個環境的干擾,我們周邊的話其實有很多這種2.4G的裝置,包括我們的耳機或者滑鼠鍵盤,同時還有2.4G的wifi,會形成一些干擾;然後就是藍芽自身跳頻的一個影響,這會直接影響到我們對資料的一個監聽。那麼對於BLE藍芽來說的話,我們可以對它的廣播通道做一個非常好的監聽,但是對它的資料通道的話,如果我們做一個真正的旁路監聽還是比較困難的。



模擬技術實現


第二個部分是我們除錯上的困難。我們如果想去通過硬體去建立一個完整的一個除錯環境的話,還是有一定難度的,主要受限於硬體對除錯的一個限制,還有就是硬體自身的一個熔斷機制。第三個方面是我們工具的一個依賴性,在我們漏洞挖掘的過程中會應用到很多的工具軟體和硬體,我們很多精力要去做這個軟體跟硬體的穩定性的維護,這就導致我們沒有辦法去專注資料本身的一個操作。


另外工具的依賴性也會造成我們測試範圍的受限,這個圖的是我們 BLE藍芽的一個協議結構圖,我們常用的一些測試的工具,比如說nrf52 dongle和cc系列的dongle,還有一些USB藍芽的介面卡的話,他們是基於一個hci介面來控制,我們 PC端的話可以通過一些協議棧的工具去做一個訪問,那麼最後實現對我們應用的屬性藍芽屬性的一個讀和寫。


那麼這裡面的話,因為我們這些工具其實是建立在物理層和鏈路層上的,鏈路層的邏輯其實是固化在我們的硬體工具當中的,這就導致我們沒有辦法對鏈路層去做一個測試。那第二個的話就是我們這些工具的話,一般是通過 hci介面來去訪問的,hci介面本身它是一個功能性的介面,它並不是一個測試介面,所以本身也會受到一些限制。我們通過模擬的手段就是為了將我們一些複雜問題簡單化,這個圖的話是我們在物理環節中想對藍芽協議棧的測試場景,這裡面可能會用到一些軟體無線電或者ubertooth等。


對於我們這個圖的本質,其實是為了做藍芽資料的一個互動,對於我們安全研究者來說的話,我們最希望的其實是有一個介面,通過這個介面的話做協議的一個互動,達到我們測試的過程。


實現這個過程的轉換,其實就是我們需要做的模擬實現的部分,也就是我們第二個內容要講的模擬技術。這一塊的話我會講兩個內容,一個是對我們模擬物件的分析,第二個是我們模擬的設計方法。


首先剛才我們講了幾個藍芽的SOC的平臺,這裡面我們會以 nrf52作為對標的模擬物件,這裡面有一些引數可以看一下,在這裡面我們其實最關心的還是協議棧的問題。


nrf52平臺目前有兩個應用比較廣泛的藍芽協議棧,一個是 softdevice,這是nordic官方的一個協議戰,是有商業化的。


第二個的話是一個開源的協議棧叫Zephyr,這個也是非常活躍,由現在的一個社群去維護的。這是我們整體的一個設計思路,我們模擬器的話是基於 qemu5.1的版本,建立在 arm的架構的模擬基礎之上,我們模擬的目標是基於Zephyr和SoftDevice的應用韌體,當然也可以包含我們普通的基於這個平臺的韌體,那麼具體怎麼實現?


從硬體的一個角度來講的話,我們的韌體其實可以分為兩個層次,一個部分是我們韌體裡面其實是大量的這種arm的指令,這些指令的話它會對我們的特定的一些資料做一些讀寫的操作,形成我們對外設的訪問。


這些外設的話可能會包括比如GPIO、I2C或UART這些,我們要實現一個模擬的話,首先我們要對它的一個CPU的核心做一個模擬,qemu目前已經對Cortex-M4的一個核心做了支援,我們可以直接拿來用。


以此為基礎,我們可以做一些基礎硬體模擬的擴充套件,包括記憶體中斷還有暫存器,但是這些還是遠遠不夠的。


圖片


在模擬實現的過程中,最重要的是我們 SOC外設的模擬,對外設模擬其實是區分我們模擬器是不是能夠用在MCU上的重要指標,模擬器是針對於PC的還是針對於MCU的,很關鍵的就在於外設的功能,這一塊也是我們後面重點會去模擬的一個物件。我們模擬的物件是一個韌體,所以我們首先要對韌體做一個分析,這裡面還是以 SoftDevice的協議棧為例,一個使用SoftDevice作為應用的一個完整部件,它的結構是這樣的,會包含兩個部分,一部分是我們的應用層的程式碼韌體,然後第二部分是協議棧本身,他們之間會通過一個svc的指令去做一個呼叫,SoftDEvice其實就是我們協議站實現的一個部分,它是不開源的,所以需要我們去做一個逆向分析。


通過分析,我們要確定我們模擬什麼以及模擬到什麼程度,首先我們要知道我們模擬什麼,這裡面的話其實要去知道的是它使用了哪些外設,對於硬體來說的話,特定的外設其實是對映到特定的地址上,根據這個特點的話,我們可以通過資料手冊去查詢他用了哪些外設,然後做一些統計。單純知道這些的話還是不夠的,那麼對於我們每一個外設來講的話,它的邏輯還是非常複雜的。


圖片


對於 IoT協議棧來說,為了實現一些非常高效的一些操作,往往會跟我們的硬體做一些聯動和結合。因此的話我們要對一些關鍵的邏輯去做一個逆向的分析,這裡面是對它的一個廣播的邏輯,藍芽的廣播做了一個逆向分析以後的結果,在廣播的邏輯當中,它使用了三個主要的外設,分別是 RTC、Timer定時器,還有 Radio的一個功能。廣播它其實是有一個廣播週期的週期,一般會在60毫秒到1秒之間,這個是由RTC模組來維護的。


同時對於單個的一個廣播週期內的話,也有它會在三個不同的通道上進行廣播,這一部分是由 timer來維護,對於我們radio的話,它主要是做資料的收發處理,當我們有藍芽資料請求過來的時候,他要做一個response的操作,這裡面我們講到的這三個模組,是通過我們的硬體事件、硬體的中斷,還有PPI這三個部分進行一個連線的,PPI是我們 nrf52裡面特有的一個外設,它的一個功能是可以實現把我們硬體的事件和我們硬體的動作進行一個連線。


這樣的話其實就可以實現一個自動化的操作,實際上在整個的廣播的邏輯當中,80%的工作是硬體自動來完成的,從另一個角度來說,也就是說我們80%的邏輯需要我們去做模擬的一個實現。


圖片


在對這個部件的分析過程當中,我們也發現了一些反除錯的現象,它的基本的邏輯是這樣的,當我們在做除錯的過程中,在我們斷點以後,我們的PC指標它停止了,它的指令流停止了,但是它的硬體外設其實還是在跑,這裡面典型的就是一個定時器,定時器在執行的過程中它會產生一個時間差,時間差如果被我們的韌體去檢測到的話,它會產生一個錯誤。具體的話其實是兩種表現形式,一種的話它會直接讀我們的定時器的一個數值做一個比較,第二種的話就更隱蔽,它會設定一個預期的值。


那麼在檢測點去檢視這個有沒有一些超時事件。反調式怎麼會影響到模擬的實現,是因為我們在模擬的過程中,其實所有的模擬器其實它的模擬的速度其實是不均等的,這樣的話就會產生一個時間差,這個時間差的話在一定概率上就是觸發這些問題。


那當然我們針對這個也做了一些解決的方法,因為誤差是是我們模擬導致的,所以可以通過提高硬體的一個精度,模擬的精度來解決。還有的話我們可以適當的去降低定時器的一個頻率,增加時間的一個冗餘。


最後,我們也可以去對它的特定的一些邏輯做一些補丁或者修改,實際上在最後的模擬實現過程當中,從結果來看,我們只需要做一處的這種補丁,所以的話最後它整個韌體的話還是比較完整的。

圖片


這是我們韌體分析以後統計的這些外設的一個模擬的情況,實際上最後我們是對13個主要的外設做了模擬,外設功能的覆蓋度達到了80%,這個程度已經完全可以支撐我們協議棧韌體的執行,這些外設裡面其實可以分為兩類,一類是我們強依賴的外設。


就是說我們必須要去實現,如果不實現的話,我們的韌體可能會卡死或者是報錯,或者說進入一些非預期的一些邏輯,這些是我們不希望看到的。


第二個的話就是通訊介面,通訊介面的話它反映在我們的韌體跟外部的裝置的互動上,典型的是我們的SPI的介面還有I2C的介面,當然也包括藍芽介面。


圖片


那麼這些外設具體是怎麼實現?首先外設模擬的本質是對地址讀寫的一個例項化,我們韌體對我們硬體的一個訪問往往是通過特定的一些地址讀寫來操作的,所以的話我們要實現模擬的話,其實是對讀寫過程進行賦能。


我們在模擬的過程當中,我們對韌體的一些讀寫操作會進行過濾,通過模擬器的一些callback的機制,然後過渡到我們外設的實現當中,我們的外設實現過程當中,除了要對這個地址的讀寫進行資料的一個反饋,還有儲存的話,其實最關鍵的其實要對他它讀寫硬體行為做一個模擬,這是我們非常核心的一個部分。


圖片


在所有的外設裡面,其實我們最關心的還是藍芽,實現藍芽的一個模擬的話,其實是實現它的一個組包跟拆包的一個過程,它的組包跟拆包其實發生在我們的硬體層,因此在硬體模擬的時候,我們就可以做一個組包拆包的實現,其實我們模擬的是藍芽的一個物理層。但是對於藍芽來講的話,僅僅這些還是不夠的,因為藍芽它不可能去單獨的存在,它一定是兩個或兩個以上的裝置存在的,因為它要建立一個連線的互動,那麼這裡面的話我們通過一個介面來實現,通過 interface介面來實現。


那麼對於這個介面的話,基於介面協議,可以在模擬器的主體外部去做一些指令碼的程式設計,從而我們對藍芽協議的一個通訊。這個結構其實也是有一定的靈活性跟擴充套件性的。基於這個介面的話,我們除了藍芽,我們還可以擴充套件一些其他的外部裝置,比如說spi的flash,還有一些按鍵互動,甚至還有 LCD的一個顯示。這是我們模擬以後藍芽資料的一個體現,它是一個我們自己定義的json的格式是一個非常易讀的。


圖片


這裡面我們一個具體的例子來講解,那麼這是一個真實的韌體模擬的案例,那麼對於這個韌體的目標裝置,它其實外面接了兩個晶片,一個spi flash用來儲存一些資料,還有I2C的控制器用來做一些機械的控制,當然還有藍芽的通訊。我們在做裝置模擬的過程中,我們可以基於一些高階的語言去來做程式設計,一般安全人員喜歡用這種Python的格式,我們可以用Python來實現三個裝置的模擬,進而實現一個電路級別的模擬。


那麼它模擬的結果是什麼樣的?這裡面我列舉了一些它的資料日誌,從這一點來看,我們可以看到韌體對我們spi flash還有 I2C的資料的一個讀寫,這裡面比較關鍵的就是我們藍芽的資料,藍芽大多數它還是一個 client server的模型,我們這裡面也是用一個方向進行了標識。


剛才介紹的就是我們模擬實現的一個過程,分別講了我們模擬器主體的一個實現,還有我們外部裝置的模擬。



漏洞挖掘方法


下面的話第三部分就是講模擬技術如何應用到漏洞挖掘中?

圖片


首先,模擬在藍芽漏洞挖掘當中其實有兩個非常直接的意義,首先說可能給我們建立一個比較好的動態分析的環境,第二個的話就是可以高效率的建立自定義互動資料。


這是我們虛擬環境中的一個概況,這裡麵包含幾個部分,首先是物理裝置,物理裝置可以認為是我們的被挖掘的真實的裝置,或者說我們可以理解為韌體,那麼模擬器主體的話就是我們 CPU的模擬,還有外設的一個模擬實現,外部裝置的一個模擬就是我們剛才講的基於通訊介面來做的,比如說LCD或者flash或者eeproom這些,同時的話針對外部裝置的模擬,我們也會增加一些視覺化的一個輔助,這樣的話更形象的把我們韌體所對外表現出來的行為進行一個直觀表現。


作為一個安全研究者的話,其實是模擬器的一個使用者,那麼我們韌體在模擬的過程中,它與外界的所有的互動都會通過 interface介面來體現出來,我們安全的人員可以去介面去做監聽或者分析,還有進一步的做修改和反饋,達到測試的目的。


圖片


那麼具體針對這個介面,我們從藍芽來講,這裡面主要是有兩種表現形式,一種是Guest to Geust,首先Guest的意思就是說是我們的模擬器,其實這是一箇中間人模擬的場景,我們需要同時模擬兩個韌體,分別是韌體一還有韌體二,同時通過一箇中間的指令碼對他們所產生的藍芽資料做一個連線,在這個連線過程當中我們就可以去過濾我們感興趣的欄位,然後去做一些修改,甚至做一些重複的一些操作,這種場景的話就比較適合我們同時對藍芽的中心裝置,還有外圍裝置去做同步的這種分析。


圖片


第二的話是Guest to Host,它是一種點對點的模擬,Host指的就是我們的 PC端,在這裡面的話我們只需要模擬單一的一個韌體,同時的話基於我們剛才講的介面協議,我們可以編寫一些測試指令碼,這裡面的話是對BLE藍芽的connect請求的一個fuzz的一個場景,它其實是對我們連線資料包中的AccessAddr,還有ChannelMap的欄位做了一個fuzz的測試。


同時我們的模擬器在對這個漏洞的驗證,還有除錯的過程中也是支援比較好的。首先我們直接可以基於 shell環境來做漏洞的驗證,對於已知的一些CVE的話,我們可以直接在命令列裡面跑,即使一些複雜的話,我們其實也可以編寫一些簡單的指令碼來做。


圖片


我們對除錯的一個支援,還是基於 qemu的 GDB除錯。我這裡面我們做了一個東西,就是說把程式的斷點跟我們的硬體模擬做了一個強繫結。當我們這個斷點的時候,我們的硬體狀態其實是真正的去暫停了,像我們剛才講的這種基於時間的這種反除錯的話,它就不再起作用,起到了一個去反除錯的效果。


我自己的話也是基於這些方法去做了一些研究,然後發現了一些問題,這些這幾個漏洞的話都是非接觸式的漏洞,因為今天我們主要還是以概括的方法為主,所以對於這一部分就不做詳細的介紹。



案例演示


第4部分是做一個案例的演示,我們剛才講了,其實藍芽模擬互動有兩種方式,這裡面也會有兩個演示,首先是一箇中間人的案例,中間人的話肯定是一個三個角色去存在的,首先這裡面我們要有一個藍芽的中心裝置,然後第二個的話是藍芽的一個周邊裝置,然後我們通過一箇中間指令碼把這個資料做一個互動的連線,從而建立兩個韌體的一個通訊,實現一個連線。基於這個的話,我們可以針對特定的去報文去做一個修改和重放。


圖片

(此處為視訊,點選文末閱讀原文前往下載ppt檢視)


中間人的這種場景的話,其實如果我們在物理環境中想去實現的話,其實目前來看還是比較困難的。


然後第二個案例:


圖片

(此處為視訊,點選文末閱讀原文前往下載ppt檢視)


這個案例的話我們是找了一個具體的漏洞,這裡面的話首先我們去執行一個有漏洞的韌體,然後我們去執行我們驗證指令碼。這是一個鏈路層的漏洞,在模擬器裡面是非常容易去驗證的,但是在我們物理環境中其實還是有一定困難的。原因就在於我們剛才講的就是鏈路層的一個邏輯,很多是固化在我們的工具韌體本身的,這樣的話我們如果在物理環境中想去做驗證的話,很多時候需要去做對做一些SOC的程式設計和工具韌體的修改。



總結、規劃


最後的話是對我們今天講的內容做一個總結。


圖片


首先我們今天講了一種嵌入式平臺的這種精確模擬的一種方法,我們今天通過 nrf52還有藍芽協議棧對我們模擬技術在漏洞的挖掘、驗證,還有分析過程當中的實際意義其實做了一些闡述,從結果來看,我覺得還是比較樂觀的,模擬技術在實際的安全研究中,能夠增加研究的便利性,併為真實環境提供有價值參考。


實際上除了藍芽協議棧,同樣適用於普通的MCU韌體和RTOS韌體的模擬,也可以應用在RTOS和普通MCU韌體的軟體上的漏洞挖掘,整體的思想和方法是一致的。都是以模擬為基礎和出發點,講測試資料附加到程式碼執行過程中,實現一個測試的目的。


實際上關於這部分研究後續仍然有很多工作要做,未來會增加新的硬體平臺和IOT協議棧的模擬,不侷限於nRF的平臺和藍芽協議棧另一個,因為MCU的型別和架構是比較雜亂的,需要新的MCU架構的模擬,目前已經對STM8這個MCU架構做了全面的支援。基於藍芽通訊的這種框架,可以模擬更多的外部裝置,最後實現一個外部裝置的集合庫。進一步的會使得模擬過程更便利和具有靈活性,這部分開發會獨立於模擬器本身,作為一個擴充套件。


模擬技術在IOT的批量化的漏洞分析、驗證、自動化漏洞挖掘中是有優勢的,為了發揮模擬技術最大的優越性,後續會考慮增加一些漏洞檢測的工具進來,去覆蓋一個漏洞的管理週期。同時的話我們會對它的外部裝置做一個擴充套件的集合,那麼模擬技術其實在我們自動化跟批量化上其實也是非常有優勢的,後面的話我們可能會考慮結合溝通的檢測工具進行。


圖片


最後對目前我們團隊的專案做一個介紹,目前我們團隊在做一個IoT-Matrix的專案,這張圖是它的一個技術路線。首先這個專案是針對IOT裝置的漏洞驗證和挖掘的應用場景,目標是實現對一切IOT裝置韌體的模擬,包括基於linux-base的模擬,和硬體裝置的全模擬。


IoT碎片化是比較嚴重的,為了解決這個問題,我們也劃分了很多分支路線,今天分享的內容其實是IoT-matrix中的MCU的模擬一個案例。實際上去實現模擬一切的目標其實還是非常困難的,還有很多東西要做,對這些東西感興趣的話也可以跟我們去做一個交流和溝通。

相關文章