大家好,这里是海盗茶馆,我是海盗。
今天来点实际的搞车案例,但是由于一些原因,不能放一些特别具体的信息。请大家谅解。
茶馆科普之Tbox
Tbox 又称为TCU,是车内负责接入网络的设备单元。你可以理解成一个小型的操作系统+SIM卡。Tbox则是车与TSP(车厂的管理系统)之间沟通的中介。
Tbox比较常见的功能如收集车辆信息。上传到TSP,TSP会把消息推送到你的邮箱或者手机App。还有,当你通过App远程开启发动机或者车门的时候,TSP会把你的操作转化成命令下发到Tbox,Tbox再解析命令执行对应的操作。
Tbox的结构简单示意如下:
Tbox在车里的位置,再来一个示意图:
通过上面的示意图以及例子大家可以看到,Tbox是一个很敏感很重要的设备。也是远程非接触式攻击面中最重要的攻击点。
不过,Tbox也有前装与后装之分。前装是指出厂就带的,一般都是厂家事先做好的设备,购买车辆的时候直接包含的。后装是指市面上一些厂家,为了帮助本来不具备联网功能的车辆,实现车辆的监控与管理,后安装到车上的。市面上常见的有针对Audi的楼兰盒子,还有其他各种的车盒。感兴趣的可以自己找找看。
大家都知道,汽车虽然是某个厂家生产的,但是他用到的设备以及软件,大都不是车厂自己生产的。可以说,车厂是一个总装工作为主的厂商。各种零部件都是从供应商那里采购的。一级供应商可以成为tier1,就是直接供货给车厂的供应商。以此类推。tier1们,也有一些处于类似的情况,他们也是要采购不同的模块进行组装。Tbox就可以理解为车厂tier1 出的产品,但是Tbox的厂家,也有一些供应商,比如提供软件系统、硬件生产等。也有一些大的tier1,自己包揽大部分的环节,只采购或者外部一些模块。
信息收集
跟常规的渗透测试一样,搞之前先做些信息收集的事情是必须的,不然边搞边收集信息会耽误进度,并且会影响你的视野。当然,搞的过程也需要不间断的信息收集与整理。
我们的目标是一台电车。搞之前先去收集信息,比如Tbox的型号等。搞车的信息收集途径,其实与渗透测试类。举一些我常用的方法与途径:
- 1. 原厂的资料:包括不限于各种管理软件。比如volvo的VIDS、宝马的瑞金、大众系的ODIS等。里面都会包含一些重要信息。
- 2. 玩车论坛。很多动手能力很强的玩家会丢一些信息出来,有时候会对我们有比较大的帮助。比如WIFI信息等。
- 3. 安全论坛。直接国外放狗搜吧,很多相关的东西,不算太大众的安全信息,国内都不好找的很可能能找到。
- 4. 淘宝。
- 5. 修理店。
- 6. 官网。有些企业支持车主进行系统更新,官网会提供包括车机、Tbox在内的固件下载。如长安。
设备准备
搞车的一个门槛就是你需要有目标设备,但是并不意味你需要一整台车。所以如果再看到那些说“搞车你首先需要一台车”的专家,你就呵呵一下放过他吧。大家都挺忙的,不要浪费时间了。
设备采购这块一般可能都不知道怎么下手,但是,也没有那么难。比如万能的淘宝,随便一搜,还能搜到不少Tbox的信息。
不过,我不建议买全新的设备(这玩意儿不是手机等设备,新的没必要),旧的设备意味着运行了一段时间了,里面有些有用的日志跟使用痕迹,在我们分析系统跟应用的时候,都会有很大的帮助。所以购买所谓的拆车件比较好,很多拆车件也都会带上线束,让买家至少把usb跟电源的线头给你标记出来,这样你后面可以很容易的点起来。最重要的是,价格也合适,省钱。毕竟,花自己的钱搞研究还是能省就省吧。
我们拿到的目标设备就是使用了一段时间的。自己买个12V的电源就可以点起来。
攻击面分析
Tbox的攻击面分析类似于整车的攻击面分析了,但是因为我们要先分析再找漏洞,所以在实验室环境也会把一些非远程接触或者非接触的方面放进去。举个例子,Tbox的usb接口,即便你能接触车,也得把手套箱拆掉才能看到Tbox,在整车的攻击面梳理中,我们一般不会把Tbox的usb放进攻击面,但是,我们是实验室环境的目标是攻破Tbox,所以我们也会把usb放入我们的攻击面。
通过分析,我们这款Tbox的攻击面梳理大致如下:
- Tbox攻击面
- 1. wifi
- 2. usb
- 3. GSM/4G
部分Tbox会带蓝牙模块,用于手机的蓝牙钥匙,我这款Tbox不具备这个功能。
对类似的Iot设备的分析,大致有两种思路:
1. 先本地getshell,进行活体设备的调试分析。
2. 直接想办法获取系统固件,还原文件系统,进行静态分析。
3. 通过设备存贮器件的拆解去读取。
但是考虑到Tbox在车内的更新属于频次较低的操作,方法2基本没戏。而方法3第一是费钱,第二是还需要你具备一定的硬件操作的能力,拆个小米路由器的rom读取还原下问题不大,但是拆tbox还是心理没底的。所以,我们就直接方法1。
开搞
WIFI
点起Tbox,就会发现一个类似tbox-xxxxxxxx的名称的wifi。使用1234567890作为密码连入这个wifi,会自动获取一个192开头的ip地址。1234567890目前是比较常见的hostapd服务的默认密码,而且,大部分都不修改。
接入Tbox的子网以后,就可以做一些常规的端口扫描了。开放的也都是一些比较常见的端口。如23,53,3490.系统识别为linux/oelinux。
23、53就不说了,3490可能大家不常见,可以多说一下。
3490是一个叫dlt的开源应用开放的tcp端口。dlt全称是Diagnostic Log and Trace。是GENIVI下面的一个项目。用于系统的诊断,主要用于应用及系统的日志收集与整理,类似syslog。github地址
53是 dnsmasq 2.8.x,就不看了,比较新的版本,没有可以远程利用的漏洞。
搞定telnet
23直接telnet显示:
Mdm9607
login:
可以判断使用了高通mdm96xx系统的芯片,可以参考下附录链接资料。
前面扫描系统被识别为oelinux,试下默认的oelinux root密码,oelinux123,居然进去了。
进入系统就可以继续搞活体测试了。
还有一些设备,如楼兰盒子,usb接入也会进入一个内部子网,telnet也一样可以进去。
分析业务
oelinux中的服务跑的还挺多的,但是我们这里就不挨个分析了。常规情况下,一个陌生的系统,是需要从启动开始分析起的,这样就可以分析哪些服务是核心的,哪些被拉起的,做了什么事情。
ls / 发现,根目录下有一个app的目录,里面是一些DSxxxx这样以ds开头的二进制以及配置文件。ps一下,发现部分启动的服务也都在这个目录,基本可以断定,这个就是tbox的主要服务目录了。就是tier1自己负责的业务实现,比如远程车控。
app/log 目录下,发现不少日志文件,其中tspConnect.log 里面,包含了服务端下发命令处理的日志。这就是我前面说的搞台使用过的设备的好处。
整个业务主逻辑并不复杂(经过若干小时的分析之后):
- tspConnect 负责与tsp的交互,获取服务端的指令。解析指令并根据执行做相应的操作,遇到控车的指令,则会发送广播。
- 监听广播的dsvCom 服务,转化成具体的can信号。
- can信号传递给mcuCom服务,发送到CAN。
- 完成车门打开或者关闭操作,把结果再传回tsp。
可见,这个远控的业务逻辑入口就在tspConnect。虽然日志里有一些信息,但是属于解包过程了,可以帮助我们还原指令拆封过程,具体过程还是需要我们逆向tspConnect才能知道。
不过,在做这些之前,还需要确认一件事,就是这个传输过程是不是加密的,加密逻辑我们是不是能还原。
还原加密过程
丢一个编译好的arm的tcpdump进Tbox,顺利运行起来。
注: 这里不是太好实现原始业务流量的抓取,因为我们拿的是一个独立的设备,不在原有可用的业务链中。不过我们可以通过修改dns解析地址来伪造一个tsp,把测试环境的网络搞通之后,就可以进行数据包的抓取与分析了。
通过tspConnect.log日志分析可知,传输的数据是定长的,那就意味着,可能是某种特定的格式,有定长的数据长度,组合而成的数据。
通过抓包确定,数据传输过程并没有加密,就是常见的socket。那好,剩下的就是逆向分析tspConnect中的数据包拆解逻辑,理清楚逻辑,就可以实现tsp指令的伪造了。
此处省略1万字的ida分析tspConnect的过程。
最终还原出,指令格式
数据内容经过加密的,使用了AES加密,key呢?你肯定也想到了,在tspConnect里面。
经过其他同学的分析,确认,这里面的key,是对vin车架号进行变化生成的key,虽然每次都是一个动态计算过程,但是每次的key其实都是一样的。到这里,再结合tspConnect.log,我们就可以完美还原车控命令下发的过程了。
GSM劫持下
这里我们并没有通过完整的GSM劫持的测试。因为我们手头没有现成的劫持工具。所以就偷个懒,使用修改hosts文件的方式,服务端Python伪造一个tsp的server,tbox连上来的时候,伪server下发车控的命令,tspConnect.log的日志显示成功解析了我们的命令。说明已经实现了远程解锁了。
最后
其实还有别的地方我们没有展开去分析,比如移动端app的业务逻辑。
但是,实际分析的过程也远远不止上面描述的部分,实际上整个过程还是花费了不少的时间。
最后,希望可以继续关注海盗茶馆后面的无车搞车系列文章。
附录
- DLT : https://github.com/GENIVI/dlt-daemon
- MDM96xx : https://www.jianshu.com/p/8158b7c80aaa
还没有评论,来说两句吧...