car theft
Whether or not it is possible to hack a car depends almost entirely on the kind of car you drive. I, for example, drive a 1998 Honda Accord, and I’m almost completely certain compromising its computer systems remotely would be almost impossible. Sure, there are probably plenty of ways to compromise whatever computer lives in Honda Accord One (that’s what I call my car), but an attacker would need direct access to it, which means it’s roughly as vulnerable as a Ford’s early 20th century Model T.
However, a lot of you probably drive a newer car than mine with all sorts of cool built-in features like navigation and collision detection systems. Most –if not all – of these features are controlled by on-board operating systems or industrial control-like machines, and we’re only just breaking the surface on the computerization of automobiles.
A couple years back, a senior security researcher at Kaspersky Lab named Vicente Diaz drafted up a paper on the potential effects of pumping computers and mobile technology into cars. At the time, cars were coming off the line with a whole bunch of electronic control units (ECUs) built into them. For all intents and purposes, an electrical control unit is essentially a computer that controls some part, process, or series of components within your car.
At the time, Diaz expressed concern about a deluge of different, proprietary technologies implemented to meet different needs in different kinds of vehicles with no real standards among the various manufacturers. Each car company prefers its own operating system and each operating system could contain any number of known and unknown vulnerabilities. The question is, if exploited, how would ECU vulnerabilities affect the systems they manage and other computers and censors they interact with.
The other question, of course, is how do you exploit these vulnerabilities? As I said earlier, there was a time when most of these exploits required physical access. Now things are changing. Remote, targeted, and cross-device attacks as well as unintended infections are becoming increasingly possible as the car-makers are trying to find new ways of integrating Internet access and mobile device interaction into their vehicles.
The potential for surveillance and cyber-espionage and location tracking in such connected cars is obviously very high, but not really much higher than the potential for these things on that computer in your pocket. Diaz notes that automobile theft could be an issue on computerized cars where an attacker could possibly compromise a car’s ECU and advise it to unlock the car and start its engine.
The real question you want me to answer though, is can I hack your car and take complete control over every aspect of it? Well, there is some widely cited research from the Universities of Wisconsin and Califorina at San Diego wherein a handful of researchers managed tried to determine just that. Their aim was to see what they could do after compromising an automotive system rather than explain the ways it is possible to compromise such systems. In the end though, they found a rash of car components that they could remotely manipulate. In the event of a caused-crash, the researchers also found they could erase all traces of what they had done. This was nearly three years ago now.
There was no way to manually override many components they found they were able to remotely control though the various ECUs they accessed. First, I’ll focus only on those components that could NOT be manually overridden:
They could continuously turn on the wind-shield wipers, pop the trunk, release the shift lock solenoid (take the car out of park), permanently activate the horn, turn off all auxiliary light, disable window and key locks, spit out a continuous stream of wiper fluid, and control the horn frequency, dome light dimness, instrument brightness, and brake lights. In the engine, researchers could temporarily increase the engine RPM, grind the starter (you know that noise your car makes when you forget it is on and try to start it?), and increase idling RPM as well. Most alarmingly, they could release all the brakes or engage each individual brake. Less alarmingly but no doubt annoyingly, they found ways to increase radio volume, change the radio and driver information center displays, and manipulate the alarm honk. Lastly they were able to falsify speedometer readings, and remotely start and kill the car’s engine. Remember, these are the functions for which there is no manual override available.
Now for the components that could be manually overridden, albeit, I’m not sure how easily: they could continually activate the lock relay (lock and unlock the doors), disable the headlights, turn the wipers off, initiate the crankshaft, and disable power steering, cylinders, and brakes. The reason that there is some overlap between the features that could and couldn’t be manually overridden is that some of these car components are regulated by different computers within the car. In other words (without getting too technical), the locks are controlled by both the driver information center and by the body control module (the computer that regulates that car’s body features like lights and such).
As you can see, there is a bunch of scary stuff an attacker could possibly do to hack your car. However, these researchers bought two brand new cars and performed these experiments in a lab. They had direct access to the vehicles and the aim of their experiment was not to compromise the cars but to see what they could do after compromising the cars.
There isn’t a whole lot you can do to protect yourself other than to stay on top of any updates the car-maker may or may not issue to your car’s on-board computers (ECUs), be aware of any recalls that pertain to these systems, and have your call serviced somewhat regularly. You can rest somewhat assured that the cost of developing exploits for automobiles would probably be quite high. Vulnerabilities and exploits don’t fall from the sky. Attackers aren’t just throwing noodles at the wall and seeing what sticks. Finding vulnerabilities and developing ways to exploit them involve test environments, trials, and extensive experimentation.
