车联网技术本身是指：车辆上的车载设备通过无线通信技术，对信息网络平台中的所有车辆动态信息进行有效利用，在车辆运行中提供不同的功能服务。车联网表现出以下几点特征为：能够为车与车之间的行驶提供保障，降低车辆发生碰撞事故的几率；可以帮助车主实时导航，并通过与其它车辆和网络系统的通信，提高交通运行的效率；帮助监管/监控方掌控车辆的实时、历史信息，提升车辆管控效率。
一旦车载终端通讯设备或车联网终端管理平台被黑客入侵，黑客可能间接或直接监控汽车的实时运行状态和车辆行驶轨迹，甚至可能对运行参数进行修改，这都将对正在运行的汽车造成不堪设想的后果。
现状
目前车联网安全行业研究人员相对较少，远远不如传统安全行业人员众多。在开展安全研究时又因为投入成本高，有极高入门门槛，同时车联网行业的错综复杂，应用的各种通讯协议规范、平台应用众多，导致对于独立安全研究人员来说对车联网安全研究入手相对来说比较难。
终端与服务端的通讯协议是车联网平台中最基础最重要的部分，起到连接和沟通两端的作用，交通部委和各省交通厅都对此制定了相关标准。而在诸多通讯协议标准中， 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等漏洞。
