2023 SDC 议题回顾 | 探索软件定义汽车的安全攻击面
2023-12-7 18:1:33 Author: 看雪学苑(查看原文) 阅读量:7 收藏

02

演讲内容

以下为速记全文:

今天我为大家带来最后一个议题——探索软件定义汽车的安全攻击面,我是演讲人曲乐炜,我之前在百度有5年的IoT产品安全保障的经历,现在做自动驾驶相关的产品安全和企业信息安全的保障,主要的研究成果是围绕安卓的生态系统,多次获得知名厂商的产品安全致谢,在2022年被谷歌评为Top Bug Hunter,相关的研究成果也多次在国内外的安全会议上做分享。

那么下面进入我们今天的正题,我将从如下4个方面来对本议题展开阐述,分别是背景概述,威胁分析,典型案例,总结建议。

首先来看,整车软件架构的演变,左边这张图是博世在2017年提出的,汽车电子电器架构发展的6个阶段,分别是模块化,集成化,集中化,域融合,车载电脑和车云计算,这里,我进行了对应。

传统汽车,采用的是分布式电子电器架构,ECU之间采用的是模块化,集成化,采用独立的ECU,并且基于CAN和LIN总线进行通信。

现代汽车,采用的是域集中的电子电器架构,将车划分为几大域,比如座舱域,动力域,底盘域等,部分通信模块采取以太网进行通信。

未来汽车,采用的车云计算,物理上简化线束复杂度,采用基于服务化的软件架构。

智能网联汽车发展至今,随着联网化和智能化的发展,尤其是新能源汽车的一股热潮,未来汽车的时代已经来临。

下面我们再来看,整车软件架构的一个案例,就是我们熟悉的特斯拉,我认为特斯拉是真正将软件定义汽车带到大家的视野中。

图中是model3的整车电子电器架构图,可以看到,特斯拉采用集中式的中央控制器,搭载了四个中央域控制器,比如自动驾驶及娱乐域控模块,右车身控制模块,前车身控制模块,左车身控制模块。

在自动驾驶及娱乐域控模块中,连接了大量的传感器,如摄像头,雷达,并且提供了辅助驾驶的能力,以及丰富的车载应用生态,如导航地图,车内娱乐等。通过软件实现与研发,极大提升了用户的体验。

第二个案例则是国内某新势力造车,从其连接架构图来看,其具备更加丰富的座舱应用生态,导航,娱乐,诊断,车内控制。其余外部的交互也更加丰富,如自动充电,手机蓝牙的控制,远程启动,无钥匙的解锁。提供了大量的远程控制功能,并且具备各个模块的OTA能力。

这里则是一组对比,左图是我在18年买的长安CS 15的内饰图,只有简单的蓝牙连接手机功能。右图是现代的新能源汽车,其丰富的车载应用的引入以及娱乐化的提升,使得汽车更像一部手机。

那么在第一部分的最后,我们再看来软件定义汽车的概念。这个概念,是2007年4月份,由IEEE首次提出。

真正带入大众视野的是特斯拉的商业模式的成功,特斯拉提出了以硬件为流量入口,软件为收费服务。打破了传统汽车卖车的一锤子买卖的商业模式,把汽车变成了一款能通过软件迭代开发,持续后向收费的产品。

实现软件定义汽车的核心思想,就是面向服务的思想,也就是把车内复杂的功能,以服务的形式满足各个应用场景的需求,这样使得软件开发变得更加敏捷和高效。但是大量的软件开发也引入了安全风险。

所以,面向服务的架构,最重要的就是分层,提到分层,一个我认为做的最好的就是Android Open Source Project,那么Android同样为了满足软件定义汽车的需求,开放了Android Automotive OS来给主机厂做定制。

AAOS的整体设计,集成了Android 分层的思想,在Framework层面定制了Car相关的API,来供APP调用。在System Service层面,提供了Car相关Service的实现。在HAL层面,留给OEM来依据自身需求做定制开发。

目前主流的新势力造车,还是基于原生的AOSP来定制,相当于借用AAOS的思路来完整实现自己的车机能力。

第三部分,我们来看威胁分析:

整车的威胁分析,是ISO 21434主导的标准方法论,目的是通过系统化的分析明确网络安全需求,考虑的要素则是系统化的防护方案。

要求我们要有持续的网络安全活动,要通过风险评估,TARA分析,明确网络安全需求。要求安全能力覆盖概念阶段,产品开发阶段,验证确认阶段,生产阶段和运行维护阶段。

这套方法论我相信是各个主机厂以及我们公司关注的,并且持续落地的,关注的更多是面,而不是点。

