Posted by Robert Vamosi on August 7, 2017
Before the public sessions kick off at Black Hat on Wednesday and Thursday, there are four days of training courses. The course I took part in this year was a two-day, hands-on car hacking course. My instructor, Robert Leale, is the founder and coordinator for the car hacking village at DEF CON. Both the weekend and weekday editions of this course were sold out.
Modern cars are somewhat of a mystery to most of us. Gone are the days when anyone with a wrench could perform repairs in a garage. Since 1968, computers have increasingly become a part of what we drive. Only recently have microprocessors become integral to how we drive. Tesla, for example, has been called a ‘network server on wheels’ with a carefully thought out computer structure that is thoroughly integrated within a custom car. Unlike Tesla, most cars on the road are inherently still mechanical. Most contain a Frankenstein’s Monster of systems within systems without a unifying operating system. So how do these cars work?
Each part of the car has its own set of electronic control units (ECUs) or microprocessors. These are fast-boot devices with no software. The upside of having the fast boot is you can’t wait two seconds for the chip to reboot while driving. The downside is that it’s hard for quality and security systems to inspect what’s being booted. ECUs are manufactured by a handful of Tier 1/Tier 2 vendors. The standard governing their design is ISO 26262.
There are over 70 ECUs in the average car. The engine has its own unique ECUs. As does the anti-lock brake system. And there’s a catch-all set for the car body itself (headlights, door locks, etc.). These ECUs are purposefully grouped into discrete modules following the SAE J1939 standard:
If these systems are segmented by use, then how do different modules talk to each other?
Unifying the car is a controller area network (CAN) bus. Sometimes ECU transmissions (such as “engine on”) are general, intended for all ECUs. Other times they are specific, and directed to a particular module. Communication over the CAN bus is basic. High voltage is a 1, low voltage is a 0.
These broadcasts are sent in frames with set lengths, 11-bit and 29-bit. When a message is broadcast, there’s also a pecking order in which some messages receive priority over others. When there’s a collision, two high priority messages at once, there’s an arbitration procedure. No matter who wins, after a set amount of time, the messages are cleared and the process starts over. That’s a vast oversimplification but it gets to the question:
Can someone on the outside of the car listen in on the network and inject code that silences the ECM?
It just so happens that they can.
For easy access to CAN bus messages, OEMs provide an on-board diagnostic (OBD-II) port located under the steering column. The SAE J1962 16-pin diagnostic port that was first mandated in 1994 by the State of California for use in the state’s auto emissions tests (smog tests). Nine of the sixteen pins are allocated for specific purposes, seven are left for individual OEMs to decide, and its use has expanded beyond just reporting emissions data.
Today, when you take your car in for service, a technician will query the OBD-II port for error messages and other diagnostic information. There’s a new standard, Enhanced, which makes different use of the same 16-pins. But, most the cars on the street today speak OBD-II, and with the right tools you can interact with the CAN bus. Suddenly the diagnostic port on any car becomes a physical attack vector.
Rather than provide 40 cars for his class, Leale had us build our own CAN bus units out of materials he provided. The car was an Arduino-board-like black box loaded with CAN bus firmware. This fed via wire into an OBD-II port which then connected to a diagnostic dongle. That dongle then connected to a USB port on a computer running Windows 10 and a proprietary app.
To interpret and display the CAN bus messages, Leale’s class used Vehicle Spy 3, a commercial Windows app. The app helped identify the individual controller IDs and helped to isolate the more interesting ones, such as the ECM. The app also allowed the class to script and transmit on the ID channel used by the ECM. For example, when a script is set to transmit its message faster than the legitimate ECM, the net effect is a denial of service. In other words, the channel goes silent from all the collisions, and the other controllers might now think the car is off when it is in fact still running.
If the other controllers think the engine is not running, then you can maybe disable the brakes, and so forth. In reality, this scary scenario is much harder to achieve than it sounds. Each manufacturer has its own way of implementing the ISO and SAE standards. So, one would need to gain access to specs specific to the brand and model under attack. And, again, this is a physical attack, so an attacker would have to be sitting in the front seats with a laptop to execute such attacks.
Misuse of the OBD-II port like this has been known for years. The Holy Grail of car hacking was to do these things remotely. In 2015, researchers Charlie Miller and Chris Valesek succeeded in exploiting a software vulnerability in a telematics unit that in turn allowed them to remotely disable the brakes on a speedy Jeep Cherokee in St. Louis, Missouri. That attack has lead the automotive industry to embrace the need for cybersecurity, with more software specific standards coming from ISO and SAE soon.
There are also some legitimate reasons to hack a car. Leale said his company was hired by an auto reclamation company. Before the cars can be crushed, all the flammable liquids must be removed. Leale’s team wrote a CAN bus script that reversed the fuel pump for example.
Similarly, airbags must also be removed prior to crushing a vehicle. Airbag control modules (ACM) are explosive devices. They must be safely detonated in what’s known as “end-of-life-pyrotechnic” event. Otherwise, they’d have an explosive event in the crusher. Leale wrote a script for that as well.
Having taken this course, I have a better understanding of how cars operate. I know how a simple paperclip can prevent most cars from starting. I also know that if you brick a car, in most cases, you can power it off and restart it.
There’s more (both in what was taught and what wasn’t). For example, the course didn’t get into networks or gateways, which are currently under hot discussion within the car security community. These, along with remote hacks, would be the subject of a more advanced course. Perhaps next year?
Get the latest AppSec news and trends sent directly to you.