2023 SDC 議題回顧 | 探索軟體定義汽車的安全攻擊面

隨著軟體定義汽車時代的到來，面向服務的軟體架構(Service-Oriented Architecture)被廣泛應用到現代汽車中。汽車SOA的實現使車載應用開發和整車硬體平臺解耦，車載應用可透過標準化的介面，呼叫汽車域控制器和感測器的能力。本議題深入研究主流SOA架構，透過整車角度發現多個安全攻擊面，能夠繞過系統限制傳送敏感指令，如車門解鎖，獲取敏感資訊等。展示如何透過惡意車載APP結合多個系統缺陷控制車輛，並提出安全建議與修復方案。

下面就讓我們來回顧看雪·第七屆安全開發者峰會（2023 SDC）上《探索軟體定義汽車的安全攻擊面》的精彩內容。

01 演講嘉賓

【曲樂煒：資深安全研究員】

前百度資深安全工程師，曾負責百度AIoT產品安全保障工作，現為某自動駕駛公司安全負責人，負責車路雲一體化產品安全保障、企業網路和資料安全防護體系建設工作。在WiFi、藍芽、核心、安卓系統中均有深入研究，獲得300+ CVE漏洞，多次獲得谷歌安卓、高通、聯發科致謝，被谷歌評為2022年度Top Bug Hunter，是紫光展銳晶片在全球獲得致謝最多的研究員，BlackHat 2021 Europe/2022 Aisa/2022 USA，KCon 2023，5th AutoCS 2023 演講者。

02 演講內容

以下為速記全文：

今天我為大家帶來最後一個議題——探索軟體定義汽車的安全攻擊面，我是演講人曲樂煒，我之前在百度有5年的IoT產品安全保障的經歷，現在做自動駕駛相關的產品安全和企業資訊保安的保障，主要的研究成果是圍繞安卓的生態系統，多次獲得知名廠商的產品安全致謝，在2022年被谷歌評為Top Bug Hunter，相關的研究成果也多次在國內外的安全會議上做分享。

那麼下面進入我們今天的正題，我將從如下4個方面來對本議題展開闡述，分別是背景概述，威脅分析，典型案例，總結建議。

首先來看，整車軟體架構的演變，左邊這張圖是博世在2017年提出的，汽車電子電器架構發展的6個階段，分別是模組化，整合化，集中化，域融合，車載電腦和車雲端計算，這裡，我進行了對應。

傳統汽車，採用的是分散式電子電器架構，ECU之間採用的是模組化，整合化，採用獨立的ECU，並且基於CAN和LIN匯流排進行通訊。

現代汽車，採用的是域集中的電子電器架構，將車劃分為幾大域，比如座艙域，動力域，底盤域等，部分通訊模組採取乙太網進行通訊。

未來汽車，採用的車雲端計算，物理上簡化線束複雜度，採用基於服務化的軟體架構。

智慧網聯汽車發展至今，隨著聯網化和智慧化的發展，尤其是新能源汽車的一股熱潮，未來汽車的時代已經來臨。

下面我們再來看，整車軟體架構的一個案例，就是我們熟悉的特斯拉，我認為特斯拉是真正將軟體定義汽車帶到大家的視野中。

圖中是model3的整車電子電器架構圖，可以看到，特斯拉採用集中式的中央控制器，搭載了四個中央域控制器，比如自動駕駛及娛樂域控模組，右車身控制模組，前車身控制模組，左車身控制模組。

在自動駕駛及娛樂域控模組中，連線了大量的感測器，如攝像頭，雷達，並且提供了輔助駕駛的能力，以及豐富的車載應用生態，如導航地圖，車內娛樂等。透過軟體實現與研發，極大提升了使用者的體驗。

第二個案例則是國內某新勢力造車，從其連線架構圖來看，其具備更加豐富的座艙應用生態，導航，娛樂，診斷，車內控制。其餘外部的互動也更加豐富，如自動充電，手機藍芽的控制，遠端啟動，無鑰匙的解鎖。提供了大量的遠端控制功能，並且具備各個模組的OTA能力。

這裡則是一組對比，左圖是我在18年買的長安CS 15的內飾圖，只有簡單的藍芽連線手機功能。右圖是現代的新能源汽車，其豐富的車載應用的引入以及娛樂化的提升，使得汽車更像一部手機。

那麼在第一部分的最後，我們再看來軟體定義汽車的概念。這個概念，是2007年4月份，由IEEE首次提出。

真正帶入大眾視野的是特斯拉的商業模式的成功，特斯拉提出了以硬體為流量入口，軟體為收費服務。打破了傳統汽車賣車的一錘子買賣的商業模式，把汽車變成了一款能透過軟體迭代開發，持續後向收費的產品。

實現軟體定義汽車的核心思想，就是面向服務的思想，也就是把車內複雜的功能，以服務的形式滿足各個應用場景的需求，這樣使得軟體開發變得更加敏捷和高效。但是大量的軟體開發也引入了安全風險。

所以，面向服務的架構，最重要的就是分層，提到分層，一個我認為做的最好的就是Android Open Source Project，那麼Android同樣為了滿足軟體定義汽車的需求，開放了Android Automotive OS來給主機廠做定製。

