Could ISO/SAE 21434 Have Stopped the TeslaLogger Exploit?

Modern vehicles are not just mechanical devices anymore. According to Porsche Engineering Magazine in 2021, “Even today, cars are very much rolling computers. They contain a network of electronic control units (ECUs), with between 70 and 100 being installed in every modern vehicle” and “100 million. This is how many lines of code feature in today’s car.” [1]

To make matters more complex, these ECUs and lines of code are developed by different vendors and are designed to run on different operating systems. These ECUs control various functions in the vehicle, including propulsion, braking, advanced driver assistance, and steering. These devices are often communicating across a CAN bus (Controller Area Network) in which an attacker only needs one vulnerability to gain access into the vehicle CAN.

In May 2024, a security researcher, Harish Santhanalakshmi Ganesan, a Master’s student in cybersecurity at the University of Texas, Dallas, claimed to have exposed a significant vulnerability in TeslaLogger which is an open source third-party data logging software for Tesla vehicles, allows user to monitor, analyze and visualize data including: trips, charge, battery health. By exploiting the security vulnerabilities, Harish was supposedly able to gain unauthorized access to over 30 Tesla cars worldwide, demonstrating the potential risks posed by insecure third-party integrations.[2]

Harish downloaded the open source software from the internet and was able to run a simple nmap vulnerability scan and he was able to discover several open ports including:

Port 3306/ tcp: which is MariaDB
Port 3000/ tcp which is Graphana
Port 8888/tcp which is admin panel

The vulnerabilities he identified included the use of insecure default settings, plain text storage of sensitive API keys, and a lack of proper security authentication mechanisms. These vulnerabilities allowed him to control various functions of the vehicles, such as unlocking doors and manipulating climate settings. Before publishing his findings, Harish contacted the developer and maintainer so that they can apply necessary mitigations. According to him, “Maintainer has enabled encryption to store Tesla API key and refresh token in Database. so even though an attacker compromises the Data Base or graphana he cannot get the API Key in plain text. Also the maintainer has added authentication in the admin panel already.”

Notably, the author did not seem to have reported this particular vulnerability with Tesla’s product security team because of their response to a security issue he had identified with a different third party software (Teslamate) in the past.

This incident highlights the importance of implementation of cybersecurity measures in automotive software development. ISO/SAE 21434:2021 Road vehicles – Cybersecurity engineering, is an automotive standard focusing on the cybersecurity risk management in the automotive industry [3]. The standard emphasizes the importance of cybersecurity implementation throughout the lifecycle of the vehicle.

A proactive implementation of a Threat Analysis and Risk Assessment (TARA) based on ISO/SAE 21434 Clause 15 could have addressed the vulnerabilities in TeslaLogger. RQ-15-03 under sub-clause “15.4. Threat Scenarios and Identification” specifically requires the inclusion of malicious use cases resulting from reasonably foreseeable misuse and/or abuse.

We want to show you a high-level example of how a TARA could have captured the admin panel vulnerability. While the TARA is still based on a threat “model” and could suffer from unknowns, a systematic approach highlighted in a standard like ISO/SAE 21434, along with the right combination of experts with diverse experience, will greatly reduce the likelihood of vulnerabilities in released products.

The TeslaLogger exploit demonstrates a critical need for comprehensive implementation of cybersecurity measures by OEMs, suppliers and third-party software vendors operating in the automotive industry. More importantly, it drives the question “What is the scope of responsibility an OEM development team shoulder for their customer’s use of third-party software and the related vulnerabilities they may pose?”.

In the automotive functional safety standard, ISO 26262: 2018 [4], and the Safety of the Intended Functionality (SOTIF) standard, ISO 21448:2022 [5], ‘reasonably foreseeable misuses’ of the safety-critical product are systematically analyzed during development and counter-measures subsequently developed. Even in these standards, what is “reasonable” is not clearly defined. Therefore, we clearly need industry alignment on “what is good enough” when it comes to foreseeable misuses and/or abuses over time. At the same time, it is also equally important for security researchers to remain optimistic and continue reporting the vulnerabilities to all stakeholders regardless of past reactions from automakers and suppliers.

Currently vehicles are as vulnerable as computers were in the early 2000s making it necessary to stay ahead of hackers and learn from each other. We have a joint responsibility to apply state-of-the-art standards and methods to keep ourselves and our loved ones secure and safe. The worst thing we can do is do nothing.