CVE-2020-10558 | Tesla Model 3 Hack – Disable Autopilot Notifications, Speedometer, Web Browser, Climate Controls, Turn Signals, Nav, etc.

Safekeep Cybersecurity

CVE-2020-10558 | Tesla Model 3 Hack – Disable Autopilot Notifications, Speedometer, Web Browser, Climate Controls, Turn Signals, Nav, etc.

CVE-2020-10558 | Tesla Model 3 Hack by Jacob Archuleta


Featured On:

 Safekeep Cybersecurity - The Daily Swig

Safekeep Cybersecurity

Safekeep Cybersecurity - Hot Hardware

Tesla Model 3 HackSafekeep Cybersecurity NIST


Investigation:

I was able to find this Tesla Model 3 Hack / Denial of Service Attack (DoS) after investigating the Tesla Model 3’s web interface. This was after being inspired from the amazing team, Fluoroacetate after they discovered a JIT bug in the browser.

The investigation started with a dive into the potential threat vectors that the Tesla Model 3 vehicle may have:Tesla Model 3 Hack

  • 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.
  • 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.
  • 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.
  • 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.
  • Tesla Key Card
    • After testing with some RFID cloning devices, I was pleased to see that the key cards were not easily cloned.
  • Charging Port
    • I was not able to even figure out how to start with the charging port. No progress. I will definitely need some more time for this avenue.
  • Controller Area Network
    • I did not have the hardware needed to investigate the CAN bus, but hopefully it arrives soon!
  • TPMS
    • After investigation with the TPMS system using a HackRF, I was not able to find anything of value.
  • GPS
    • I was not able to test the GPS of the vehicle. No progress.
  • 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.

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.

 


 



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 Tesla Model 3 Hack, a user has to go to a special web page with the DoS code embedded. 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.

Nullze Script Tesla Crash

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 Tesla Model 3 Hack through Bug Crowd, I had the incredible pleasure of working with the Tesla team to get this issue resolved. Tesla was able to resolve this issue in a timely manner, and push an update to it’s fleet of affected vehicles in order to keep their drivers safe.

This bug was also issued a CVE number from the National Vulnerability Database due to its severity. You can find a link to the vulnerability below!

https://nvd.nist.gov/vuln/detail/CVE-2020-10558