道路運輸車輛衛(wèi)星定位系統(tǒng)平臺網(wǎng)絡(luò)安全威脅分析報告

          車聯(lián)網(wǎng)技術(shù)本身是指：車輛上的車載設(shè)備通過無線通信技術(shù)，對信息網(wǎng)絡(luò)平臺中的所有車輛動態(tài)信息進行有效利用，在車輛運行中提供不同的功能服務(wù)。車聯(lián)網(wǎng)表現(xiàn)出以下幾點特征為：能夠為車與車之間的行駛提供保障，降低車輛發(fā)生碰撞事故的幾率；可以幫助車主實時導(dǎo)航，并通過與其它車輛和網(wǎng)絡(luò)系統(tǒng)的通信，提高交通運行的效率；幫助監(jiān)管/監(jiān)控方掌控車輛的實時、歷史信息，提升車輛管控效率。

          一旦車載終端通訊設(shè)備或車聯(lián)網(wǎng)終端管理平臺被黑客入侵，黑客可能間接或直接監(jiān)控汽車的實時運行狀態(tài)和車輛行駛軌跡，甚至可能對運行參數(shù)進行修改，這都將對正在運行的汽車造成不堪設(shè)想的后果。

          目前車聯(lián)網(wǎng)安全行業(yè)研究人員相對較少，遠遠不如傳統(tǒng)安全行業(yè)人員眾多。在開展安全研究時又因為投入成本高，有極高入門門檻，同時車聯(lián)網(wǎng)行業(yè)的錯綜復(fù)雜，應(yīng)用的各種通訊協(xié)議規(guī)范、平臺應(yīng)用眾多，導(dǎo)致對于獨立安全研究人員來說對車聯(lián)網(wǎng)安全研究入手相對來說比較難。

          終端與服務(wù)端的通訊協(xié)議是車聯(lián)網(wǎng)平臺中最基礎(chǔ)最重要的部分，起到連接和溝通兩端的作用，交通部委和各省交通廳都對此制定了相關(guān)標準。而在諸多通訊協(xié)議標準中， JT/T808協(xié)議標準作為交通部牽頭定制的用于規(guī)定國內(nèi)道路運輸車輛衛(wèi)星定位系統(tǒng)車載終端與平臺之間的通訊協(xié)議標準，對各地方性協(xié)議的制定具有指導(dǎo)作用，并且被車聯(lián)網(wǎng)平臺所廣泛應(yīng)用，具有一定的權(quán)威性和通用性。我們將從對JT/T808協(xié)議標準的分析入手，然后進一步分析車聯(lián)網(wǎng)平臺端存在的安全風(fēng)險，希望能夠給大家在相關(guān)車聯(lián)網(wǎng)安全研究上提供一定的幫助。

          3.1 JT/T808協(xié)議

          JT/T808全稱為《道路運輸車輛衛(wèi)星定位系統(tǒng)終端通訊協(xié)議及數(shù)據(jù)格式》，其中按照年份現(xiàn)階段共發(fā)布了三個相關(guān)版本分別為：JT/T808-2011、JT/T808-2013、JT/T808-2019。協(xié)議規(guī)定了道路運輸車輛衛(wèi)星定位系統(tǒng)車載終端與車聯(lián)網(wǎng)監(jiān)管/監(jiān)控平臺之間的通信協(xié)議與數(shù)據(jù)格式, 包括協(xié)議基礎(chǔ)、通信連接、消息處理、協(xié)議分類與要求及數(shù)據(jù)格式。

          JT/T808通信協(xié)議采用TCP或UDP進行封裝傳輸，車聯(lián)網(wǎng)監(jiān)管/監(jiān)控平臺（以下簡稱“平臺”）作為服務(wù)器端，道路運輸車輛衛(wèi)星定位系統(tǒng)車載終端（以下簡稱“終端”）作為客戶端。當(dāng)數(shù)據(jù)通信鏈路異常時，終端可采用SMS消息方式通信，通信整體流程如下：

          3.2 協(xié)議傳輸規(guī)則

          協(xié)議應(yīng)采用大端模式的網(wǎng)絡(luò)字節(jié)序來傳遞字和雙字。傳輸規(guī)則約定如下：

          BYTE的傳輸，按照字節(jié)流的方式傳輸；

          WORD的傳輸，先傳遞高八位，再傳遞低八位；

          DWORD的傳輸，先傳遞高二十四位，然后傳遞高十六位，再傳遞高八位，最后傳遞低八位。

          3.3 通訊協(xié)議解析

          每條消息由標識位、消息頭、消息體和校驗碼組成，詳細數(shù)據(jù)結(jié)構(gòu)如下：

   JT/T808協(xié)議采取0x7e作為數(shù)據(jù)標識位，標識位位于每條消息的首尾兩端；對于除標識位之外的0x7e和0x7d則要進行轉(zhuǎn)義：

          先7d→7d 01

          再7e→7d 01

          消息頭中主要包括：消息ID、消息體屬性、協(xié)議版本號、終端手機號、消息流水號、消息包封裝。

          消息體的數(shù)據(jù)格式和內(nèi)容根據(jù)對應(yīng)命令進行確定，消息體的相關(guān)屬性由消息頭中的消息體屬性來確定，具體包括：保留字段、版本標識、分包、數(shù)據(jù)加密方式、消息體長度。

          校驗碼通過異或方式計算得到。

          3.4 通訊消息例示

          服務(wù)端發(fā)送信息例示——車門加鎖命令：

          7E 85 00 00 01 01 23 45 67 89 98 00 06 01 14 7E

          消息分析：

          終端發(fā)送信息例示——終端位置信息上報：

          7E 02 00 00 26 01 23 45 67 89 98 00 7D 02 00 00 00 01 00 00 00 02 00 BA 7F 0E 07 E4 F1 1C 00 28 00 3C 00 00 18 10 15 10 10 10 01 04 00 00 00 64 02 02 00 7D 01 13 7E

           消息分析：

           4、車聯(lián)網(wǎng)平臺端可能存在的安全風(fēng)險分析

           4.1 車聯(lián)網(wǎng)平臺服務(wù)端與終端交互的安全風(fēng)險

           車聯(lián)網(wǎng)平臺與終端在JT/T808協(xié)議時，一般的鑒權(quán)機制為：終端在未注冊狀態(tài)下，首先進行注冊，注冊成功后終端將獲得鑒權(quán)碼并保存，鑒權(quán)碼在終端登錄時使用，車輛需要拆除或更換終端前，終端應(yīng)該執(zhí)行注銷操作，取消終端和車輛的對應(yīng)關(guān)系。

           鑒于車聯(lián)網(wǎng)平臺開發(fā)廠家眾多，在平臺服務(wù)端協(xié)議棧的實現(xiàn)方面不同的廠家，可能存在不同的實現(xiàn)思路，從技術(shù)層面分析車聯(lián)網(wǎng)平臺端可能存在如下風(fēng)險。

          4.1.1 車載終端枚舉

          直接通過發(fā)送符合JT/T808協(xié)議格式的數(shù)據(jù)包到達服務(wù)端后，平臺不進行相關(guān)鑒權(quán)也會返回給客戶端符合JT/T808協(xié)議格式的數(shù)據(jù)包，因此可以發(fā)送攜帶不同的終端手機號的數(shù)據(jù)包，根據(jù)服務(wù)端的響應(yīng)來對終端進行枚舉，探測真實存在的終端手機號。黑客可以通過此方式實現(xiàn)專項滲透測試攻擊，極易鎖定相關(guān)目標。

           4.1.2 車載終端異常數(shù)據(jù)偽造

           根據(jù)JTT808協(xié)議規(guī)定，終端在正式進行使用之前，設(shè)備首先會發(fā)送注冊數(shù)據(jù)通過服務(wù)端進行注冊，服務(wù)端注冊成功后終端將獲得鑒權(quán)碼，并把相關(guān)注冊信息在平臺保存。這一過程中看似沒有相關(guān)安全風(fēng)險，但是如果攻擊者通過偽造注冊請求或者其他符合協(xié)議的異常數(shù)據(jù)內(nèi)容，服務(wù)端將會出現(xiàn)大量異常設(shè)備驗證或鑒權(quán)操作錯誤日志與記錄，干擾管理人員審計；并以此消耗服務(wù)器運算資源，從而可能導(dǎo)致服務(wù)端拒絕服務(wù)。

           4.1.3 車載終端通信偽造

           在協(xié)議通訊過程中，JT/T808服務(wù)端的開發(fā)者可能并不會對數(shù)據(jù)上報來源進行限制，因此再得知設(shè)備的終端手機號車牌號等信息的情況下，可以通過模擬設(shè)備與數(shù)據(jù)平臺進行通訊，發(fā)送異常報警與位置數(shù)據(jù)。

           4.2 車聯(lián)網(wǎng)平臺服務(wù)端安全風(fēng)險

           4.2.1 服務(wù)端管理WEB安全風(fēng)險

           車聯(lián)網(wǎng)平臺為了便于使用者的訪問和操作，通常使用Web服務(wù)來實現(xiàn)管理平臺端。因此同樣易受到各類Web安全風(fēng)險影響，如弱口令、敏感信息泄露、未授權(quán)訪問、中間件RCE等安全風(fēng)險影響。

           我們在研究中發(fā)現(xiàn)“登錄弱口令（初始口令）”、“數(shù)據(jù)庫暴露公網(wǎng)，數(shù)據(jù)庫弱口令（初始密碼）”以及敏感信息泄露（日志文件泄露數(shù)據(jù)庫連接密碼、泄露車輛sim號）等風(fēng)險較為常見，并以較低的利用成本威脅車聯(lián)網(wǎng)系統(tǒng)信息安全。

            4.2.2 API接口安全風(fēng)險

           一些車聯(lián)網(wǎng)平臺的移動端程序與服務(wù)端進行數(shù)據(jù)交互一般通過API接口來實現(xiàn)，同時API接口也被用于第三方平臺請求車聯(lián)網(wǎng)平臺的數(shù)據(jù)。這些API接口可能存在著安全隱患，例如：越權(quán)，輸入控制（xss、注入），接口濫用（爆破），信息泄露等。

           4.2.3 平臺運維管理風(fēng)險

           車聯(lián)網(wǎng)平臺功能眾多，操作起來相對復(fù)雜，并且平臺部署涉及諸多軟件和服務(wù)，對于非相關(guān)專業(yè)的管理人員和運維人員來說操作有一定難度，若沒有專業(yè)的技術(shù)培訓(xùn)和安全培訓(xùn)則可能對平臺帶來一定風(fēng)險。

           例如運維配置不當(dāng)導(dǎo)致車輛信息報送漏發(fā)、錯發(fā)數(shù)據(jù)造成的風(fēng)險等。平臺管理安全意識不足或?qū)ζ脚_使用不理解則可能導(dǎo)致管理賬號弱口令，下級賬號權(quán)限分配不當(dāng)以致信息泄露或越權(quán)操作等安全風(fēng)險。

           目前，使用JT/T808的車載終端主要通過物聯(lián)網(wǎng)SIM卡，經(jīng)由3G、4G網(wǎng)絡(luò)，與位于互聯(lián)網(wǎng)的車聯(lián)網(wǎng)平臺服務(wù)端進行通訊，JT/T808協(xié)議的標準規(guī)范方面目前沒有具體約定TCP/UDP傳輸?shù)姆绞胶蜆藴实耐ㄐ哦丝?，一般用戶會自行選擇使用TCP或者UDP指定特定端口進行數(shù)據(jù)通信。

            根據(jù)Zhifeng綜合分析數(shù)據(jù)顯示國內(nèi)車聯(lián)網(wǎng)平臺分布情況如下：

           根據(jù)知風(fēng)安全分析團隊研究發(fā)現(xiàn)，當(dāng)前JT/T808車聯(lián)網(wǎng)通訊協(xié)議中存在的風(fēng)險主要來自三個方面，分別是：服務(wù)端廠商搭建的車聯(lián)網(wǎng)平臺WEB系統(tǒng)安全風(fēng)險隱患與廠商根據(jù)通訊協(xié)議開發(fā)的通訊程序存在的隱患以及通訊協(xié)議中設(shè)計邏輯存在的缺陷可能導(dǎo)致的安全風(fēng)險。

            我們建議在針對通訊協(xié)議層通訊數(shù)據(jù)實施安全優(yōu)化，針對互聯(lián)網(wǎng)在線的車聯(lián)網(wǎng)平臺的協(xié)議服務(wù)端針對異常邏輯的數(shù)據(jù)包不響應(yīng)，有條件情況下可以嘗試升級成必要的加密通訊，按照加密規(guī)范來約束各個廠商之間的實現(xiàn)邏輯；廠商開發(fā)的通訊程序時應(yīng)嚴格按照協(xié)議標準規(guī)定進行開發(fā)，并應(yīng)在上線前對程序進行安全測試；車聯(lián)網(wǎng)平臺WEB系統(tǒng)方面應(yīng)該避免出現(xiàn)常見的弱口令、信息泄露、目錄遍歷、RCE等漏洞。