Objective: Find a vulnerability in the Tesla Model 3 Vehicle. But how?
The first start to any type of research project is to first do the research (do your homework). I started looking at all of the successful Tesla hackers in the past and see if there is a way to emulate their methodology, and their successes.
As some previous researchers have described, this is really the Hacker Olympics.
Some resources that I had found useful were:
Hacking the Tesla Model S - Marc Rogers and Kevin Mahaffey
And then there is the typical OSINT that can be done on several different types of search engines.
Investigation
After doing my initial research, I decided that it was time to just do it! Since I am no Vehicle Security expert at the start of this journey, there were a lot of trials and tribulations along the way. The first steps would then be to identify all the different types of subsystems to the car and determine if there is a way to exploit one of them.
Proper threat modeling of a Tesla Model 3:
USB
After doing some investigation with the USB ports, it appears that the front two USB ports in the Tesla Model 3 have the potential for data connectivity back to the Infotainment System, or MCU. The two vectors I tested were for the “Sentry Mode” folder format and the “USB Music” functionality. A lot of trial and error occurred from using an embedded linux system that can emulate as a keyboard, ethernet card, USB storage, and capture data back to the linux system. No progress was made yet in that area of testing.
Tools Used:
Exploits Attempted:
- Lame Heap Overflow \Music folder
Wifi Connectivity
Connecting the vehicle to my internal WiFi network yielded no results. After being able to see DNS requests made from the vehicle after connecting to Tesla’s API, I was not able to locate any vulnerabilities from that avenue. I was pleased to see the full extent of Tesla’s API, as it can be pretty useful, and decided to use some in a program on my linux machine in python for fun. The project can be found on my Github under "Tesla Tester."
Tools Used:
- Tesla Tester
LTE Connectivity
I was not able to see anything significant from the LTE connectivity of the car. I will see if I can acquire some equipment to start testing LTE connectivity.
Wish List:
- LimeSDR Mini 2.0
Android App / Iphone App
I was not able to see any issues with the android or iphone applications. Hopefully I can get some more time in the future to investigate this avenue of the vehicle. To be continued…
Tools Used:
- Android APK Decompiler
Tesla Key Card
After testing with some RFID cloning devices, I was pleased to see that the key cards were not easily cloned.
Tools Used:
- ProxMark 3
Charging Port
Update: Recently someone had found a vulnerability for ALL of the Tesla charge ports.
Tesla stated that from their perspective this is intended behaviour.
Tools Used:
Resources:
Cylect.io was able to verify that the hack still does indeed work.
Controller Area Network
I did not have the hardware needed to investigate the CAN bus, but hopefully it arrives soon! To be continued…
TPMS
After investigation with the TPMS system using a HackRF, I was not able to find anything of value.
GPS
Reported a vulnerability in the internal networks of the system, where I mistakenly thought that a configuration command was a password.
I was also able to listen to the internal network by following a series of steps I found while messing with the car:
- Hard Shut Down Car
- Connect your ETH cable to the ICE
- Spoof the MAC Address of the DAS ECU and the ICE.
- Start sniffing traffic.
- Start the car.
During this boot-up process, I was able to see the genealogy 3 command being sent to some type of live build system.
Unfortunately, this was not a vulnerability, I was awarded no points, and may God have mercy on my soul.
My next GPS hack was being able to spoof the car's GPS location using a rooted Android device, a GPS apk (I was messing around with Pokemon GO and ended up finding this), and found that you can summon your Tesla Model 3 from way farther than it's intended range.
The API connection from "https://owner-api.teslamotors.com/" allows for re-use of the exact vehicles GPS location to be then sent out as location of the owner, even when they are not at that current location. This allows an attacker to open the garage door from anywhere in the world (as they are allowed to spoof the co-ordinates of the vehicles).
PoC Code at: https://github.com/nullze/Tesla-Tester/blob/master/tesla-tester.py
Option: 13: Trigger Homelink
Vulnerability Summary for GPS Spoofing via Rooted Android Phone:
The Tesla Mobile Android Application can be ran from a rooted android device to then spoof the GPS co-ordinates of the owner. This allows remote access for an attacker anywhere in the world to summon the vehicle and slowly drive it anywhere, and to also open the garage door of the owner if the vehicle is parked at home.
So they do have a point where if someone is able to spoof the GPS coordinates, it is outside of their control.
Have fun with this one!
MCU Ethernet Port
After doing some physical investigation of the car, I was able to tap into an exposed ethernet connection with the vehicle and found some pretty interesting ARP requests internally from the network, and was able to find an internal page hosted on the MCU on port 8080, but that was a dead end. If there is someone who can look at fuzzing the internal applications underlying software, maybe in the future that would be an avenue of attack to the Tesla Model 3. Who knows.
Web Browser
After attempting to follow in the footsteps of the Pwn2Own team, I was not able to find any remote-code execution vulnerabilities from the browser perspective at the time. I was only able to find the Denial of Service vulnerability.
Previous Bug:
This code was reported back in 2016 as a problem with Chromium, as this abuses the pushState() function inside the browser.
From “[email protected]”, he states the following:
“Summary: Browser crashes when window.history is spammed by bunch of pushState() calls (was: Browser crashes when window.history is spammed by bunch of pushState() calls with a big string as the url argument) A single pushState() call with a big string is fine (moved pushState() call out of the for-loop). 100000 pushState() calls with url=”” –> CPU busy. unresponsive”
In the example with the Tesla Model 3, this abuse of the function utilizes too much CPU processing power which in turn causes the whole interface to freeze. This means that the browser process is sharing some essential background services to the whole interface of the screen, which will cause the entire screen to crash.
Important Note: I stated in the video that this disables the autopilot functionality, but that is incorrect. This will only disable the notification to place pressure on the wheel. If you keep pressure on the wheel, AP will continue to function.
Summary
The driving interface of Tesla Model 3 vehicles in any release before 2020.4.10 allows Denial of Service to occur due to improper process separation, which allows attackers to disable the speedometer, web browser, climate controls, turn signals, navigation, autopilot notifications, and blinker notifications along with other miscellaneous functions from the main screen.
Attack Vector
To exploit the vulnerability, a user has to go to a specially crafted web page. This web page will crash the chromium-based browser interface and inherently crash the entire Tesla Model 3 interface.
If you want to test it out on your tesla before you update, feel free to go here. Please drive responsibly as this does not inhibit your ability to manually take over. You can still drive.
Script
Warning: This script above will still crash your browser on the system you are currently using, so be sure to save your place or use a scrap web browser for this page.
Resolution
After reporting this vulnerability through Bug Crowd, I had the incredible pleasure of working with the Tesla team to get this issue resolved.
This issue is fixed in any release >= 2020.4.10.
The US Government issued out CVE-2020-10558 in response to this finding.
This vulnerability was ranked as "7.1 High".
"The driving interface of Tesla Model 3 vehicles in any release before 2020.4.10 allows Denial of Service to occur due to improper process separation, which allows attackers to disable the speedometer, web browser, climate controls, turn signal visual and sounds, navigation, autopilot notifications, along with other miscellaneous functions from the main screen."
Press: