2023 SDC 议题回顾 | 探索软件定义汽车的安全攻击面

【曲乐炜：资深安全研究员】

前百度资深安全工程师，曾负责百度AIoT产品安全保障工作，现为某自动驾驶公司安全负责人，负责车路云一体化产品安全保障、企业网络和数据安全防护体系建设工作。在WiFi、蓝牙、内核、安卓系统中均有深入研究，获得300+ CVE漏洞，多次获得谷歌安卓、高通、联发科致谢，被谷歌评为2022年度Top Bug Hunter，是紫光展锐芯片在全球获得致谢最多的研究员，BlackHat 2021 Europe/2022 Aisa/2022 USA，KCon 2023，5th AutoCS 2023 演讲者。

以下为速记全文：

今天我为大家带来最后一个议题——探索软件定义汽车的安全攻击面，我是演讲人曲乐炜，我之前在百度有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 的Native和QNX的模块交互，最终转化成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。

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