AAOS的整體設計，整合了Android 分層的思想，在Framework層面定製了Car相關的API，來供APP呼叫。在System Service層面，提供了Car相關Service的實現。在HAL層面，留給OEM來依據自身需求做定製開發。

目前主流的新勢力造車，還是基於原生的AOSP來定製，相當於借用AAOS的思路來完整實現自己的車機能力。

第三部分，我們來看威脅分析：

整車的威脅分析，是ISO 21434主導的標準方法論，目的是透過系統化的分析明確網路安全需求，考慮的要素則是系統化的防護方案。

要求我們要有持續的網路安全活動，要透過風險評估，TARA分析，明確網路安全需求。要求安全能力覆蓋概念階段，產品開發階段，驗證確認階段，生產階段和執行維護階段。

這套方法論我相信是各個主機廠以及我們公司關注的，並且持續落地的，關注的更多是面，而不是點。

下面這張圖，是我們針對主流的座艙系統做的，關於點的威脅分析。

目前座艙域，主流的方案則是虛擬化的方案，也就是我們接觸到的車機其實是一個執行在QNX上的Android，車機負責與使用者互動，QNX負責與底盤互動。我們知道QNX其實是符合功能安全要求的。

APP層面，提供系統介面，地圖服務，內容生態，車家互聯，應用市場。

框架層面，則是提供了一整套控車服務，比如車身控制，連線控制，儀表通訊等。

下游的Native和Driver層面，則是控車服務的進一步實現，並且與QNX在虛擬的網路卡中進行通訊。

那麼作為一個惡意的APP，可以透過硬體外設的方式去安裝，比如USB，藍芽等，也可以透過應用去安裝，比如應用市場中，提供微信，QQ等，透過檔案傳輸來執行。

惡意的APP可以有兩條攻擊路徑來最終達到控車的目的，第一條攻擊路徑，是透過AIDL，呼叫系統服務，進一部資料流轉到Native層面，由Android 的Native和QNX的模組互動，最終轉化成CAN控制。

第二條攻擊路徑，是APP直接透過TCP的方式/或者NFS的方式，來與QNX進行互動，對車進行控制。

那麼我們在研究過程中，都面臨哪些困難與挑戰？

第一，是實車測試環境的缺乏，作為獨立研究員，購買整車去拆解研究是不現實的。

第二，量產車輛往往在軟體除錯介面做了控制，像傳統的ADB，TELNET，SSH等都做了封禁或強密碼管控。

第三，系統的訪問控制，這點是車機比IOT裝置做的好的地方，目前主流的車機均開啟了Selinux，這導致IPC通訊，檔案系統的訪問大受限制，極大削弱的漏洞的影響力。

最後，就是封閉的應用生態，目前主流的車機禁止隨意安裝三方APP，僅支援從其應用商店中安裝。

針對缺乏實車測試環境的問題，我們可以購買單個零部件，透過臺架的方式去做研究。

現在車安全逐漸引起重視，各家也會不時的組織眾測及攻防演練活動，這也是一個好的途徑。

那麼針對除錯入口缺乏的問題，可以著手尋找車輛的工程模式。各地的車展，也有機會接觸到最新的款式，很多車輛也是除錯車，擁有工程模式和除錯入口。

下面，我們將介紹幾個典型的案例，這些案例都是由於軟體定義汽車，所引入的安全風險。這些案例都集中在座艙域。

案例1，某國產汽車多處漏洞突破。

這款國產汽車是典型的QNX虛擬化的Android架構，我們在某些特殊場合下，可透過除錯方式訪問該車輛，並且透過USB來安裝應用。

在Android端，其提供三個主要功能，第一個是QNX Control，顧名思義，就是與QNX互動的模組。第二個是CarControl，也就是與車輛相關控制的模組。第三個是TboxControl，也就是與Tbox相關的控制模組。

這裡存在的問題，則是其三個模組所以來的Framework存在重大許可權設計缺陷，普通APP可對系統服務進行呼叫。

第二個問題，則是車內網路的訪問控制存在重大缺陷，APP可直接走內網通道向QNX傳送指令。

問題1，系統服務缺乏許可權校驗，可導致惡意控車。

缺陷模組為com.living.vehicle.carservice.ICarService，其透過AIDL提供如下四個介面：

Transaction ID，1，對應的函式是獲取CAN訊號

Transaction ID，2，對應的函式是傳送CAN訊號

這個介面的使用場景則是，給車內的系統APP提供API，如空調設定，車門設定，上游模組是CarSystemServer。

當我們分析了CarSystemServer之後，便能夠還原出其控制指令，如右圖所示：

506對應的開車門

616對應的解鎖命令

然後形成了完整的POC，透過AIDL呼叫com.living.vehicle.carservice來傳送車門開啟和解鎖的指令。演示影片如右圖所示。

第二個問題，則是Tbox模組的，同樣是其上游服務缺乏許可權控制。

模組com.tbox.service.TboxService，提供各種服務，可開啟飛航模式，撥打電話，獲取裝置的IMEI。

