【安防展覽網 訪談】 7月22日—23日，由蓋世汽車主辦、上海汽車城特別支持的“2020首屆軟件定義汽車高峰論壇”正式舉辦。本次論壇主要探討軟件定義汽車領域新的創新理念、技術趨勢、現實挑戰等熱點話題，共謀行業未來發展之道。下面是騰訊安全車聯網安全技術專家張康在本次論壇上的發言：
2018年5月9號是我第一次代表實驗室去分享議題，當時發生了什么事情呢？奔馳車主高速剎車失控，120車速失控的例子。我當時拿這個例子作為一個開場，那個議題也是半個小時，我當時花了20多分鐘的時間在告訴大家說車聯網安全為什么很重要，當時放了我們2016年特斯拉的視頻，視頻里面演示到我們的研究員在10公里以外的地方通過4G的方式遠程對特斯拉進行一個剎車的時候，那個時候大家的感受是非常真切的：車聯網信息安全的問題真的是能造成功能安全的風險。
所以也是那幾年我們在做的事情，我們一直在做行業教育。后來5月底的時候我們又發布了寶馬的一個研究案例，當時是受影響超過1000萬臺的車。從2018年下半年開始我們再去跟車企聊的時候已經不需要做教育了，車企說我知道信息安全很重要，你告訴我應該怎么做？特斯拉和寶馬都有這樣的問題，那你們量產的時候肯定或多或少有這樣的問題，那我們先做滲透測試，發現你們現有的問題，然后去解決問題。
這里需要澄清一下，雖然說我研究特斯拉和寶馬存在安全問題，但是在看來他們的信息安全水平是TOP的：特斯拉不用提了，他們的安全團隊都是從Google Apple過來的，寶馬也有專門負責內部滲透測試的安全團隊，所以我們交流完全是在一個頻道上的；特斯拉是16年的平臺比較早，寶馬是2018年做的，代碼是15、16年開發的平臺，都已經是4,5年前的事情了，所以有安全問題也是可以理解的；當我們后來看兩家廠商這兩年的代碼時，我們其實看到他們的安全性做的是相當好的。
過去兩年我們做了超過20多家的車企，有些車企連續兩年都在做，做得多了客戶提出這樣一個問題：車企都喜歡量化，也喜歡行業對標，但是安全本身該不該被量化的這件事情就值得討論，而且我們收費也不便宜，那我怎么跟老板匯報我的錢是花在點子上了；另外一個就是我跟其他的對標，我處于什么樣的狀態。
所以基于這個東西我們做了一些思考，設計了一套安全測評的體系，橫向是設計安全，設計安全就是從系統安全、開發安全、通信安全等等各個維度，每個維度有不同權重的檢測項，可以理解為是一套checklist；縱向是實現安全，是指設計層面的安全需求是否都得到滿足了，實現的過程當中是不是存在哪些邏輯漏洞。
這里列出來的點就是我們測過所有網聯功能模塊的打分，其中有些黃點是車企第一年做，綠點是他們下一代車型，可以看到整體安全性的確是有提高的。
所以今天后面整個議題都會圍繞設計安全和實現安全兩個角度來講。
這張圖和上午博世那張非常經典的EE架構圖演變不太一樣，這張是從攻擊者視角車聯網安全會關注的點。左邊是車端，我們主要關注攻擊入口，比如說車機是很主要的入口，WIFI、藍牙、USB，然后還有Tbox，負責與云端后臺通信，然后再往底層有一個網關，前幾年可能還是傳統的防火墻，現在可能會變成智能網關這樣的概念，下面就是不同的域，基本走的是CAN協議，以及包括周邊的一些設施，比如說充電樁、ADAS，V2X等等。
舉些例子，車端的這些攻擊面，特斯拉我們是做過了包括WIFI、OTA、4G、等等，寶馬我們關注了一個新的攻擊面，就是可以通過短信去開啟車門；今年我們做了豐田，豐田是實現了藍牙攻擊面的利用。車端的攻擊面一旦被利用了以后可以造成功能安全方面的一些影響，破解車機，T-Box，網關后，直接向CAN去發送一些惡意指令，會造成車輛的功能安全影響。
右半邊就是傳統的互聯網安全，云端后臺可能是OEM自己的后臺，也可能是三方服務的后臺，通過手機可以實現遠程車控，或者是像藍牙鑰匙這樣的功能。右邊可能造成的風險相對以信息安全偏多，比如說財產損失或者是信息泄露這樣的一些問題。
我們做了特斯拉、寶馬、豐田，這兩天基本所有人都在講特斯拉，但我今天還是主講特斯拉，為什么？因為這次是軟件定義汽車大會，大家都不可否認，特斯拉其實是軟件定義汽車的典范。
這張是2016年的架構圖，和EE架構圖不太一樣，我們只列出了我們主要關注的模塊。
2016年的時候它的中控屏車機，車機是Linux系統，它本身還承載了Tbox的功能和后臺通信，車機和跟儀表盤和WIFI模塊，還有網關走的以太網，網關是個RTOS系統。我們當時研究了兩路CAN，包括車身控制CAN，還有高速CAN，就是ABS、ESP這些行車過程中造成的動作。16年的時候我們的攻擊鏈是這樣的：特斯拉有一個內置的WIFI，我可以通過惡意WIFI熱點來進入特斯拉車內網絡，車機顯示頁面是Linux自帶的WebKit瀏覽器，當時這個瀏覽器的版本非常低，存在大量的已知漏洞，通過這些已知漏洞我們就拿了瀏覽器的權限，但特斯拉權限控制做的比較好，瀏覽器進程的權限有限。我們見過其他太多的車機系統所有的應用都跑在root/system下，拿到一個應用就直接拿到系統ROOT。
于是下一步我們去研究Linux內核，同樣當時內核版本很低，存在很多已知漏洞，利用之后實現了提權，到這里我們完全控制了中控屏。
特斯拉是應該是第一個在量產車上實現OTA的公司,可以通過遠程做包括中控屏，網關和底層ECU在內的系統更新，這在當時是很超前的。但16年的時候特斯拉OTA沒有做簽名校驗，就意味著任意的攻擊者可以構造任意惡意的固件去刷掉網關。后面就很簡單了，通過分析CAN指令或者發送診斷指令，就可以實現一些非常規的車控效果。
所以可以看到16年的時候還是設計問題偏多，存在大量的已知漏洞，OTA沒有做校驗，這些都是設計層面的問題。
到了2017年的研究我們來看，首先瀏覽器之前的漏洞修復了，但版本仍然不是新的，我們利用當時較新的已知漏洞，再次獲取了瀏覽器代碼執行的權限。之后是內核，內核在當時已經升到了新版本，但我們通過深入研究后發現了一個內核驅動的未知漏洞，通過這個漏洞再次實現了提權的動作。內核這里就屬于實現問題。
之后是網關，2017年的時候特斯拉OTA已經加了簽名校驗，但通過深入逆向分析我們發現了它在代碼實現層面的邏輯漏洞，可以跳過簽名校驗，再次刷寫了網關，之后的事情就基本一樣了。這里也屬于實現問題，設計層面上了安全措施，但代碼實現上有缺陷導致被繞過。
2017年的時候我們還做了一件事情，通過深入分析特斯拉的ADAS模塊APE，我們發現通過一個高權限的進程，外加一個名為m3-factory-deploy的函數，可以拿到APE模塊的root權限。這里其實又屬于設計問題了，從上面這個函數名字可以猜測，這應該是當時在還未上市的model3上預留的工程模式函數，但在量產版本上沒有做刪除。
拿到APE的root權限后，我們做了進一步的深入研究，并在2019年發布了成果。這是當時研究的發布視頻，大家可以看一下。
大家可以明顯看到，我們視頻的預算增加了(笑)。其實從安全角度來說，安全是一個伴生屬性，任何新技術的出現往往都伴隨著信息安全的風險，這也是科恩實驗室一直在關注的事情，我們一直在做前沿技術的安全研究。對于ADAS來說，我認為是安全有兩個維度：
第一個維度，ADAS本身的系統模塊，這個展開來講的話，不只ADAS了，新架構下會有大量功能集中在一個域控制器上，這個系統本身的安全性是至關重要的，因為它可以直接發出車身控制，動力系統控制等高危操作，如果這個系統自身安全做得不好，那我一旦被破解之后就可以去實現車控，造成安全功能的影響。
第二個維度，自動駕駛算法引入了一個新的場景，特斯拉走的是圖像識別這條線路，大家看到第一個雨刷的研究，它的雨刷是靠深度學習算法去做決策，判斷當前的畫面是不是下雨，我們在不清楚具體算法的前提下，構造了一個對抗樣本的訓練模型，通過純黑盒的方式，端到端地生成了一個對抗樣本，終實現了通過放一個干擾畫面可以讓自動駕駛的算法做出一個錯誤的判斷，然后導致雨刷器啟動。
車道輔助這一塊，這個跟對抗樣本沒什么關系，通過測試我們發現在地面上部署幾個隨機的點，就可以讓特斯拉識別出來這是一條新的車道，做出錯誤的判斷，駛向錯誤的路線。實際測試的時候我們也遇到過，像是天橋上面灑下來的倒影，樹蔭等有時也會讓特斯拉做出一些錯誤的判斷。我們只是做了一個拋磚引玉，是想表明ADAS，自動駕駛的場景下，算法本身的安全問題也是需要值得大家考慮的。
剛剛講了那么多特斯拉再講講別的，除了特斯拉之外，我們做了20多款車的網聯系統測試，總結下來，車聯網系統常見的安全問題有幾類，首先從問題發現的難易程度來說，簡單的問題是系統版本低存在已知漏洞、通訊不加密、小權限未滿足等等設計層面的問題，這些是占很大一部分的，而且這些問題是好利用的，有些已知的漏洞，利用代碼網上都可以搜到，這個就大大減少了攻擊者的攻擊成本。稍微難一點的比如說系統自帶的安全緩解措施或者是多余的組件和服務沒有被刪除等，這個需要做一些進一步研究才能夠發現；比較困難的多數是偏代碼實現的邏輯漏洞，比如說剛才提到的特斯拉簽名繞過的問題，以及虛擬化逃逸，自動駕駛算法安全等前沿技術的安全問題。所以越往左看是越偏向于設計安全，比如說版本舊，或者通訊沒加密這些都是可以去通過給供應商和開發者提需求來解決的。
所以從技術角度有哪些建議呢？安全基本原則是永遠不過時的，比如說小權限設計原則，或者攻擊面收斂-沒必要的接口或者組件直接刪掉，不要留在那里；還有默認安全，就是系統原生的默認選項配好；還有縱深防御等等，這些安全基本原則是*過時的，而且往往是有效的。
我們再回到這張圖，這些問題可以通過什么樣的方式去發現呢？對于簡單的問題來說，上面提到的安全基本原則可以，結合自動化工具，比如說應用代碼審計工具等等，其實是可以基本全覆蓋到的；中等難度的問題可能會需要配合一定的滲透測試；對于困難問題來說可能需要大量的滲透測試，就是偏實現安全的問題，我去深入理解你的代碼邏輯才能發現這些漏洞，從很長遠角度來說甚至還需要配合一些IDS實時監控手段。
除此之外應急響應/眾測/漏洞獎勵計劃也能騎到查缺補漏的效果，特斯拉這里就做的很好，通過實際獎勵，去鼓勵安全研究員把問題直接報給你，而不是直接賣給黑產。
對于攻擊者來說他永遠是考慮投入產出比，我花費多少的代價，能獲取多大的一個成果。所以從防御者的角度來說也是一樣，我不用跑得比熊快，只要跑的比別人快就行了，對吧(笑)？其實我只需要把這些簡單的問題在需求設計階段規避掉，花很小的成本就可以把安全提升到一個還不錯的level，差不多是這個概念。
sysAuditor是騰訊科恩實驗室的一個嵌入式系統安全審計平臺，科恩做的產品都是怎么來的？我們在滲透測試的過程當中，我們發現剛剛提到的一些安全基線的問題，可以通過自動化的工具來實現，然后我們就開始寫一些自動化的腳本，然后就發現這些腳本為什么不把它生成工具賣給客戶呢？這樣我們把自動化的測試工具給到客戶，讓客戶去用，可以提升自己的測試能力水平，然后更高級的測試讓我們來做，是這樣的一個思路。
幾句話解釋這個平臺能夠干嘛：首先會在目標系統上跑一個腳本，這個腳本可以理解為它會生成一個系統的快照，里面包含所有需要的信息，然后上傳到后臺，通過一定的規則引擎去做分析，這里的規則是科恩多年來車聯網的滲透測試經驗沉淀下來的，可以看到從系統、通信，權限等多個維度，這個和前文提到的設計安全的checklist是有對應的；掃描之后終出一個結果，列出系統對于車聯網來說存在哪些風險，哪些是高危、中危的或者警告的等等。
這個打分系統說實話我們是抗拒的(笑)，但是廠商還是希望你可以再直觀一點，給我一個打分，告訴我綜合評分是多少。顯然現在這個打分系統的算法還是有待優化，14分有點說不過去了(笑)。
剛才講的是在技術層面，從流程層面來說，我們跟車企去聊的時候說你們該在設計層面去做什么，去提需求，那車企會問另外一個問題，我該如何制定一個詳細的需求，后面該怎么驗證需求被滿足了？這個也是說明車企到了下一個階段，就是對下一代開發平臺的安全該做。
這里可以看，對于車企開發來說它是從傳統的模型一直到現在軟件定義汽車SOA的開發模式去做轉變，安全來說也是一樣的，開始時微軟的SDL，安全開發生命周期，在設計階段把需求提出來，然后在驗證階段進行測試，去驗證需求是否滿足，然后發布以后再進行應急響應，這是安全開發生命周期；將來隨著軟件定義汽車的普及，安全也是一樣的會向DevSecOps去做轉變，會更加強調自動化；其實我們在跟寶馬合作的時候，寶馬已經在往這種方向去轉了，剛才的那個工具他們很感興趣，這個工具可以集成到他們的CI流程里去，每做一個版本迭代都跑一次，確保我沒有引入新的安全問題，進而保障安全的下限。
但是對于大部分的車企來講，目前連SDL都還沒有實現，所以我們現在也開始做轉型，開始給車企做咨詢規劃，比如車企說我想成立自己的安全管理團隊，那我們給集合具體的業務規劃，去做一個安全的規劃，需要招多少人、分3到5年，需要做什么事情，后面包括風險評估，應急響應流程等等的咨詢，這是我們目前在做的事情。
后一頁takeaway，從人的層面來講，現在大部分車企還沒有做到“有專門的團隊負責信息安全”，先做這個，后面再考慮“信息安全是每個人的責任”；然后就是要找專業的人去做專業的事情，怎么樣幫你做咨詢規劃，針對于你的方案該給供應商和開發提出怎么樣的一個安全需求，再由誰去做風險評估，誰來去做滲透測試的驗證，其實每個階段一定要有專業的人來做這個事情。
技術層面大家可以看，車機趨勢基本是安卓或者Linux，其他域控等也基本是Linux為主，大家的手機其實就是安卓，大家的主機就是Linux，這兩個系統本身這已經是非常安全的產品了，所以對于車端來說需要做的就是將PC端和移動端非常成熟的技術，結合具體應用業務場景，按照優先級順序應用到車聯網當中；優先級順序是很重要的，因為還是那句話，車企永遠是考慮成本控制的，不可能說什么安全措施都要上，一定是有一個先后順序的，這個一定要結合自己的應用場景，先上哪些技術再上哪些。舉個例子有些車企說我們要不要做IDS或者CAN加密？我說有這些錢還不如把系統的基礎安全性做好，先從20分達到60分，然后再去考慮怎么樣達到80、90分的概念；
還有就是選擇合適的自動化工具，應用到安全開發的流程中去，確保我每次的版本迭代都是有一定質量保證的。
流程層面就很簡單了，首先是安全左移，大多數的安全隱患都是可以在需求設計層面解決的，而且越往左移的成本越低的，所以這是一個低成本*的事情。還有就是這個需求提給供應商也好，還是提給OEM自己的開發也好，還是要在驗證階段做測試，驗證需求是否得到了滿足，滿足過程當中是不是也存在實現問題，終確保整個系統的安全。
差不多就是這樣，謝謝大家！大家有什么問題嗎？
提問：你好，我想問一下您這邊的實驗室有沒有攻擊過一些其他非Linux的系統？有沒有成功的案例可以跟我們分享一下？比方說QNX之類的。
張康：我現在講的都是可以在網上查到的信息，特斯拉和寶馬這些都是公開的，是有研究白皮書的，我們看的Linux/安卓比較多，QNX也有，像寶馬的車機就有一個QNX，其他的T-Box，網關也有QNX或者RTOS等系統，以及單片機這種，都有看，我們研究不分系統，還是具體攻擊鏈上遇到什么系統就看什么。
提問：那也就是說一些號稱安全的操作系統道高一尺，魔高一丈還是有這個？
張康：其實剛剛提到了，Linux和安卓其實也是安全的，你用的手機如果滿分是100分，已經可以達到99分了，但車機上如果是同樣的安卓能不能達到同樣的效果，這個是要看具體實現的。
提問：你前面提到17年特斯拉你們用了一個0day漏洞，是你們自己找的還是？
張康：對，我們自己找的，本身早科恩就是關注Linux和Windows這樣的操作系統，我們會去做0day，然后我們發現了以后會去報給廠商。
提問：因為這些代碼都是開源的，如果整車廠的代碼不是開源的話，是不是不容易去找？
張康：我們研究所有的安全漏洞都是黑盒測試，簡單來說是把一個二進制的文件，比如安裝包，逆向成匯編代碼，再逆向成C/C++這種開發語言，然后再去分析其中的代碼邏輯。所以為什么你在市面上沒有做安全測試這么多，能達到我們這個成果是很少的，這個是有很高的技術門檻在里面的。此外，今天想給大家分享的17年特斯拉的Oday情況攻擊成本是非常高的，是需要有我們這樣的專業人才去做深入的研究才能發現問題，但事實是車聯網系統其實存在更普遍的可以利用的已知漏洞，這些相對來說很容易被利用，所以一旦你把系統版本升到新，確保已知的安全漏洞都被修復，就可以達到一個比較高的安全水準了，謝謝。
移動版
智慧城市網APP
智慧城市網小程序
微信公眾號
