AVGuardian Attack Demos

Threat Model

We assume that a ROS node/module for implementing the driver functionality for peripheral devices (e.g., GNSS, Lidar, etc.) in autonomous driving systems such as Apollo can be compromised by an attacker to perform malicious code execution. This threat model is based on existing well-known ROS and automotive security work:

1) Assuming a compromised ROS node is a typical threat model in previous ROS security work, e.g., SROS.

2) The assumption of device drive being compromised is based on a series of demonstrated real-world security vulnerabilities discovered by previous automotive attacks (TPMS, Bluetooth, FM Radio, cellular exploits), TCU vulnerability (CVE-2017-9633 and CVE-2017-9647), GPS software attacks, Jeep Cherokee hack, remote Tesla attack, remote BMW hack, Infotainment malware infection, Tesla's Autopilot hack.

Thus, we believe that this is a realistic threat model with direct practical implications for autonomous vehicle systems.

Attack Summary

  • Exploits on publisher-side overprivilege: obstacle relocation (TF attack) & obstacle removal (PCL attack) to cause an AV crashing into on-road obstacles

  • Exploit on subscriber-side overprivilege: VIN stealing attack to uncover personal information of an AV owner and conduct fraud incidents using stolen vehicle identification numbers (VINs) of AVs

Demo Setup:

We demonstrated attacks exploiting TF and PCL vulernerability in a docker container (officially released by Baidu Apollo) and used demo-sensor-demo-apollo-1.5.bag collected from Apollo's real-world test driving at Sunnyvale CA (download link) as our input sensor and traffic trace.

For the untampered perception obstacles in normal situation (i.e., without attacks), we directly used the PerceptionObstacles messages included in the original data bag.

To generate PerceptionObstacles under TF/PCL attack, we first generated fake tf or PointCloud message as input to the perception module to generate corresponding PerceptionObstacles message output and replayed them in Apollo's built-in simulator (a.k.a., SimControl) to perform differential testing.

0. Control Group (no attack)

In order to provide a baseline without attacks for comparison, we ran the SimControl simulation platform with the untampered perception obstacles to see how it behaved in the normal circumstances.

In this video, the AV had a tendency to change the lane and then started braking when it was far enough away from the obstacles. As a result, the AV successfully avoided the obstacles and safely pulled up before them.

1. TF Vulnerability

Threat Model: Compromise of TFBroadcaster node in GNSS driver module

Attack process: An attacker compromises TFBroadcaster node and injects fake tf.transform.translation in /tf message. TFBroadcaster is a ROS nodelet in the GNSS driver module that publishes /tf message.

Attack consequence: Vehicle running Apollo crashes into an obstacle.

The threat model of the attack exploiting TF vulnerability (a.k.a., TF attack) is compromise of the GNSS_Driver module such that an attacker can inject fake tf message (topic: /tf ) to relocate the obstacles.

Detailed message modification: transform.translation.x += 15; transform.translation.y -= 2;

To illustrate the exploitation of TF vulnerability, as shown in the video below, we sent fake tf message continuously for 5 seconds [1504653404s, 1504653409s) to trick the AV to misjudge that the obstacles were in the other lane (but actually in same lane in reality, according to the Control Group Demo shown above). We started sending the fake tf message right before the AV observed the obstacles for the first time, and stopped sending the fake ones when it was too close to the obstacles to safely make an emergency stop. As a result, since the AV initially thought there was no obstacle before it, then it did not change the lane and also did not slow down, which caused crash into an obstacle.

The reason why we choose 5-second as the duration of the attack is that the Apollo AV system has a prediction module, which can keep tracking and publishing the observed perception obstacles for 5 seconds, and thus we need to send fake /tf messages continuously for 5 seconds to bypass this protecting mechanism.

2. PCL Vulnerability

Threat model: Compromise of compensator node in Velodyne's LiDAR driver module

Attack process: An attacker compromises Velodyne compensator and injects fake /apollo/sensor/velodyne64/compensator/PointCloud2 message. Velodyne compensator is a ROS nodelet in Velodyne's LiDAR driver module that performs motion compensation for LiDAR point cloud and publishes /apollo/sensor/velodyne64/compensator/PointCloud2.

Attack consequence: Vehicle running Apollo crashes into an obstacle.

Detailed message modification: msg.height = 0;

To craft the attack exploiting PCL vulnerability (a.k.a., PCL attack), under the threat model that an attacker controls the Velodyne Driver module and can inject fake compensated PointCloud message (topic: /apollo/sensor/velodyne64/compensator/PointCloud2), which is subscribed by the perception module, to disrupt an AV's real-time perception of nearby obstacles or even remove obstacles from AV's perception field (i.e., obstacle remove).

To illustrate the exploitation of PCL vulnerability, in this video, we sent fake fake compensated PointCloud messages continuously for 5 seconds [1504653404s, 1504653409s) to trick the AV to misjudge that there was no obstacle in front of it. We started sending the fake messages right before the AV observed the obstacles for the first time, and stopped sending the fake ones when it was too close to the obstacles to safely make an emergency stop (same as TF attack). As a result, the AV neither changed the lane nor slowed down, which led to crash into an obstacle.

The reason why we choose 5-second as the duration of the attack is same as the one stated previously for the attack exploiting TF vulnerability.

3. VIN Stealing Vulnerability

Threat Model: Compromise of parser node in GNSS driver module

Attack process: An attacker compromises data parser node in GNSS driver module (subscriber of Chassis message, namely /apollo/canbus/chassis) and passively sniffs license.vin (v3.0/v3.5) or vehicle_id.vin (v5.0) field in its subscribed Chassis message.

Attack consequence: Attacker steals the Vehicle Identification Number (VIN) of an AV to uncover personal information of the AV owner and uses the stolen VIN for further fraud incidents.

Canbus module publishes /apollo/canbus/chassis message, whose license.vin field contains the Vehicle Identification Number (VIN) of an AV. If compromising the GNSS driver module (subscriber of /apollo/canbus/chassis message), an attacker can sniff the VIN field of an attacked AV and further uncover personal information of the AV owner, including name, address, and in some cases phone number and email address, for example, through a website called “That’sThem” with a VIN search service that would bring up personal information of the vehicle owners when the VIN number is entered into the website. And the website claimed that “the data is sourced from both public and commercially available sources” [1].

Furthermore, the VIN can be used to register dozens of stolen vehicles for masking vehicle theft (through VIN cloning [3]) or filing insurance claims on totaled vehicles, and even to make duplicate keys for an attacked AV. The stolen VIN can be also used by thieves to get car loans. And the actual VIN owner will be associated with the debt [2].

Research paper

[EuroS&P '20] AVGuardian: Detecting and Mitigating Publish-Subscribe Overprivilege for Autonomous Vehicle Systems. [PDF]

David Ke Hong, John Kloosterman, Yuqi Jin, Yulong Cao, Qi Alfred Chen, Scott Mahlke, Z. Morley Mao.

To appear in the 5th IEEE European Symposium on Security and Privacy (EuroS&P'20), Genova, Italy, Sep. 2020.