-
-
[原创]谈谈车联网安全入门那些事
-
2022-6-13 12:42
-
谈谈车联网安全入门那些事
根据大多人说法，车联网安全就是从IOT安全过渡的，比如一个小固件，分析其安全性只需要通过分解逆向，找到入口点，就可以进行了多样化攻击，这或许在常见的IOT中，多见于路由器攻击方面，但是车联网其实更接近于一个生态，不只是小固件组成，如图所示，其基带（包括wifi，蓝牙，无线电频率等）攻击、云端控制攻击、物理接触近距离攻击等
其中， 比较容易理解的是ADAS就是中央域控制器，拿下中央域控制器就好像拿下了核心，如果对ROS有所了解的伙伴应该很快就知道，中央域控制器被外部拿下，则整个汽车都可以说被控制住了，因为这个就类似是ros-core，一旦core被挂掉，整个车的所有通信功能直接报废。
不过一台车的对外网的连接，并非直接通过ADAS去对外连接，也非车机自带的wifi外连，而是通过T-box固件去对一台车做控制，大部分情况下，T-box本身也有证书校验的效果。
那说回来，从一辆车的了解开始，那就肯定是从协议入手，最基本入手的就是CAN协议
CAN协议
CAN协议，可以说是入手一台车基本接触的一个控车协议，其中，根据官方说法，CAN 总线采用差分信号方法“差分信号是一种使用两个互补信号以电气方式传输信息的方法，该技术将相同的电信号作为一对差分信号发送，每个信号都在自己的导体中。这对导体可以是线路板上的导线或线迹。”
这里不直接废话这种官方低电平高电平的概念东西了，了解可以从官方文档中去阅读，这里不难可以看到，CAN的攻击其实就是基于重发的威胁，入门的测试就是通过OBD口（如图示），连接到CANOE或者Kvaser去监听。
软件的监听方案这里就不多做介绍了，直接通过linux的配置设置比特率后建立监听
1 2 3 4 5 | #ifconfig -a#sudo ip link set can0 type can bitrate 1000000 restart-ms 1000#sudo ifconfig can0 up |
设置好以后直接通过apt install can-utils去直接安装CAN发送监听命令
1 2 3 4 5 6 7 8 9 10 | 监听：1、全局监听$cansniffer$candump any2、单个CAN口监听candump can0发送：cansend can0 canid#datacanplayer -I xxx |
看过一个比较友好的例子https://github.com/zombieCraig/ICSim
这个可以直接通过软件层面去运行模拟操作做CAN重放攻击
这里举例最简单的攻击，直接通过操作左转灯
这里直接通过candump做重发，初步验证的时候，由于垃圾数据较多，这里直接全部写下全部重发
1 | #candump -l any |
然后直接通过canplayer去重发这个can报文
1 | #canplayer -I candump-2022-06-13_112346.log |
试验至此，就已经说明了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 websockethost = "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的发送就是带有新鲜度值了，没办法实现协议重发这些效果了。
[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
