阿維塔在車輛安全中的以攻促防實例 | 附PPT下載

以下內容整理自談思AutoSec 8周年年會。

分享嘉賓：蘇牧辰 阿維塔科技數字安全-車輛安全負責人

本次的演講主題為《阿維塔在車輛安全中以攻促防實例》，內容相較于此前在談思平臺上分享的日常安全運營工作，這次會更偏技術化。

分享內容主要分成兩個方面，一是介紹阿維塔安全團隊在攻擊上面的一些探索，可能大家會覺得甲方是更偏防守的一方，但阿維塔一直是以一個縱深防御、以攻促防的思路來建設日常的安全工作以及團隊；二是基于IDPS的策略實例，介紹一下阿維塔是如何根據以攻促防進行要塞的防守。

目前，阿維塔的數字安全團隊有20多個人，在日常工作中，幾乎每個人每天都在寫代碼、做紅藍對抗，大家最大的興趣愛好就是給公司挖一些車云安全或者車輛安全的漏洞。

阿維塔安全團隊的工作原則是憑手藝說話、憑事實定級、憑自省提高，也就是說，無論是做TARA，還是做漏洞分析，都必須自己證明：我至少能找到這個漏洞。而不是憑空跟業務講：某個地方很危險，某個漏洞不修的話會怎樣……很重要的一點在于，漏洞找到之后能不能利用，而不是拿掃描器掃出來一堆CVB，然后去找業務反饋。

01 阿維塔安全攻擊實例

首先，來介紹阿維塔的一些攻擊實例。圖1顯示的是一個非常簡單的案例，尤其是做乙方的朋友可能會特別熟悉，當接到甲方的滲透測試時，無論是智能座艙，還是智能駕駛，首先要做的就是nmap一輪掃，看是否有開放端口，再比對業務的端口設計文件，一旦發現有在這個設計文件里面沒有的端口，就會去跟業務確認。

圖1

當然，也會先做一些嘗試指令的連接，比如說“adb connect”，這些連接都嘗試一遍后，往往就會發現這樣開放到車機里的端口不止一個，這是因為我們拿到的往往是一個測試版本，而在測試階段，研發是有合理的需求去保留這么一個端口去打印日志，或者是輸出一些CAN信號。

這時，我們就要先跟研發進行一輪確認，并且也要捋一下日志里面的內容，CAN信號也會打印一份出來看，如果這是 CDC 跟 TBOX 之間的CAN信號，但捋出來發現里面有跟 MDC、或者有一些敏感信息，那就是超微傳輸CAN信號了，就要進行一些限制，并且要留底，以提醒研發在實際的商用版本中，關閉這些暴露端口。有必要的話，還要再做一些強密碼的保存，以便后面的調試。

圖2是我們阿維塔安全團隊的工程師挖到的另一個比較有意思的漏洞。在研究了一款很多主機廠都采用的一套通用代碼的座艙后，在里面發現了一串地址，這串地址光用肉眼去看的話，是不太能知道講的是什么，有些地方可能有一些英文符號如news，或weather，從而猜測它可能是連接到座艙里的天氣，或者是某個消息中心。

圖2

在訪問這些地址的時候，都需要用戶名及密碼，或者是一個權限。這時，以黑客的視角來看，就要想辦法去登錄這個地址，所以一開始找到的那串地址不算是成功利用，那就要倒回到系統里去找這個“xml”文件，它里面肯定有一份文件記錄著如何去探測和登錄這個地址。

然后，我們把系統里的“config”文件捋了一遍，發現有一部分記錄了類似用戶名密碼的內容，但未必第一個用戶名密碼就是準確的，所以要寫一個腳本依次去登錄嘗試，最后成功登到了里面的平臺，并發現，只要找對了一個用戶名和密碼，就可以用它登錄所有平臺，相當于這一臺座艙的車機，可以訪問多個地址，因為它都要用這些應用服務。

這里要說明一點，并不是說登陸了別人的消息中心就是一個漏洞利用了，這不算一個完整的利用鏈路。登錄后，我們會寫腳本去嘗試發送一些語句，尤其是news。因為黑客的攻擊要么是利益驅動，要么是政治導向驅動，所以最怕TA給座艙發一些（惡意）消息。

一般來說，座艙的展示屏幕前端會不停地調取后端接口發的數據，所以我們就一直去探測類似于news這樣的自研地址，并發送一些文字，比如說一開始就發“hello”，后面再嘗試發一些可能不雅的言論，測試用戶是否真的會受到影響。

嚴格來講，這個漏洞不是那種掃描出來后很難修復的漏洞，而是大量的代碼導致的邏輯漏洞，這也是在車機里面大家最怕的一種，如果有黑客思維的話，能在很多通用代碼里找到大量類似問題，所以這里也提醒大家以后要注意。

