《电子技术应用》
您所在的位置:首页 > 通信与网络 > 业界动态 > 专题·智能网联汽车安全 | 车联网安全新型攻击范式“空中跳跃”

专题·智能网联汽车安全 | 车联网安全新型攻击范式“空中跳跃”

2021-09-18
来源: 中国信息安全
关键词: 网联汽车 安全

  近几年,随着云和物联网技术的快速发展,汽车领域也发生着深刻的变革。各厂商为汽车提供了更加智能化的功能,如手机钥匙、语音控制和寻车等,但是随之而来的安全问题也更为突出。例如在电影《速度与激情 8》中,黑客可以在任意地点触发攻击,恶意控制大量汽车在街道上肆意横行。作为观众的我们不经产生一个疑问:这种远程遥控汽车是导演的天马行空,还是真实存在于现实世界中?为了解答这个问题,本文将揭示针对智能网联汽车的新型攻击范式,以 2 个真实案例进行分析,并提出缓解措施。

  一、车联网架构和安全特性

  1. 车联网架构

  随着万物互联时代到来,车联网已经广泛应用于现代车辆。基于云、5G 和消息队列通信等技术,智能网联汽车具备手机钥匙、语音控制和智慧投屏等功能。例如,用户即使没有带钥匙,也可以通过手机控制车门和车窗,这些智能化功能方便了人们的生活和出行。作为支撑汽车智能化的技术架构如图 1 所示,“用户<->云<->汽车”,用户利用手机应用程序,通过蓝牙和 Wi-Fi 等近场通信协议与车载通信模块(T-Box)和中控主机进行数据交互,实现智慧投屏等功能。或者通过蜂窝网络与云侧通信,以此突破地理的限制。云侧则与车载T-Box 进行数据交互,采用机器对机器(Machine toMachine,M2M)技术通信模式,维持双工通信隧道,以此增加时效性。

  图 1 车联网架构

  2. 车联网安全特性

  与此同时,车辆丰富的功能和通信方式也让其智能化“外溢”,产生了新的安全风险,增加了更多的攻击面,近场无线通信的汽车终端或者在互联网种的云平台都成为攻击者的目标。车联网安全可分为空间和时间两条线。

  空间上,依照车联网架构可以分为用户侧、云侧和车侧安全。

  用户侧安全。 智能网联汽车提供了丰富的交互功能,这对于用户而言,主要通以手机应用作为交互对象,这就可能存在 App 安全问题,例如,个人隐私泄露、二次打包和登录验证缺陷等漏洞。

  云侧安全。云技术的使用增强智能网联汽车适用范围,让查找车的位置和远程开启空调等功能成为可能。但云平台也存在各类安全问题,比如传统的 Web 安全问题,SQL 注入、XSS 漏洞和逻辑漏洞等,也会增加安全风险,攻击者只需通过云侧问题攻击车辆,降低了攻击成本,增加了攻击范围。

  车侧安全。智能网联汽车包括各类终端,如T-Box、中控主机和行车记录仪等。终端包含了丰富通信方式,也存在各类安全风险,比如命令执行和缓冲区溢出等漏洞。

  时间上, 从攻击者的角度审视汽车技术变革对车联网安全带来的影响,可将汽车技术的发展分为以下三个阶段:

  传统汽车。其影音娱乐系统智能化程度不高,攻击者一般通过影音娱乐系统的 USB 接口和车载OBD 接口作为攻击点,这种攻击方式通常需要攻击者物理接触汽车。

  智能网联汽车。为了方便用户的使用,汽车采用 WiFi、蓝牙和蜂窝网络等通信方式,加强与用户的交互,并且增加了中控和 T-Box 等计算单元。对于攻击来说,攻击面进一步扩大,可以通过近场无线或远程的方式进行攻击。

  自动驾驶。自动驾驶技术的发展打破了机械控制的隔离,可以通过 CAN 总线或者以太网等通信方式来控制油门等,让攻击者有了操控汽车的技术可能性。

  汽车作为复杂系统的集合,自身各种 ECU 通过 CAN 总线串连起来,随着汽车智能化发展,车载以太网也被用于车内设备间通信技术,比如特斯拉的车身,包含有以太网和各种CAN 总线,通过车载网关让各种网络技术进行通信。因此,对于攻击者来说,攻击向量主要是通过车联网终端,再进一步渗透车辆内部网络,形成完整的攻击链。综上所述,智能网联汽车存在被远程遥控的可能性,这也回复了本文开篇提出的问题。

  二、“空中跳跃”攻击范式

  通过对车联网架构研究可以看出,远程遥控汽车在技术上存在可能性。随着汽车功能业务逻辑逐渐向云转移,与云结合的安全问题日益突出。以往的研究大多是将云和设备的问题分割开来独立分析,忽略了车侧和云侧之间的相互影响。下文将揭示车联网安全中的新型攻击范式——“空中跳跃”,展示攻击者如何远程攻击或控制汽车。

  1. 消息队列协议通信

  在智能网联车应用中,大量采用消息队列通信技术,比如消息通知、远程控制、位置推送和 OTA 更新等。消息队列协议允许应用程序通过云端服务中转通信,并且消息队列会在应用程序未连接的时候临时存储消息,等待设备在线后发送,以保证设备不在线时消息数据不丢失。常见的消息队列协议包括 MQTT、AMQP、STOMP 等。由于 MQTT 协议轻量级的特点,在车联网领域有着广泛的应用场景。

  消息队列协议通常为三方通信协议。首先,消息的订阅者向消息队列服务订阅消息,告诉服务自己感兴趣的消息主题,消息队列服务会监听并等待接收该主题所对应的消息;之后,消息的发布者将该主题所对应的消息发布至消息队列服务;最后,消息队列服务会根据消息主题,将此消息转发至对应的订阅者,订阅者收到消息,解析并处理。

  2. “空中跳跃”攻击范式

  在这个应用场景中,存在一种结合云和设备(车)的攻击范式——“空中跳跃”攻击,如图 2 所示。车与消息队列服务进行通信,如果攻击者通过逆向工程等方法获取凭证,或者云存在安全缺陷,就可以远程接入消息队列服务,具备了对车发送消息的能力。如果汽车存在消息解析漏洞,攻击者就可以通过云这个“跳板”攻击车载终端,利用漏洞获取车载终端控制权,进而发送 CAN 信号来控制汽车。该攻击范式涉及云侧和车侧的安全问题,对于攻击者而言只是发送一条恶意消息,即可远程控制汽车。该攻击范式按照攻击流程可分为 4 个攻击步骤 : 接入服务(S1)、越权发布消息(S2)、漏洞利用(S3)和 CAN 控制(S4)。

  图 2 新型攻击范式

  S1:接入服务。“空中跳跃”攻击首先需要攻击者接入消息队列服务,让其具备连接云服务的能力。通过研究发现,在 M2M 模型中,由于缺乏用户的介入,云侧对设备侧的认证逻辑在实现过程中易产生安全问题。攻击者可以通过以下方法,获取认证凭证,进而连接到云侧的消息队列服务中。

  匿名访问。一些消息队列服务端软件支持匿名访问,允许用户通过空的用户名和密码接入服务。

  暴力破解。对于消息队列服务而言,认证往往是采用用户名和口令的方式进行,安全意识较弱的管理员可能会使用弱口令,这就给攻击者提供了条件,进行暴力破解来猜解出用户名和口令。

  凭证硬编码。因为车载终端 M2M 模式的原因,开发者为了简化认证的流程,可能采用硬编码的方式,将消息队列服务的认证凭证写入设备和移动应用程序中,并在同类型的产品共享,让攻击者以较低的成本获取接入凭证。

  复现逻辑。对于使用了动态凭证进行认证的目标,一旦攻击者获取了设备固件或 App,就可以通过逆向分析的方法获取认证逻辑,复现认证过程以接入消息队列服务。

  S2:越权发布消息。在通过认证后,消息队列服务可能会对用户的权限进行限制,防止攻击者向非授权的设备发布消息。因此,攻击者需要测试发布权限,若存在缺陷则可以对任意车辆,甚至所有车辆发送恶意消息。

  S3:漏洞利用。上述两个攻击步骤,主要是云侧的安全问题。对于车而言,我们提出了漏洞利用的攻击步骤。攻击者可以通过获取的设备固件进行逆向分析,或者利用模糊测试、静态分析等方法去挖掘设备在消息解析时的漏洞。然后攻击者就可以通过消息队列的跳板作用,将恶意的消息转发给指定的目标设备触发漏洞,达到对智能网联汽车远程攻击的效果。

  S4:CAN 控制。攻击者通过前序攻击步骤获取终端的控制权限,并通过逆向工程获取发送 CAN信号能力,进而控制或攻击汽车。

  三、案例分析

  “空中跳跃”攻击范式主要有 2 种攻击向量:远程漏洞利用和远程操控复现。

  1. 远程漏洞利用

  该攻击向量的前提是与订阅设备通信的消息队列服务可远程访问。由于服务的身份验证和授权薄弱,攻击者可以将恶意消息发布到消息队列服务,以此结合云侧和车侧的漏洞实现完整的攻击链,控制汽车甚至攻击行驶中车辆。

  某品牌汽车通过消息队列协议实现了定位推送功能。通过 App 逆向发现,该品牌汽车云侧存在未认证和未授权安全问题,因此具备 S1+S2 的攻击条件,并且该车终端解析消息逻辑存在漏洞,可以通过远程获取汽车中控主机 Root Shell,进一步发送CAN 信号控制汽车。

  攻击链:S1+S2+S3+S4

  攻击条件:攻击者可以在任意地点接入互联网。

  攻击效果:获取任意激活车辆中控 Root Shell,接入车 CAN 网络进行汽车控制。

  2. 远程操控复现

  在这种类型的攻击向量中,尽管没有发现设备固件中消息解析逻辑漏洞,但攻击者可以利用消息队列服务的认证缺陷,逆向消息格式,通过正常功能消息来操纵汽车。

  某品牌新能源汽车具备 App 远程控制汽车功能。汽车的所有者可以通过手机 App 远程控制汽车打开(关闭)车门,打开(关闭)车窗等操作。该功能是通过消息队列协议实现的。我们通过逆向手机App,发现了硬编码凭证的问题,获取了高权限的认证凭据,并成功连接到消息队列服务。由于该硬编码账号权限较高,这使攻击者可以将操纵消息发布到连接到服务的任何汽车上,控制打开车门进入汽车,并启动汽车开走。

  攻击链:S1+S2

  攻击条件:攻击者可以在任意地点接入互联网。

  攻击效果:操控任意激活车辆车门和车窗等功能,甚至可以直接开走。

  四、缓解措施

  针对消息队列协议在车联网领域应用存在的安全问题,建议有 3 个缓解措施来应对,分别从车侧到云侧层层递进,提高安全能力。

  混合的身份验证。MQTT 协议规范中没有提供可靠的身份验证机制。无论使用哪种身份验证方法,攻击者都可以始终使用自己设备的账户与消息队列服务建立连接。但是仍然有必要根据以下考虑采取复杂的身份验证措施,通过动态申请获取身份验证信息。一方面,它可以阻止攻击者轻松获取凭据,增加攻击成本。另一方面,有助于消息队列服务隔离用户权限。例如在与用户绑定之后,设备可以使用账户的信息作为秘钥来生成证书,因为该信息不会硬编码到固件中,静态的分析方法无法轻松获取敏感信息。

  设备和用户的紧密耦合授权。实际上,我们的攻击范式所涉及的问题主要是由权限隔离不严造成的,这为未经授权的攻击者提供了发起大规模攻击的条件。我们可以采用设备和用户的紧密耦合授权,一旦用户将设备添加到应用程序或云平台上的账户上,服务应将用户身份识别信息与设备端 ClientId 或Username 绑定。这样,由于紧密耦合的授权,使用其他 ClientId 或 Username 的攻击者无法将消息发布到此设备。尽管大多数公共物联网云平台已采用此措施,但许多制造商仍在其私有消息队列服务中忽略此问题。

  空中攻击检测。基于对服务的信任,订阅者很少检查收到的消息。同时,消息队列服务仅按照发布者的主题转发,因此它也不会检查或修改消息。这使得攻击有效载荷可以不受任何限制地传递给订阅者。本文提出一种解决方案是添加如 Web 应用程序防火墙之类的消息数据过滤模块,以检测从攻击者发布的消息中可能携带的攻击载荷。




电子技术图片.png

本站内容除特别声明的原创文章之外,转载内容只为传递更多信息,并不代表本网站赞同其观点。转载的所有的文章、图片、音/视频文件等资料的版权归版权所有权人所有。本站采用的非本站原创文章及图片等内容无法一一联系确认版权者。如涉及作品内容、版权和其它问题,请及时通过电子邮件或电话通知我们,以便迅速采取适当措施,避免给双方造成不必要的经济损失。联系电话:010-82306118;邮箱:aet@chinaaet.com。