Tomorrow a team of researchers will present their paper on Experimental Security Analysis of a Modern Automobile (PDF) at the IEEE Symposium on Security & Privacy. Much like the racing simulators we’ve seen they’re exploiting the ODB-II port to get at the vehicle’s Controller-area network, or CAN-bus. We’re not surprised at all that they can display custom text on the dashboard display or read sensor data from the car. What does surprise us is their exposé on how truly unsecured the system is. It seems that access to any device on the CAN-bus gives them unobstructed control of the car’s systems. Any device can send commands to any other device. They’ve even found a way to write malicious code to the car’s computer which can be programmed to erase itself in the event of a crash.
Much like RFID the security risks here are basically nill for the vast majority of consumers. We just find it a bit surprising that there’s apparently been little thought put into fortifying the communications between the safety systems such as the brakes on the vehicle. For instance, team experimented with sending random packets over the CAN-bus and stumbled across a way to lock the brake on just one wheel. To us it’s conceivable that a malfunctioning device on the network could start sending out damaged packets and cause a dangerous malfunction like this one.
The 14-page PDF linked above is a page-turner, check it out on your hacked ereader during lunch.
Looks like a Chrysler product. They’re really big on networking and computer-based solutions.
Scenario 1: Somebody uses screwdriver to tamper with a car to kill a target.
Scenario 2: Terrorist organisation tampers with 10,000 cars wirelessly (or some vector that doesn’t require physical access) so that one day at the same time they simultaneously malfunction, killing or injuring thousands of people.
Is the second scenario possible? I don’t know, but if it is then it’s a bit of a concern, because some lunatic out there will have sufficient motivation to do it (or pay a black-hat hacker to do it).
Don’t leave your adjustable wrench laying around either.
Someone could gain access and change the parameters on you and then it’d slip right off, or maybe not even fit at all!
Nono, I’m being facetious on purpose.
I think it’s an interesting subject to kick around, but I don’t think I have any real concerns about the issue directly.
SATCOM applies to less than 3% of the active vehicles on the road probably. Let me know when a way becomes public for thieves to defeat transponder keys without $900 field programmers and a spare.
Also most ECMs and BCMs even on a large portion of 2010 models are limited to instrument feedback and brake and engine management. If the code can erase itself it’s a threat though, even though it still reveals the attack vector.
No such problems for my 1995 Proton! Low tech is normally better tech!
They need to see if they can get the throttle to stick on a Toyota (under safe conditions) with code that is hard to find or erases itself after such an instance. Document well and put all info on the web (if you value your continued existence).
To counter the ‘it could never happen’ camp.
Interesting article about Google/OnStar/GM integration in the Volt, they are putting way too much in this car:
http://www.linuxfordevices.com/c/a/News/OnStar-Mobile-for-Android/?kc=rss
I believe the whole point of the paper is ‘shock value’ to try to get some attention on the subject, and get some understanding/limiting of what is ‘acceptable’.
Imagine that GM/Google/et al decide to do something which has a software glitch and results in causing accidents…
would be like penguin controlling the batmobile in batman returns
This can be done with the OBDKey USB, Bluetooth and WiFi units. (http://www.obdkey.com)
* “you can’t just connect to the OBD port and upload code into an ECM”
–> Yes you can. Google “J2534″, its mandated by EPA on all modern cars.
No you can’t, J2534 reflashers are also mandated to be encrypted, it has challenge/response keys too. Different cars have different protocols, and require different options to put them into reprogramming modes.
J2534 is just the method for an interface device to talk to the ECU/PCM ( ps it’s the same thing)
J2534 does not define how to reprogram a car.
It’d be like saying PC’s have TCP/IP so you can reprogram the BIOS with it.
Most cars have seperate a seperate bus for senstive data, they usually also have fault checking to make sure somethings possible, but sure you can screw it up enough to make something go bad, but its down to the individual car.
fluff piece.
Manual brakes (anti-lock disabled), hydraulic steering, manual windows, drive by cable for me thanks. I have been accused in the past of being a control freak. And yes, this article is much ado about nothing….
I think some of you are missing the point.
Yes, the technique illustrated here required physical access to the car. The difference here is that, were you to access someone’s car and cut the brake cables, there would be obvious signs of tampering. However, with modern systems it is fully possible (even plausible) to upload modified code through the CAN, causing the brakes to malfunction at a specified time or speed, then restore to factory code afterwards, thereby eliminating any obvious signs of tampering.
Secondly, all GM cars have come with OnStar for quite a while now. Even if you don’t use it, it’s still there. Car stereos with Heads Up track displays, integrated GPS units and, yes, OnStar all have the POTENTIAL to inject code into the CAN.
I don’t think a virus capable of shutting down even one model of car (Ford Sync, hint hint) is likely, or even plausible. I DO think that a well funded attacker with local access to your vehicle now has another option for sabotage.
In short, drive-by-wire has serious safety concerns that should not be cast aside with a simple “that’s not likely” or “most vehicles” argument. It’s a system that is still evolving, and as more interconnected devices are incorporated into our vehicles, this kind of issue will become more prevalent.
Meanwhile, my 1990 Chevrolet Suburban still has an issue with runaway throttle. 3 GM vehicles from 1984 to 1999 with essentially the same cruise control layout, all 3 display the same tendency. 20+ years on the market and no recall.
“Figure 6. Displaying an arbitrary message and a false speedometer reading on the Driver Information Center. Note that the car is in Park.”
… or is it?
MUHAHAHAHAHAAAAA!!!
i doubt many of us are missing the point, i’d be a lot easier to swap out one of the ecu’s with modified code than to upload a virus via CAN, than cause a physical failure.
Any ‘well funded’ hacker would be a chump to approach it from this direction.
Not only would you need to figure out the reflash code ( and a lot of ecu’s have password protected CPU’s, that you can only erase everything but the bootloader if you don’t have it), you’d need the DBW code, then the support code to bypass the DBW security checks. As well as somehow add code to it that could run, replace the original code , and most ecu’s have block by block erase, so you need to be able to store the original code somewhere that you’re going to erase it. Which is certainly doable, but more suited a for a movie plot.
In most ecu’s if you override the DBW inputs (which there are usually two as a differential of some sort) there are further checks to make sure it makes sense.
Plus you can just switch off the engine.
Talk about going the long way around.