Your car is a computer on wheels — and its code can be hacked

We aren’t joking when we talk about cars as big fat data generating computer centers on wheels. If you go on Glassdoor, there’s even an interview question, “How many lines of code does a Tesla have?”

I’m not entirely sure, but even a decade ago, premium cars contained 100 microprocessor-based electronic control units (ECUs), which collectively executed over 100 million lines of code. Then there’s telematics, driver-assist software, and infotainment system, to name but a few other components that require code.

What I do know is that as cars’ digital and autonomous capabilities increase, the integrity of that code will matter even more — especially its security. 

Every car comes with many components, and each of these might have a different codebase, which, if poorly tested or secured, is vulnerable to bugs, errors, or malicious code. But what if we could secure cars before they leave the factory floor?

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

I recently spoke to Matt Wyckhouse, founder and CEO of Finite State, to find out how the heck automakers secure all that code.  He also owns a Tesla so he’s personally invested in car security. 

It’s common to build security into the entire development lifecycle. However, Finite State pushes security “as far to the right as possible.” This ensures that the code of the final build is secure, to ensure nothing changes between testing and the car going to its customers.

What are some of the most common security flaws? 

Poorly written code is vulnerable to security risks or malicious activity. Those millions of lines of code within a car’s microprocessors all have their own origin. For example, embedded system firmware, including the firmware used in connected vehicles, is composed of 80-95% third-party and open-source components. 

And, once you start using software from other parties who may not share your security vigilance, the risk increases. Some common examples:

Log4J vulnerability

An example of the recent Log4j vulnerability — a zero-day vulnerability in the Apache Log4j Java-based logging library. 

The main developer might have pulled in the Log4j software as part of their development practice. Or it might be wrapped in a third, fourth, or fifth party component built in Java that lands in the final software. 

This jeopardizes the security of any auto server using the library. The data is collected and stored in different places over time. This increases the risk of impact on the vehicle software. 

In January, cybersecurity researcher David Colombo gained remote entry to over 25 Teslas due to a security flaw discovered in third-party software used by Tesla drivers.

It didn’t enable him to ‘drive’ the cars. But he could lock and unlock windows and doors, disable the cars’ security systems, honk the horns, and turn the cars’ radios on and off.

So, I now have full remote control of over 20 Tesla’s in 10 countries and there seems to be no way to find the owners and report it to them…

— David Colombo (@david_colombo_) January 10, 2022

The security problem of hardcoded credentials

Another example is hardcoded credentials. This is where plain text passwords and secret data are placed in source code. It provides a backdoor for product testing and debugging. 

Left in the final code, an attacker can read and modify configuration files and change user access. If the same password is in use as a default across multiple devices, then you have an even bigger problem. 

In 2019, hardcoded credentials left in the MyCar mobile app made it possible for attackers to access consumer data and gain unauthorized physical access to a target’s vehicle.

So, how do you secure software against vulnerabilities and attacks?

Finite State’s work starts at the testing phase, focusing on the final binary copy and builds. They work backwards, automating the reverse engineering of code, disassembling, decompiling, and testing for weaknesses and vulnerabilities. They then share these with the client’s security team.

Wyckhouse explained that end testing enables them to see how a software artifact has changed over time:

And if there’s an unintended change that’s not traceable back to an action by the dev team, that’s a reason to investigate further.

When we think of cybersecurity and mobility really, we’re only just beginning. But according to Wyckhouse, automakers are continually investing in security, not only to comply with industry standards but also to gain reputational and competitive advantages over rivals who repeatedly suffer from security breaches. 

Still, not a week goes by without yet another report of an attack or a vulnerability found by white-hat researchers. And as car automation increases, the risks only get greater.