根据大多人说法,车联网安全就是从IOT安全过渡的,比如一个小固件,分析其安全性只需要通过分解逆向,找到入口点,就可以进行了多样化攻击,这或许在常见的IOT中,多见于路由器攻击方面,但是车联网其实更接近于一个生态,不只是小固件组成,如图所示,其基带(包括wifi,蓝牙,无线电频率等)攻击、云端控制攻击、物理接触近距离攻击等

其中, 比较容易理解的是ADAS就是中央域控制器,拿下中央域控制器就好像拿下了核心,如果对ROS有所了解的伙伴应该很快就知道,中央域控制器被外部拿下,则整个汽车都可以说被控制住了,因为这个就类似是ros-core,一旦core被挂掉,整个车的所有通信功能直接报废。
不过一台车的对外网的连接,并非直接通过ADAS去对外连接,也非车机自带的wifi外连,而是通过T-box固件去对一台车做控制,大部分情况下,T-box本身也有证书校验的效果。
那说回来,从一辆车的了解开始,那就肯定是从协议入手,最基本入手的就是CAN协议
CAN协议,可以说是入手一台车基本接触的一个控车协议,其中,根据官方说法,CAN 总线采用差分信号方法“差分信号是一种使用两个互补信号以电气方式传输信息的方法,该技术将相同的电信号作为一对差分信号发送,每个信号都在自己的导体中。这对导体可以是线路板上的导线或线迹。”
这里不直接废话这种官方低电平高电平的概念东西了,了解可以从官方文档中去阅读,这里不难可以看到,CAN的攻击其实就是基于重发的威胁,入门的测试就是通过OBD口(如图示),连接到CANOE或者Kvaser去监听。

软件的监听方案这里就不多做介绍了,直接通过linux的配置设置比特率后建立监听
设置好以后直接通过apt install can-utils去直接安装CAN发送监听命令
1 2 3 4 5 6 7 8 9 10 | 监听:
1 、全局监听
$cansniffer
$candump any
2 、单个CAN口监听
candump can0
发送:
cansend can0 canid
canplayer - I xxx
|
看过一个比较友好的例子https://github.com/zombieCraig/ICSim
这个可以直接通过软件层面去运行模拟操作做CAN重放攻击

这里举例最简单的攻击,直接通过操作左转灯
这里直接通过candump做重发,初步验证的时候,由于垃圾数据较多,这里直接全部写下全部重发
然后直接通过canplayer去重发这个can报文

试验至此,就已经说明了can重放的漏洞是存在的,有且只有一个CAN报文可以控制。其中后面可以通过二分法获得详细的报文是188#01000000,这里不做介绍,canplayer就已经说明了漏洞存在。
为什么这样说呢,因为现在SecOC的介入,作为一种鉴权的手段,CAN重发就已经失效了,这里的CAN重发引发的危害其实算是利用的可能性几乎为0,因为司机不会蠢到开着车让你接着OBD口在做攻击。
因此,CAN的利用条件大部分就是只能基于通过中间传输,如车机的控制,T-box的云端控制等(其中车机的automotive目前还在研究中……)
至于云端,这里我在2022年数字中国车联网CTF比赛中遇到一道特别有趣的题目,模拟诠释了一下CAN的网络传输方案

这里直接有着控制车辆的功能,但是如果用bp抓包只能看到一些很明显的操作

而 传输的结果并不能直接告知我们的是有关开车逃跑的信息

而是直接返回json文件
而这里的任务是直接打开车门

说明这里还有别的数据
通过源码可以看到,这里是通过socket传输

在wireshark的抓包验证

这里就确定了can的data利用,因此,这里我们直接可以通过脚本复现:
1 2 3 4 5 6 7 8 9 10 11 12 13 | import websocket
host = "123.57.188.238:35069"
ws = websocket.WebSocket()
ws.connect( "ws://123.57.188.238:22734/hack/control" )
c = []
c.append( "17E#00000E000000" )
c.append( "166#D0320009" )
for i in c :
ws.send(i)
print (ws.recv())
|

这里就进入到下一步了
这道题虽然只是作为CTF,呈现了一种云端控车协议发送的模式,显然告诉我们,控车协议发送并未传统的web类,直接通过http去做控车,当然,现实情况真的是这样吗?
通过对国内某厂家的APP分析,经过一系列的加解密分析,包括对参数分析,可以得到几个关键信息:
1 2 3 4 5 6 7 | pin码:作为控车的验证码,一次一用(用完即废,需要重新申请)
carid:作为车辆的唯一识别码(不变)
token:手机登录的识别码(根据时效改变)
控车的操作:如控制车窗为open_windows
|
只需要结合这几个信息,加密后就可以向云端发送申请,申请后云服务器会对车辆发送对应的信息,这个信息类似于上面CTF操作一样,直接收到对应请求后,服务器对车辆上的T-box发送控车candata等信息,然后达到控车效果。
因此,CAN作为最直接控车的一环,其实也是最底层控车的一环,虽说以后说不定会改为MQTT,但目前来说,控车大部分还是基于CAN的协议进行的, 因此,CAN作为入门的一项,也作为了解车联网的初步。
这里不得不提一下,以后如果SecOC的介入后,鉴权就开始了,这时候CAN的发送就是带有新鲜度值了,没办法实现协议重发这些效果了。


[注意]看雪招聘,专注安全领域的专业人才平台!