Car Hacking Attack Vectors and Why They Matter

Hacking a Car: Run Down in Attack Vectors 

PCs didn’t have a security problem until they were connected to the internet. The same can be said for the modern car. Where we could once service our cars in our garages, automakers have added considerable complexity to cars through increased amounts of software. Today there’s more than 150 million lines of code in the typical car. Yet cars lack a unified operating system or platform to tie all the electronic subsystems together; the features have been added to the disparate CANBUS system with little or any rudimentary security. And with increasing connectivity and dependency on the Internet for services and updates, it’s only a matter of time before cars, like PCs, have their fair share of security problems. In this post, we’ll explore the evolution of hacking a car, the avenues of attack and introduce Dellfer’s IoT device integrity monitoring as a new option in this growing challenge.
Physical Access: OBD2 Hacking
One of the easiest, and perhaps best, method of attack on a vehicle remains through direct, physical contact. A typical point of entry is the mandated onboard diagnostic port (OBD-II) located under the steering column. Designed to let non-dealer repair shops have the same level of diagnostic information, this SAE J1962 defined 2×8 pin port provides a window into the internal CANBUS communications. It is the external Ethernet jack for your car. Armed with the right equipment and information, an attacker can both eavesdrop and alter the flow of information. Diagnostic Trouble Codes are 4-digit, preceded by a letter P for powertrain, B for body, C for chassis, and U for network.
Over the years, Dr. Stefan Savage and his team from the University of California, San Diego, have shown various methods of influencing CANBUS communications.  They produced a tool {Car Shark} to generate garbage (fuzzing).  Random code introduced into the CANBUS communication is enough to create a denial of service attack while more nuanced attacks (specific code) can intentionally alter specific instructions so that when a driver accelerates the car actually responds by slowing in proportion.
Hacking Infotainment Systems
In addition to using the OBD-II port, Savage has also demonstrated attacks using the infotainment system. He has shown how malformed music downloaded from the Internet can infect a vehicle. The idea is that MP3 files contain areas not used or used for album art or song text that could instead be used to host malware. This attack has merit since hacking a car with a mobile phone could be accomplished with a compromised MP3 innocently paired with the infotainment system.
In most cars, the infotainment is segmented from the rest of the vehicle; this is a good security practice.  Even so, researchers at Black Hat USA 2015 had a Tesla car hacked and showed they could connect directly from the infotainment system to the CAN bus. They had to bridge a few vulnerabilities together but they were nonetheless able to show how one could leap from a segmented infotainment system of a Tesla to the more critical parts of the vehicle – a Tesla vulnerability that was quickly addressed.
In 2016, researchers at Black Hat from Keen again showed how in-vehicle systems like IC, CID, and Gateway could be compromised, and then used to inject malicious CAN messages into the CAN Bus on a Tesla Model S in both Parking and Driving mode. Tesla responded by using its over the air (OTA) mechanism to rewrite the firmware and introduce code signing protection into its cars.
OTA Hacks (Over the Air)
OTA is an update method used by Tesla, Mercedes, and a few others. Researchers have noted that it shouldn’t be possible to rewrite the firmware on a brake component—that’s clearly a safety issue—yet some have found they could in vehicles without code signing in place. Nor should it be possible to rewrite the firmware while the car is in motion; yet, the researchers found they could do this as well. The point here is that the car must be able to a) authenticate the firmware updates and b) make sure the updates don’t install while the vehicle is driving.
Remote Attack
Until the summer of 2015, the concept of a remote attack on a moving car was limited to attacking the wireless sensors used for the tire pressure safety monitor.  Dr. Savage and his team had been able to exploit the fact that a moving tire sensor needed wireless communications to report its condition. By intercepting that signal, Savage’s team could make the light on the dashboard on a moving car go on and off on command.
It wasn’t until the Jeep Cherokee hack in 2015 that more critical systems such as the brakes were compromised on a moving vehicle. The Jeep hack demonstrated how a flaw in a Tier 1 product used for telematics could alter the vehicle’s performance while driving. The flaw also allowed the researchers to locate vehicles of a certain make and model anywhere in the world. Their controlled experiment took place on a public freeway outside St Louis, MO, and was reported widely in the media.
The subsequent Fiat Chrysler recall cost about $1.3 million — but the event prompted much-needed research and concern from within the automotive industry itself. Today there are working groups, although their guidance may be years in coming let alone being implemented.
Newer cars are using wireless vehicle-to-vehicle communication systems or vehicle ad hoc networks. This will represent yet another entry point for attackers, who could be located along the roadside.
The Dellfer Proposition
The underlying integrity of the software in automotive is critical. Our IoT device integrity monitoring solution offers the maximum protection for a connected vehicle from the inside out, beginning with the embedded systems. It is lightweight and self-contained with its ability to enforce strong security. It’s an effective way of securing portable, mobile connected devices rather than trying to analyze signals of behavior after the fact.