下面这张图,是我们针对主流的座舱系统做的,关于点的威胁分析。

目前座舱域,主流的方案则是虚拟化的方案,也就是我们接触到的车机其实是一个运行在QNX上的Android,车机负责与用户交互,QNX负责与底盘交互。我们知道QNX其实是符合功能安全要求的。

APP层面,提供系统界面,地图服务,内容生态,车家互联,应用市场。

框架层面,则是提供了一整套控车服务,比如车身控制,连接控制,仪表通信等。

下游的Native和Driver层面,则是控车服务的进一步实现,并且与QNX在虚拟的网卡中进行通信。

那么作为一个恶意的APP,可以通过硬件外设的方式去安装,比如USB,蓝牙等,也可以通过应用去安装,比如应用市场中,提供微信,QQ等,通过文件传输来执行。

恶意的APP可以有两条攻击路径来最终达到控车的目的,第一条攻击路径,是通过AIDL,调用系统服务,进一部数据流转到Native层面,由Android NativeQNX的模块交互,最终转化成CAN控制。

第二条攻击路径,是APP直接通过TCP的方式/或者NFS的方式,来与QNX进行交互,对车进行控制。

那么我们在研究过程中,都面临哪些困难与挑战?

第一,是实车测试环境的缺乏,作为独立研究员,购买整车去拆解研究是不现实的。

第二,量产车辆往往在软件调试接口做了控制,像传统的ADB,TELNET,SSH等都做了封禁或强密码管控。

第三,系统的访问控制,这点是车机比IOT设备做的好的地方,目前主流的车机均开启了Selinux,这导致IPC通信,文件系统的访问大受限制,极大削弱的漏洞的影响力。

最后,就是封闭的应用生态,目前主流的车机禁止随意安装三方APP,仅支持从其应用商店中安装。

针对缺乏实车测试环境的问题,我们可以购买单个零部件,通过台架的方式去做研究。

现在车安全逐渐引起重视,各家也会不时的组织众测及攻防演练活动,这也是一个好的途径。

那么针对调试入口缺乏的问题,可以着手寻找车辆的工程模式。各地的车展,也有机会接触到最新的款式,很多车辆也是调试车,拥有工程模式和调试入口。

下面,我们将介绍几个典型的案例,这些案例都是由于软件定义汽车,所引入的安全风险。这些案例都集中在座舱域。

案例1,某国产汽车多处漏洞突破。

这款国产汽车是典型的QNX虚拟化的Android架构,我们在某些特殊场合下,可通过调试方式访问该车辆,并且通过USB来安装应用。

在Android端,其提供三个主要功能,第一个是QNX Control,顾名思义,就是与QNX交互的模块。第二个是CarControl,也就是与车辆相关控制的模块。第三个是TboxControl,也就是与Tbox相关的控制模块。

这里存在的问题,则是其三个模块所以来的Framework存在重大权限设计缺陷,普通APP可对系统服务进行调用。

第二个问题,则是车内网络的访问控制存在重大缺陷,APP可直接走内网通道向QNX发送指令。

问题1,系统服务缺乏权限校验,可导致恶意控车。

缺陷模块为com.living.vehicle.carservice.ICarService,其通过AIDL提供如下四个接口:

Transaction ID,1,对应的函数是获取CAN信号

Transaction ID,2,对应的函数是发送CAN信号

这个接口的使用场景则是,给车内的系统APP提供API,如空调设置,车门设置,上游模块是CarSystemServer。

当我们分析了CarSystemServer之后,便能够还原出其控制指令,如右图所示:

506对应的开车门

616对应的解锁命令

然后形成了完整的POC,通过AIDL调用com.living.vehicle.carservice来发送车门开启和解锁的指令。演示视频如右图所示。

第二个问题,则是Tbox模块的,同样是其上游服务缺乏权限控制。

模块com.tbox.service.TboxService,提供各种服务,可打开飞行模式,拨打电话,获取设备的IMEI。

左边是设置飞行模式断网的POC,右边是我们的控制指令传输到HAL层面,HAL通过socket的网络通信,把payload传输给Tbox。

我们通过逆向和抓包的手段,对网络协议做了完整的还原,0xa3则是飞行模式的命令字。

在刚才的问题中,我们看到,车机可以在其Native模块与QNX或者Tbox建立socket通信,把上游的数据通过网络的方式发送到下游。

这里左边的图,是我们标准的调用流程。右边的图,则是我们绕过一系列的调用,直接通过socket发送原始数据。

整个交互流程如左图所示。

车机先发送一段消息,给QNX 的8890端口。QNX回复同样的消息。车机后发送0xff 0x55 0x00 0x00,QNX回复一段数据。之后便发送整个的Payload,Payload中包含了指令数据,右边则是我们直接通过网络来开启车门。