最后一個漏洞案例比較偏合規和體系，叫座艙安全刷寫無校驗，如圖3所示。車聯網安全行業的同仁可能都知道所謂的安全刷寫和安全啟動，二者都是AUTOSAR里面寫得很標準的東西，測試手法大家也都知道，通俗一點講就是篡改，那篡改的到底是什么？

圖3

這里我將其概括為“包身包頭包尾巴”。我看過很多家主機廠的滲透測試報告，也包括在跟乙方進行交流時，他們給到的測試條例上面就只會寫“我會篡改你這個包，然后重新刷到一個控制器上，看看能否成功做這個刷寫”。

但研究后發現，篡改不同的位置證明的是不同的東西，并且，篡改的內容也是有區分的，比如RXSWIN（Regulation X Software Identification Number），它是R156 里面的一個概念，這個概念跟R155有一定的重疊，然后我就發現，改的東西不同測的也不一樣。

對應這個法律法規，我們一般去篡改這個包的版本號，對應的是R156里面的這個版本號的唯一性，就是說一個OTA版本只能有一個版本號，所以車企要去做歐標認證的話，這一條就不能只是簡單的一個篡改就能證明的，而是一定要證明篡改的是它的版本號。因為阿維塔正好在做歐洲出海的項目，所以這塊就捋得比較細。

還有R155，通俗來講，改的就是簽名值，這也是基于之前做測試時的經驗。我們團隊把這個包整個拆開來改，改了一個“.s19”的文件后發現刷不成功，當時改的不是簽名，也不是版本號。我們就發現，不是隨便打開這個包，改一個配置文件，就能證明這個實驗是成功的。

這里提醒一下，改“.s19”文件的時候，是會影響它本身的完整性校驗的。所以我們只知道篡改，但并不知道改了什么東西。所以現在就做了嚴格的要求，并且把它對應得比較細化。

02 實戰漏洞分布

講完阿維塔的漏洞攻擊實例，接下來講一下實戰漏洞分布。這個數據是基于阿維塔的日常工作所調研出來的，跟中汽中心或一些國檢中心的不一樣，他們是車云漏洞的占比更高，但因為我們團隊更偏零部件、車端的滲透，所以碰到的端上漏洞更多。此外，由于我們這個車依賴的云平臺是華為車云，所以確實沒什么漏洞，不得不說，華為在這方面做得挺好的。

至于為什么要說安全減負，因為攻擊做多了之后就會發現，安全需求并沒有那么難做，它不需要下得那么全面。下圖是按照阿維塔的車型項目節點去計算的安全團隊解決問題的速率。首先，平均每個車上解決的漏洞是25個，這25個指的是把所有的組件漏洞合并之后，那些需要組件升級的往往會被我歸并成一個。

目前，阿維塔已經把信息安全納入了質量標準，即整車上市之前，在信息安全層面也要符合公司的質量標準。其解決率為98%，即量產之前，車輛的高危及中規漏洞要消除為零，可能會有一、兩個屬于可以去澄清或沒有辦法解決的中危漏洞，但是它不可被利用，那這種情況是可以放過的。

圖4是卡點攻擊面的一些分析，首先是TARA分析，TARA在做的過程中很容易邊界模糊，把所有的功能錄進去之后，有些時候會發現不知道自己在分析什么了。所以我們會采用幾個方法論，一個是定性，一個是定量，然后再用一個風險倒推。有的風險其實是能想象得到的，所以就能用這種倒推的形式完成整個TARA分析，這樣也能保證這個分析不是超出認知和常識的。

圖4

舉個例子，我們經常講SecOC，也都知道SecOC是一段 Mac 值加一段新鮮值，它上在任何一個信號上都會影響這個信號本身傳輸的速率，在讓電子電器架構設計的時候，他都會說“Mac值加FA值得占多少個BT、影響私CAN的負載率……”所以我們往往就只能在那些所謂定級最高的信號上推這個防護措施，但是往往定級最高的信號，它的傳輸實時率要求又很高，所以在這方面，安全概念就成了一個悖論。

再比如，一些動力域發到電驅的信號很重要、不能被篡改。但事實是，很多電驅是掛在動力域下面，中間走的是私CAN，這個時候SecOC對這兩個控制器其實一點幫助都沒有，因為它只能解決跨域傳輸的問題，對私CAN是完全不進行校驗的。所以我們就在原有的一套理論和方法論上面減了很多負，取消了私CAN上面的SecOC。

其次，安全的需求特性。還是剛才那個例子，保護不同的信號一定要定到非常細的方案上，一一對應。再就是安全方案設計，我們團隊中的任何一個工程師，都能指導SecOC代碼的編寫，以及調庫。經常會遇到一些供應商，他可能是第一次寫，我們會告訴他AES的算法哪個庫會比較好用，會剪裁得比較好，還會告訴他整個算法怎么去排這個邏輯。

