Shortly after obtaining root access on a Tesla Model 3, Tesla released their ‘Safety Score’, which is an assessment of driving behavior based on a variety of metrics. This data is currently being used for calculating drivers’ Tesla Insurance cost premiums and was previously used to gatekeep entry to the FSD Beta program. Our team viewed this new program as an interesting target and ultimately discovered a way to create fake data and submit that data to the Tesla ‘mothership’ server to be incorporated into the Tesla Safety Score system.
In order to reproduce the vulnerability, an individual must obtain root access on a Model 3 car computer running any firmware version which includes Tesla Insurance Telemetry. The feature can be enabled via setting data values; but for this proof of concept, we opted-in to the FSD Beta Request Queue to enable the telemetry data collection.
Next, we generated a valid driving telemetry sample to analyze and modify. To do so, we go on a drive of at least 0.1 miles extremely carefully to get a 100/100 safety score. Upon returning but before placing the car into park, we log into the vehicle as root and run the following script, which we call ‘save-telemetry.sh’:
#!/bin/sh
while true; do
cp /home/tesla/.Tesla/data/drivemetrics/* /home/tesla/
sleep 0.02
done
Once the script is running, we place the car into park, exit the vehicle, and walk away. After waiting about 2 minutes, we check our Tesla App to see if the resulting Safety Score for that drive has been uploaded to the mothership and to make sure we have achieved 100/100 score. Then we copy the telemetry data we saved from the /home/tesla/ directory to our local working computer.
Now that we have a telemetry sample with a perfect safety score, we must modify it to change the sample’s Unique ID (UUID) and inflate the sample’s drive length in miles. First, we print the current state of the sample’s values we care about (odometer readings and UUID). To do so, we use ‘dd’ and the following file titled ‘drivemetrics.proto’ which contains the protobuf definitions for the Tesla telemetry data format. Credit to Tristan Rice for this discovery.
syntax = “proto3”;
message TisDriveRecord {
string metric_uuid = 1;
string firmware_version = 3;
string driver_name = 5;
int64 start_time = 6;
int64 end_time = 7;
string location = 8;
int64 drive_time_ms = 9;
double odometer_begin = 10;
double odometer_end = 11;
}
To use the file, we issue the following command:
dd if=FileNameOfTheTelemetrySampleGoesHere skip=1 bs=7 | protoc –decode TisDriveRecord drivemetrics.proto -I.
The results appear as follows:
metric_uuid : “3908fc3b-6197-49f1-9a29-2370dcd29c35″ firmware_version:”feature-2021.32.22-20-9e064485d2″ driver_name:”Me”
start_time:1633219574754
end_time:1633220552958
location:”America/New_York”
drive_time_ms:900038
odometer_begin:3269.9331217892632 odometerend :3277.1851453183176
Now that we understand our sample and have a baseline for its relevant values, we can move to modifying it.
Modifying the odometer requires using a hex editor and the guess-and-check method. (There is a Protobuf Editor but we could not get this to run promptly). Knowing the order of the sample goes location, drive time, then odometer readings though; we can discern that the odometer ending value cannot be held too far after “America/New_York” shown in the ASCII on the right side of the hex editor.