• <input id="ueaq2"><tt id="ueaq2"></tt></input>
  • 您好!歡迎登陸興智科技官網...
    微信公眾號
    news 媒體中心
    道路運輸車輛衛星定位系統平臺網絡安全威脅分析報告
    作者:興智科技 發布時間:2021-04-09 13:59:46
    前言
     

    車聯網技術本身是指:車輛上的車載設備通過無線通信技術,對信息網絡平臺中的所有車輛動態信息進行有效利用,在車輛運行中提供不同的功能服務。車聯網表現出以下幾點特征為:能夠為車與車之間的行駛提供保障,降低車輛發生碰撞事故的幾率;可以幫助車主實時導航,并通過與其它車輛和網絡系統的通信,提高交通運行的效率;幫助監管/監控方掌控車輛的實時、歷史信息,提升車輛管控效率。

    一旦車載終端通訊設備或車聯網終端管理平臺被黑客入侵,黑客可能間接或直接監控汽車的實時運行狀態和車輛行駛軌跡,甚至可能對運行參數進行修改,這都將對正在運行的汽車造成不堪設想的后果。

     

     

    現狀

     

    目前車聯網安全行業研究人員相對較少,遠遠不如傳統安全行業人員眾多。在開展安全研究時又因為投入成本高,有極高入門門檻,同時車聯網行業的錯綜復雜,應用的各種通訊協議規范、平臺應用眾多,導致對于獨立安全研究人員來說對車聯網安全研究入手相對來說比較難。

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

     

    協議介紹

     

    01 JT/T808協議

    JT/T808全稱為《道路運輸車輛衛星定位系統終端通訊協議及數據格式》,其中按照年份現階段共發布了三個相關版本分別為:JT/T808-2011、JT/T808-2013、JT/T808-2019。協議規定了道路運輸車輛衛星定位系統車載終端與車聯網監管/監控平臺之間的通信協議與數據格式, 包括協議基礎、通信連接、消息處理、協議分類與要求及數據格式。

    JT/T808通信協議采用TCP或UDP進行封裝傳輸,車聯網監管/監控平臺(以下簡稱“平臺”)作為服務器端,道路運輸車輛衛星定位系統車載終端(以下簡稱“終端”)作為客戶端。當數據通信鏈路異常時,終端可采用SMS消息方式通信,通信整體流程如下:

     

    02 協議傳輸規則

    協議應采用大端模式的網絡字節序來傳遞字和雙字。傳輸規則約定如下:

    BYTE的傳輸,按照字節流的方式傳輸;

    WORD的傳輸,先傳遞高八位,再傳遞低八位;

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

    03 通訊協議解析

    每條消息由標識位、消息頭、消息體和校驗碼組成,詳細數據結構如下:

    標識位

    消息頭

    消息體

    校驗碼

    標志位

    JT/T808協議采取0x7e作為數據標識位,標識位位于每條消息的首尾兩端;對于除標識位之外的0x7e和0x7d則要進行轉義:

    先7d→7d 01

    再7e→7d 01

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

    消息體的數據格式和內容根據對應命令進行確定,消息體的相關屬性由消息頭中的消息體屬性來確定,具體包括:保留字段、版本標識、分包、數據加密方式、消息體長度。

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

    04 通訊消息例示

    服務端發送信息例示——車門加鎖命令:

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

    消息分析:

    內容

    含義

    數據類型

    7E

    標識位

    BYTE

    85 00

    消息ID——車輛控制

    WORD

    00 01

    消息體屬性

    WORD

    01 23 45 67 89 98

    終端手機號

    BCD[10]

    00 06

    流水號

    WORD

    01

    消息體

     

    14

    校驗碼

    BYTE

    7E

    標識位

    BYTE

    終端發送信息例示——終端位置信息上報:

    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

    消息分析:

     

    注:流水號中7D 02轉義前為7E,消息體中7D 01轉義前為7D;轉義封包等規則詳見《JTT 808-2019-道路運輸車輛衛星定位系統終端通訊協議及數據格式》

     

    車聯網平臺端可能存在的安全風險分析

     

    01車聯網平臺服務端與終端交互的安全風險

    車聯網平臺與終端在JT/T808協議時,一般的鑒權機制為:終端在未注冊狀態下,首先進行注冊,注冊成功后終端將獲得鑒權碼并保存,鑒權碼在終端登錄時使用,車輛需要拆除或更換終端前,終端應該執行注銷操作,取消終端和車輛的對應關系。

    鑒于車聯網平臺開發廠家眾多,在平臺服務端協議棧的實現方面不同的廠家,可能存在不同的實現思路,從技術層面分析車聯網平臺端可能存在如下風險。

    1.1 車載終端枚舉

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

    1.2 車載終端異常數據偽造

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

    1.3 車載終端通信偽造

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

    02 車聯網平臺服務端安全風險

    2.1 服務端管理WEB安全風險

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

    我們在研究中發現“登錄弱口令(初始口令)”、“數據庫暴露公網,數據庫弱口令(初始密碼)”以及敏感信息泄露(日志文件泄露數據庫連接密碼、泄露車輛sim號)等風險較為常見,并以較低的利用成本威脅車聯網系統信息安全。

    2.2 API接口安全風險

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

    2.3 平臺運維管理風險

    車聯網平臺功能眾多,操作起來相對復雜,并且平臺部署涉及諸多軟件和服務,對于非相關專業的管理人員和運維人員來說操作有一定難度,若沒有專業的技術培訓和安全培訓則可能對平臺帶來一定風險。

    例如運維配置不當導致車輛信息報送漏發、錯發數據造成的風險等。平臺管理安全意識不足或對平臺使用不理解則可能導致管理賬號弱口令,下級賬號權限分配不當以致信息泄露或越權操作等安全風險。

     

    在線情況分析

     
     

    目前,使用JT/T808的車載終端主要通過物聯網SIM卡,經由3G、4G網絡,與位于互聯網的車聯網平臺服務端進行通訊,JT/T808協議的標準規范方面目前沒有具體約定TCP/UDP傳輸的方式和標準的通信端口,一般用戶會自行選擇使用TCP或者UDP指定特定端口進行數據通信。

    根據Zhifeng綜合分析數據顯示國內車聯網平臺分布情況如下:

     

     

    解決方案與對應策略

     
     

    根據知風安全分析團隊研究發現,當前JT/T808車聯網通訊協議中存在的風險主要來自三個方面,分別是:服務端廠商搭建的車聯網平臺WEB系統安全風險隱患與廠商根據通訊協議開發的通訊程序存在的隱患以及通訊協議中設計邏輯存在的缺陷可能導致的安全風險。

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

    必中计划软件 <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>