| Researchers August 6, 2015


August 6, 2015

The new assembly line: 3 best practices for building (secure) connected cars

By Kevin Mahaffey

IC-MITM
Connected cars are about to change the auto industry’s assembly line.
Vehicles are becoming computers on wheels and now have more in common with your laptop than they do the Model T. Just as smartphones have supplanted non-Internet-connected phones, connected cars will supplant non-Internet-connected cars. Auto manufacturers need to become software companies if they want to survive into the 21st century. To that end, the auto industry must now consider cybersecurity as an integral part to how cars are built, just as physical safety became a critical part of how cars were built in the late 20th century.
When an industry without experience from the front lines of Internet security begins connecting its products, one of two outcomes often occurs. If there are clear security best practices, then most companies will (hopefully) implement those best practices. If there are no clear best practices, companies will likely make a lot of security mistakes, resulting in major cybersecurity problems down the road. My research partner, Marc Rogers of CloudFlare, and I decided to help make sure those clear best practices were in place for the auto industry.
In order to help shape clear best practices, we needed to work find a car that was built with software DNA from the start and was likely making informed security architecture decisions. Our hypothesis was that Tesla was that company and the Model S was that car. We decided to look deeper to find out.
Our research confirmed that Tesla indeed made a number of excellent security decisions in the design of Tesla Model S. It also, however, has a number of areas where we believe Tesla can improve. Overall, I feel more secure driving in a Tesla Model S than any other connected car on the road.
We identified six vulnerabilities in the Model S that ultimately resulted in the ability to, with initial physical access to the car, gain full control over the vehicle’s infotainment system and be able to perform any action accessible to the center touch screen or Tesla’s smartphone app. In one case, we were able to turn off the car while it was driving. At low speeds, the car applies the parking brake and it immediately comes to a stop. At speeds above about 5 miles per hour, the Model S gracefully shuts off its engine—just like shifting a gasoline car into neutral—while still providing the driver full control over steering and brakes so they can safely bring the car to a stop.
In our research we focused on answering the question, “How do we make cars resilient in the face of cyberattacks?” assuming that attackers will compromise the infotainment system. To that end, the exploits that we discovered were conducted with initial physical access to the vehicle. We’ll reveal full details of our research during our talk at DEF CON.
We have found that if the auto industry is to build vehicles that are resistant to cyberattack, they must implement three important measures.
Set up an over-the-air update system
Traditionally when a car has a manufacturing flaw—faulty brakes or unreliable airbags, for example—the manufacturer recalls it. On a large scale, this is typically infrequent and hopefully affects a small number of vehicles. In the software world, however, vulnerabilities that affect millions of devices are discovered frequently. Consider the recent mega-vulnerabilities: heartbleed, shellshock, and the latest Android vulnerability Stagefright affecting nearly 1 billion devices. A bug in a single line of code can affect a very large number of systems.
Connected cars are effectively computers on wheels. PCs, of course, aren’t being recalled for every vulnerability found in them. Nor should cars, though that’s exactly what happened this month after researchers released information about a remote access vulnerability that prompted Chrysler to recall 1.4 million vehicles.
In order to realistically patch vulnerabilities at the frequency they are discovered, manufacturers must implement an over-the-air patching system into every connected car. We are happy to report that Tesla has built such a system. This means, when a manufacturer realizes that a software vulnerability affects their vehicles, they can deploy a patch immediately in a matter of days without the owner having to return to a dealership, receive a USB drive in the mail, or have their car completely recalled.
In order for the majority of users to practically utilize an over-the-air system, updates should be included free-of-charge and not be subject to additional fees for the usable lifetime of the vehicle.
Isolate vehicle systems from infotainment systems
In large corporate breaches, attackers will often gain access to one system—such as an employee’s laptop—in order to attack a secondary, more valuable target such as a database of credit card numbers or an archive of valuable intellectual property. Similarly, in the case of cars, attackers may compromise the browser in a vehicle’s infotainment system in order to get access to the more dangerous vehicle drive systems—brakes, steering, acceleration, etc.
To limit the damage caused by compromise of their infotainment systems, manufacturers should isolate critical vehicle systems onto a separate network, just as in-flight Wi-Fi on commercial airliners is isolated from engine control and avionics networks. As we learned while evaluating the Model S, we were not able to directly control vehicle systems because of Tesla’s implementation of a “gateway” between the vehicle network and the infotainment network. Our research did not extensively look into the security of the gateway system itself, and we welcome further work in this area to ensure that such gateways remain extremely secure.
Secure each component independently
In the past, security teams relied on a “perimeter” security architecture to protect their systems. That is to say, hard on the outside and soft and chewy on the inside. As the story went, if you kept attackers outside the gates, you didn’t have to worry so much about protecting the systems inside the gates. Time has proven, however, that it’s practically impossible to completely prevent attackers from getting inside the perimeter. There are simply too many vectors to defend.
Instead, security teams have found that it is far preferable to secure individual components of your network in order to ensure that if one system is breached, it won’t lead to another’s downfall. While Tesla has done a great job implementing an OTA update mechanism and having strong drive/infotainment isolation, they had improvements to make in their level of individual system hardening. To that end, in order to fully take control over the infotainment system of the Model S, we leveraged the lack of defense-in-depth by getting into one system, using that access to get into another system, and so on, until we had achieved full control. We’re proud to say that Tesla is rolling out an update this week that substantially improves the internal security of the Model S from attackers who might manage to compromise one of the infotainment systems.
Working together
After conducting this research, we had a very positive interaction with the Tesla team. We believe that strong collaboration between security researchers and product development organizations ultimately results in products that are more secure. While companies such as Microsoft, Google, and Facebook, have championed researcher/product developer collaboration in the software industries, we look forward to seeing new entrants, such as Tesla, similarly engaging positively with well-intentioned security researchers.
As devices with critical safety considerations become connected to the internet, we believe that cybersecurity needs to be built in from the beginning, not tacked on at the end. It is our hope that every auto manufacturer in the world implement these baseline best practices to ensure the safety and well-being of people from cyber attacks just as the auto industry has made impressive strides in keeping people safe from physical crashes.

Author

Kevin Mahaffey,
Co Founder & CTO