最后就是我們能自己去閉環進行符合性測試。符合性測試跟滲透測試的區別大家也知道，符合性就是下了需求后，有沒有給做；滲透就是在做了這個安全需求的基礎上，還能不能通過其他的黑客手段再進入到這個體系內造成一些威脅。這就是我們整個卡點的一個思路。

這里我理了一個簡易的分類，由于每家車企的電子電架構不一樣，這個只是給大家做一個參考，如圖5。

圖5

首先，是智能座艙、網關、智駕、T-box分為一類，這是所有信息安全方案基本都要上的一類；第二類是BLE等，上的安全方案也比較多，相對前一類少一個TLS，因為它不直接跟云端進行交互，而且有可能不跟其他三個件做間接的 TLS，因為它不傳輸敏感數據；第三類是轉向、電驅和無接觸充電。

最后一類比較極端，什么安全方案都不用上，比如說香氛。其實我們的業務很規范，做了體系之后，他們在每個項目上都會來確認“xx控制器有沒有信息安全的需求”，我會直接告訴他“沒有，你不要擔心。那上面既沒有代碼，也不OTA，做什么信息安全呢？”所以真正要實施信息安全方案的控制器并沒有那么多，而且有的控制器的方案還是重合的。

03 IDPS編寫實例

最后給大家分享一下阿維塔的IDPS編寫實例。雖然沒有任何一個強標要求主機廠一定要買IDPS，但所有強標的導向中都規定車企要具有車端的防護能力，以及實時監測有沒有威脅入侵的能力，它對應的其實就是IDPS。

相信大家都并不陌生IDPS，以前從事過互聯網的同仁會更熟悉，其實就是把主機安全的東西移到車上，把車當做一臺電腦?；谶@樣的思路，我們做了一些拆解。在跟華為合作的主機廠里面，阿維塔是第一個推動華為共建 IDPS 能力的，雙方一起寫了這版策略。

這里重點講下我們怎么在IDPS的策略上面減負的。有的主機廠可能會讓咨詢公司出一套IDPS策略，但這種策略一般會比較粗糙，只會大概說有哪幾個部署點，有哪些探針……但是對于這些探針的策略實際上要細化到通過采什么、計算什么，以及要去讀整個系統里的哪個配置文件。

或許大家可能沒有關心到那么底層，但我們團隊對這個直接梳理到了底層，其中就有這么幾個案例。第一個是我們在優化減負的時候，跟“網絡配置篡改檢測”這個問題battle了很久，一開始下的策略是對這個文件要進行全面的監測，無論是讀的權限還是寫的權限，這個配置文件全都要較高頻率地監聽。

但在跟研發探討了幾輪后發現，這個文件本身權限就控得很死，是一個只讀，在只讀的前提下，又只有兩個進程可以進它的root，而且這兩個進程的權限也幾乎就是最高的權限了。所以我們就把這些只讀文件的監聽范圍做了一輪縮小，畢竟安全團隊自己都完全沒有辦法攻擊進去，業內黑客做了評估后發現，也沒辦法進去，那就沒必要去監聽這些文件了，哪怕這些文件里面確實寫的是非常高敏的東西，但這個時候要得放且放，畢竟，在甲方的工作里面，去防這些未知的攻擊手段其實是不現實的。

第二個案例是異常賬號檢測。其實和上面那個案例類似，我們會去盤點這個賬號本身有沒有保護機制，有的話還需不需要做那么全面的監聽。最后一個案例是敏感文件監控，大家都知道IDPS是要上傳日志到VSOC進行分析的，我們一開始是要求全量的日志都要上傳，但后來反思了一個問題：安全運營排查的時候，真的要看日志的其他字段嗎？那些沒有用的字段為什么要上傳上來？有的字段在告警的階段已經被用于記算了，還要它原本字段的這些內容干嘛？所以我們就刪除了那些安全排查無用的字段，最后幫助性能整體提升了20%。

最后，我們也弄了一個閉環驗證實驗，這個是跟我們部門負責IDPS的同事一起寫的文檔。研發在幫我們正向開發的時候，我們就會直接把那個測試 ID 寫出來給他。當時研發質疑一個只讀文件配置的時候，就說“你自己能不能寫出測試條例來？我都不知道這個怎么黑進去，那相應的安全日志也不會記錄下來”。

當時，我們也battle了好幾輪，最后被說服了，后來在出策略的同時，針對這個策略必須寫一條測試用例出來，這樣才能閉環地給研發證明，這個東西是有用的，也是有實際研發價值的。還有就是端口掃描。端口掃描在策略上其實可以玩得很花，可以是強策略，也可以是弱策略。

阿維塔的安全團隊一直秉持就是多搞技術，少說空話、持續學習、開放態度，這也是我們的延續之本。

完整演講PPT下載，可關注“談思汽車”公眾號，后臺回復關鍵詞“阿維塔演講PPT”，獲取下載鏈接。

- THE END -

審核編輯 黃宇