左邊是設定飛航模式斷網的POC，右邊是我們的控制指令傳輸到HAL層面，HAL透過socket的網路通訊，把payload傳輸給Tbox。

我們透過逆向和抓包的手段，對網路協議做了完整的還原，0xa3則是飛航模式的命令字。

在剛才的問題中，我們看到，車機可以在其Native模組與QNX或者Tbox建立socket通訊，把上游的資料透過網路的方式傳送到下游。

這裡左邊的圖，是我們標準的呼叫流程。右邊的圖，則是我們繞過一系列的呼叫，直接透過socket傳送原始資料。

整個互動流程如左圖所示。

車機先傳送一段訊息，給QNX 的8890埠。QNX回覆同樣的訊息。車機後傳送0xff 0x55 0x00 0x00，QNX回覆一段資料。之後便傳送整個的Payload，Payload中包含了指令資料，右邊則是我們直接透過網路來開啟車門。

當我們能夠透過網路直接與QNX的模組做通訊，那麼我們便可以對QNX側的協議解析做漏洞挖掘或模糊測試工作。透過模糊測試，我們發現了一處QNX程式中的記憶體破壞漏洞。

左邊是QNX的core dump檔案，下面是Crash log。形成的效果，則是會讓QNX重啟，這個就是非常嚴重的影響了。

第二個案例，我們來講我們在某個比賽中發現的整車控車漏洞。

該車輛沒有任何的除錯入口，但是我們在某個論壇中發現了該汽車車機的韌體包，我們進行了韌體逆向工作。發現在其韌體包中，隱藏了工程模式的APK，DevelopmentTools。該模組預設是不啟動的。

我們發現，該車機能夠安裝三方應用，透過USB的形式安裝，也能透過應用市場自帶的微信，或QQ來安裝。

逆向了DevelopmentTools後，發現有開啟ADB的方式，我們透過POC起吊了該元件，最終成功獲得了ADB shell。

之後，我們分析了整個車機的Framework和SystemService，發現三大核心服務，車身控制，空調控制，後備箱控制。直接呼叫這三個服務是不可行的，因為其API簽名要求必須是系統APP才能呼叫。但這三個服務內部均呼叫了AutoDeviceManager，這個模組是缺乏許可權控制的，因此我們可以直接呼叫該模組的API，傳送更底層的命令，達到控車功能。

下圖是我們透過AutoDeviceManager獲得車機的VIN碼：

這裡是我們越權控制的一個演示：

案例3，這個案例是由於供應鏈的引入導致的問題，我們知道，廠商的車機系統，整體程式碼是由三部分組成，底層晶片系統，晶片系統會提供一套完整的BSP程式碼，以適配其硬體架構。第二部分是OEM，比如中科創達，博世這種tier1，他們負責在BSP的基礎上，做二次開發適配廠商的需求，比如一些娛樂相關的。

第三部分，才是主機廠的座艙團隊開發的適配其自有車型的功能。第四部分，是引入的三方APP如地圖，影音，娛樂等。

其中在BSP層面，往往會引入安全漏洞。我們在某晶片廠商中發現了一處本地提權的漏洞，該漏洞同樣影響了某些車機。該模組是個root 程式的模組，普通APP可以利用該模組的漏洞，以root許可權執行任意命令。

右邊是完整的POC，最終的執行效果如下圖所示。

最後一個案例，也是供應鏈相關問題，我們在Android上游的Linux Kernel的USB協議棧中發現了一處陣列越界，該漏洞影響Android所有版本，因此基於Android開發的車機產品同樣受影響。右圖是一個漏洞演示，USB模組的0 day導致的車機重啟。

那麼最終，我們總結一下該議題。

首先我們分析了軟體定義汽車面臨的安全風險，軟體定義汽車在給使用者帶來先進體驗的同時，引入了大量安全問題，包括SOA的服務存在的設計缺陷，車內網路缺乏隔離，導致的惡意控車，車門解鎖等風險。

我們針對漏洞做了組合利用，並且在實車中驗證，展示風險的危害。

最後的建議：

1. 要重視車載APP帶來的安全風險，警惕Framework，系統應用的未授權介面；

2.  車內網路需進行隔離和訪問控制；

3.  重視供應鏈漏洞，例行安全補丁及OTA。

以上就是我的演講，這裡特別感謝一下柯懂湘和閆晗對本議題作出的貢獻。

*峰會議題PPT及回放影片已上傳至【看雪課程】https://www.kanxue.com/book-leaflet-171.htm 

PPT及回放影片對【未購票者收費】；

【已購票的參會人員免費】：我方已透過簡訊將“兌換碼”發至手機，按提示兌換即可~

《看雪2023 SDC》

看雪安全開發者峰會（Security Development Conference，簡稱SDC）由擁有23年悠久歷史的頂尖安全技術綜合網站——看雪主辦，面向開發者、安全人員及高階技術從業人員，是國內開發者與安全人才的年度盛事。自2017年七月份開始舉辦第一屆峰會以來，SDC始終秉持“技術與乾貨”的原則，致力於建立一個多領域、多維度的高階安全交流平臺，推動網際網路安全行業的快速成長。

鑽石合作伙伴

黃金合作伙伴