安全车联网漏洞

一次OBD dongle漏洞挖掘

orzCat2023-09-142025-03-26

一次OBD dongle漏洞挖掘

来源

阅读了一篇讲无线OBD dongle安全问题的文章，文章中分享了攻击思路和研究成果并给出了工具，我购买市面上某一销量不错的产品试图按照文章给出思路进行攻击但是失败，最后用自己的方法进行挖掘，发现了部分问题。

文章内容

对无线检测仪安全检测

攻击面

广播阶段：无线检测仪通过wifi或者蓝牙连接使用者，在连接前需要将自己信息广播此时攻击者发现并尝试连接

连接阶段：与无线检测仪建立连接根据无线检测仪的不同可能需要密码PIN码等验证不需要验证既可以任意连接

传输阶段：建立连接后通过与无线检测仪通信再与OBD接口交互根据无线检测仪的通信协议可能需要绕过身份验证步骤之后可以将CAN总线消息发送到目标设备

漏洞种类

V1 没有连接层或应用层认证

没有连接层身份验证，可以任意连接无线检测仪

没有应用层认证，建立连接后可以尝试直接注入CAN总线消息进行通信

不同的无线检测仪可能有不同的身份验证方法，如使用WPA2-PSK验证连接，或者通过按钮使检测仪进入可发现模式

V2 连接使用者设备后仍可被连接

对于多数设备，一次只能连接一个设备，但是对于部分使用wifi的检测仪，可能会配置为允许多个设备连接和访问

V3 无法过滤未定义的CAN总线消息

在通信阶段尝试发送未定义的CAN总线消息，这些消息将被检测仪接收被传递到CAN总线，同时部分检测仪可能支持非诊断功能，攻击者可以通过对配套应用进行逆向工程提取有效的分诊断消息进行攻击

V4 受到固件的破坏

对于具有固件升级需求的无线检测仪，使用配套应用将固件数据包传输到检测仪，可能通过欺骗检测仪的方式破坏其固件。

对于没有身份验证的检测仪，如果其没有完整性检查，可以通过注入修改后的固件进行攻击，或者通过配套应用程序进行固件提取用于发掘更多问题。

V5 使用广播信息标识检测仪漏洞状态

在确定了各种漏洞之后，将分析在广播阶段是否可以对这些OBD-II检测仪的漏洞进行指纹识别。这可以帮助攻击者确定要攻击的检测仪，然后相应地进行攻击，并且这种指纹识别可以显着提高攻击成功率。

攻击威胁

信息泄露

只需要漏洞V1即可连接和读取私有信息

攻击者可以使用诊断PID 09 02获得唯一标识汽车的车辆识别号VIN，还能够通过PID读取车辆的诊断数据，包括里程表，燃油费率，发动机RPM等，这侵犯了车主的隐私。

通过向基于ELM327的OBD-II检测仪注入AT MA命令，就可以转储CAN总线流量以分析CAN总线协议。当V3漏洞存在时，攻击者能够收集与安全相关的CAN总线控制消息以执行任意CAN总线消息注入攻击

财产盗窃

需要漏洞V1和V3。通过注入能够禁用无线锁定功能的CAN总线消息。

攻击者首先找到目标车辆，注入消息禁用无线锁定功能，使用者使用钥匙远程锁定离开后，无线锁定失败。

车辆控制干扰

通过V1漏洞和V3漏洞，将诊断CAN总线消息发送到车辆，以达到DoS攻击的目的。使用控制相关的消息可能会干扰车辆控制

车载网络渗透

通过漏洞V1和V4，会允许未经授权的攻击者发送恶意固件数据包，用于破坏检测仪的固件，同时由于检测仪直接与CAN总线相连接，可以通过替换固件来渗透车载网络。

设计方法

使用DONGLESCOPE进行对检测仪的动态检测

读取测试。使用诊断PIDs从车辆中读取VIN。
写入测试。DongleScope发送预定义好的更改里程表单位的CAN总线消息。
过滤测试。注入10个任意的CAN总线消息，以测试仪器是否具有消息过滤功能。
Fuzzing测试

Donglescope

