One of the main challenges with securing autonomous vehicles is protecting its linked applications in jailbroken phones or laptops, Laurie says. If an attacker were to jailbreak their own phone, they could see the application code while it was running, which includes how it talks to the backend server. They could then retrieve the application’s hidden data, such as credentials, and take full control of the code, vehicle and connected infrastructure.
The vehicle itself can also be a prime target for attackers. Tools to launch refined attacks against embedded hardware and controller area network (CAN bus) systems are not difficult to find. Attackers could simply purchase or rent a vehicle, find its common flaws such as a backdoor in a module or network, and compromise every other vehicle in the same fleet.
Who is Responsible for Autonomous Vehicle Security?
First-party automakers are not the only ones who should be prioritizing digital safety. Third-party suppliers can also be at risk of a compromise. Attackers could find and exploit a vulnerability in a manufacturer’s network. Even a flaw unrelated to the vehicle operations unit could allow them to pivot onto a supplier’s network, Laurie says.
That is why it is critical that the entire autonomous vehicle infrastructure — every server, network, device, application, vehicle and component — must be protected. Just one poorly configured server on the manufacturer’s or supplier’s end can lead to an attacker breaking into the server, pivoting onto the backend network and gaining control of the connected application and therefore the vehicle.
With connected cars becoming more common, the industry has more standards and options when it comes to autonomous vehicle security. Adam Laurie, known in hacker circles as Major Malfunction, leads X-Force Red's automotive testing practice. He has seen firsthand how easy it can be to compromise an autonomous vehicle if strong security processes and controls are not in place.