当我们能够通过网络直接与QNX的模块做通信,那么我们便可以对QNX侧的协议解析做漏洞挖掘或模糊测试工作。通过模糊测试,我们发现了一处QNX进程中的内存破坏漏洞。

左边是QNX的core dump文件,下面是Crash log。形成的效果,则是会让QNX重启,这个就是非常严重的影响了。

第二个案例,我们来讲我们在某个比赛中发现的整车控车漏洞。

该车辆没有任何的调试入口,但是我们在某个论坛中发现了该汽车车机的固件包,我们进行了固件逆向工作。发现在其固件包中,隐藏了工程模式的APK,DevelopmentTools。该模块默认是不启动的。

我们发现,该车机能够安装三方应用,通过USB的形式安装,也能通过应用市场自带的微信,或QQ来安装。

逆向了DevelopmentTools后,发现有开启ADB的方式,我们通过POC起吊了该组件,最终成功获得了ADB shell。

之后,我们分析了整个车机的Framework和SystemService,发现三大核心服务,车身控制,空调控制,后备箱控制。直接调用这三个服务是不可行的,因为其API签名要求必须是系统APP才能调用。但这三个服务内部均调用了AutoDeviceManager,这个模块是缺乏权限控制的,因此我们可以直接调用该模块的API,发送更底层的命令,达到控车功能。

下图是我们通过AutoDeviceManager获得车机的VIN码:

这里是我们越权控制的一个演示:

案例3,这个案例是由于供应链的引入导致的问题,我们知道,厂商的车机系统,整体代码是由三部分组成,底层芯片系统,芯片系统会提供一套完整的BSP代码,以适配其硬件架构。第二部分是OEM,比如中科创达,博世这种tier1,他们负责在BSP的基础上,做二次开发适配厂商的需求,比如一些娱乐相关的。


第三部分,才是主机厂的座舱团队开发的适配其自有车型的功能。第四部分,是引入的三方APP如地图,影音,娱乐等。

其中在BSP层面,往往会引入安全漏洞。我们在某芯片厂商中发现了一处本地提权的漏洞,该漏洞同样影响了某些车机。该模块是个root 进程的模块,普通APP可以利用该模块的漏洞,以root权限执行任意命令。

右边是完整的POC,最终的执行效果如下图所示。

最后一个案例,也是供应链相关问题,我们在Android上游的Linux Kernel的USB协议栈中发现了一处数组越界,该漏洞影响Android所有版本,因此基于Android开发的车机产品同样受影响。右图是一个漏洞演示,USB模块的0 day导致的车机重启。

那么最终,我们总结一下该议题。

首先我们分析了软件定义汽车面临的安全风险,软件定义汽车在给用户带来先进体验的同时,引入了大量安全问题,包括SOA的服务存在的设计缺陷,车内网络缺乏隔离,导致的恶意控车,车门解锁等风险。

我们针对漏洞做了组合利用,并且在实车中验证,展示风险的危害。

最后的建议:

1. 要重视车载APP带来的安全风险,警惕Framework,系统应用的未授权接口;

2.  车内网络需进行隔离和访问控制;

3.  重视供应链漏洞,例行安全补丁及OTA。

以上就是我的演讲,这里特别感谢一下柯懂湘和闫晗对本议题作出的贡献。

*峰会议题PPT及回放视频已上传至【看雪课程】https://www.kanxue.com/book-leaflet-171.htm 

PPT及回放视频【未购票者收费】;

【已购票的参会人员免费】:我方已通过短信将“兑换码”发至手机,按提示兑换即可~

《看雪2023 SDC》

看雪安全开发者峰会(Security Development Conference,简称SDC)由拥有23年悠久历史的顶尖安全技术综合网站——看雪主办,面向开发者、安全人员及高端技术从业人员,是国内开发者与安全人才的年度盛事。自2017年七月份开始举办第一届峰会以来,SDC始终秉持“技术与干货”的原则,致力于建立一个多领域、多维度的高端安全交流平台,推动互联网安全行业的快速成长。
钻石合作伙伴
黄金合作伙伴

球分享

球点赞

球在看

点击阅读原文查看更多


文章来源: http://mp.weixin.qq.com/s?__biz=MjM5NTc2MDYxMw==&mid=2458531111&idx=1&sn=fc09bef1d3fe1392c69edb5fca0d1f10&chksm=b18d05ad86fa8cbb5b15c479cec1ec476c0efe5665966f896690a961a695beb553e06a5faa11&scene=0&xtrack=1#rd
如有侵权请联系:admin#unsafe.sh