根据测试仪不同模式的mode参数向client_socket发送消息，进行CAN总线消息注入测试

def inject_message(mode, client_socket, message, interval=0.5):
  if mode == 0:
    \# Wi-Fi
    client_socket.send(b"%s\r" % message)
    time.sleep(interval)
    data = client_socket.recv(1024)
    print('Received: ', repr(data))
  elif mode == 1:
    \# Bluetooth
    client_socket.send(b"%s\r" % message)
    time.sleep(interval)
    data = client_socket.recv(1024)
    print('Received: ', repr(data))
  else:
    \# BLE BLE_write_with_response(client_socket, message, interval)  # client_socket is a peripheral instance

设备的信息需要在config.json中进行配置，并在main.py中选定

根据使用的通信方式不同，执行不同的逻辑。对于Wi-Fi，通过创建socket连接并调用相应的函数进行消息注入测试；对于经典蓝牙，通过扫描附近的设备，并根据设备名称选择目标设备进行连接和测试；对于蓝牙低能耗，通过扫描和连接外围设备并执行测试

需求环境

安装 pyble PyBluez 包

使用总结

适用于有大量的OBD dongle，进行自动化的分析，对于单个的设备来说可能不是很好用，逻辑很简单就是连接然后发送各类消息，但是比如我测试的设备，蓝牙内部的服务进行了封装，发这些消息是没办法响应的

Bluetooth_scanner

github上找的一个简单蓝牙扫描脚本并可以进行fuzz测试

踩坑路线

OBD dongle测试

现有脚本用不了

在虚拟机中可以使用已经有的脚本donglescope和bluetooth_scanner，但是后者只支持扫描普通蓝牙设备，然后前者因为虚拟机没有BLE适配器。（这里我后来尝试使用蓝牙适配器，但是一直打不开我的蓝牙适配器，不过后面也没再试，脚本解决不了我手上设备）

然后我在windows环境下使用bleak自己编写脚本进行了一些信息的收集，包括mac地址服务id等等。同时手机上也使用了nRF BLE调试软件实现一样的功能，并且更加简单。nRF connect非常好用，后面也基本全部靠它。

环境搭建踩坑

想自己写脚本的话需要模块，不同模块各有限制

常用的蓝牙模块

windows上对于该BLE设备我选用使用bleak模块编写脚本

配套软件连接失败

我这里用的OBDII模拟器，在尝试使用配套软件连接的时候一直显示进入不了OBD系统，但是能连接上，一开始以为时不是实车的原因，后来发现是需要模拟器点火状态然后给一定的初始速度就可以了

抓包抓错

一开始不太懂BLE协议（现在也不太懂）抓的hci_log，也就是手机生成hcilong的文件，然后通过adb传到电脑上分析（鸿蒙系统要使用别的）。但是分析了半天全是malformed packet，其实想抓两设备间的通信报文要抓空中包，hci报文只是hci交互的内容。

挖掘过程

设备信息

型号：AD20
厂家：xxx
蓝牙版本：BLE5.0
序列号：AD20-NOUD1402059
激活码：ARRT30

配套软件信息

配套的软件通过扫描设备上的二维码或者输入序列号加激活码可以连接无线检测仪，要给一定的怠速才能进入OBD系统，否则会显示进入OBD系统失败断开连接。

连接后因为使用OBD模拟器的缘故，需要自行输入车辆信息完成后可以读取车辆的信息等

软件也支持清除故障码

分析阶段

获取mac地址

因为使用BLE通讯，可以使用nRF connect APP直接扫描附近BLE设备，也可以使用BLE相关模块编写脚本扫描

该设备的广播中自带设备名称很容易找出来

MAC地址：1B:59:2B:70:68:3C

连接尝试

使用nRF connect或者相关模块编写脚本，连接该设备并查看相应服务

有128位UUID的自定义服务，交互的内容即通过该服务完成，该服务特征中有一个可写一个响应，随意写入一些command没有响应

数据包抓取

使用hdc将手机软件连接设备后的hci日志导出分析

可以看到会有响应，但是hci中不能查看更多信息，需要抓通信包

使用ubertooth one抓取通讯包，抓包过程由于BLE三个频道跳转需要重复抓（软件解除绑定后重新连接设备时可以直接被抓到）

主要分析数据包中的write command和respond

其中某一command和对应响应：

对0x0011写command aa0f0d60090b0807df020100 00 00 00 00 00 b3，有响应：

分析大量对应的command和响应，抓到的报文中的command 格式相对固定，响应的内容也是对应command相应固定。即响应给出的是针对command的回复，而不是具体内容

对于其余没有command对应的响应进行分析，有部分的提示消息，但是抓包过程可能丢失，都不完整

初步分析该服务是通过给指令后自己开始预定的操作，然后回复预定响应

写command测试

使用nRF connect进行command写入的测试，上一步抓包中的command都是写入自定义服务的handle11中，直接在nRF connect中将抓到的command重发一遍

跟预期推测一致，大部分的command写入后，响应会给出对应的响应

有几个command写入后，会给出有提示性的响应

1	aa 01 03 60 02 01 82 e3

响应序列号 aa 2e 03 60 11 01 00 5d

aa 2e 03 60 11 01 00 5d

[OBD]EcuID:01 E8 08 07 DF 02 01 0C 00 00 00 00 00 08 07 E8 04 41 0C 16 3E 00 00 00

[OBD]Rn 1:41 0C 16 3E

[OBD]01 04 E8 0C 16 3E

[OBD]RPM-2:[5]1423,t=816982

[OBD]ECUID:01 E8 08

......

多次写入aa 98 03 60 11 01 00 eb该指令，响应中可以得到车辆的速度转速等信息，包括ECUID

[OBD]vin flag-not support11

[OBD]vin_NOTSuPP22,time=-30-01-01 16:00:06

[BLE]--->ble connect time=-30-01-01 16:04:52

[COMP] [write,965],start addr=0806D000

......

多次写入响应时间相关信息vin相关提示

有些指令写入后，响应不能一次发完，需要再多次写入将响应中的内容导出来，跟推测的服务机制一致

暴露问题

随意连接随意写入

该设备可以随意连接和随意写入command，但是由于服务机制是内部封装的，只能通过抓已经发送的确定有效的command进行重发

序列号问题

通过序列号和激活码是可以直接通过使用软件进行正常连接的

而激活码固定是6位字母数字组合并且不分大小写很容易爆破

获得这两个信息后可以使用软件连接该设备进行清除故障码等操作

序列号漏洞攻击

获得序列号

在用户关闭软件后，OBD设备不取下来就可以被扫描到

不确定对于不同的设备，获取序列号的command是否相同

若不相同需要先提前扫描得到mac地址，在用户正常使用时使用ubertooth进行抓包，可以根据包中command与响应对应的方式确定内置的command是否一致，也可以直接抓到获取序列号的command

在OBD设备待机时连接进行command写入

可以获得序列号AD20-N0VD1402059

爆破激活码

选择手动输入进入输入界面，通过autojs脚本进行爆破

激活码6位不区分大小写

使用脚本进行遍历破解，没有错误次数限制（这里的脚本需要跑的时间不是一般的长，但是这里不需要设备在线，也就是说可以一直挂着跑出激活码）

破解完成后就可以进入绑定模式，可以连接设备

绑定机制

我一开始是用一个账号测的没发现问题，后面又注册了个账号发现如果用户绑定了设备，那么再去绑定它只会显示设备已绑定，没办法暴力出激活码，只有非绑定状态（更换使用车辆，多用户使用，4S店使用）可以暴力。

总结

一个条件比较苛刻的小漏洞，用处不大只是实现了该设备有不安全的地方

同时该设备的分析还有很多遗留问题可以再去挖掘：

BLE服务究竟是怎么样的，真的是内部进行了封装吗，command的格式分析，响应的格式分析

激活码验证不需要设备开启说明直接是服务器去校验了，能不能通过逆向apk分析去进行绕过

鉴于自己apk逆向分析的能力还比较弱，这个设备的分析就暂时搁置，后面可能考虑购置wifi和普通蓝牙的OBD dongle分析