Modern Car Data Systems Lack Security

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.

65 thoughts on “Modern Car Data Systems Lack Security

  1. That is bull. You can do anything if you have physical access to the system. The same way you can cut the brakelines from under the car.

    Modern car systems are not unsecured. They’re not connected to a network.

  2. I’ve read their article a few times and it’s really quite scary. I hope the good guys do something before the bad guys.

    @jonah yes that’s precisely what it means. Perhaps not necessarily even talented, just motivated.

    What struck me was the ability to lock a certain wheel brake while driving, and also the ability to disable the break pedal. Very scary to say the least. I hope the manufacturers are able to adsress this quickly!

  3. @hackius you’re dead wrong.

    It is common knowledge that modern vehicles come with navigation packages which connect your vehicle’s on-board CAN network to the cellular network.

    I.E. Your car has an IP address fool!

  4. Interesting read, but since when was a car ever safe from a physical attack? If someone wanted to maliciously disable the brakes, puncturing a line will always work, CAN bus or no.

    The CAN bus found in some OBD ports is normally kept separate from the safety-critical systems (as in separate ports on the ECU) to mitigate this sort of problem. Maybe this car has a particularly cheap ECU. Unless they’re very recent, non badge-engineered Fords, GMs and some VWs don’t have CAN in the OBD port at all.

  5. @nes the article addressed the bridging the secure and insecure networks. They wrote a tiny piece of code that runs on their car’s Unix based nav system. That piece of code bridged packets, like a router, from the low-speed (trusted) network, to the high-speed. They used this bridge to launch some of their attacks.

  6. @Brad Hein umm, no. They did all this through physical access to the CAN bus or getting individual modules onto the bench. They don’t claim anywhere to have gained access through some existing wireless link.

  7. Scary Scenario #1: You leave your door unlocked, black hat hacker sneaks in, connects to OBD, uploads 25 lines of code in less than 10 seconds, your car connects to botnet, he goes home, logs into IRC, commands his botnet.

  8. @nes

    The fact remains that there exists a subsystem on several of these vehicles that is both connected to a cellular network and the vehicles can system, presumably on the trusted side.

    All it would take is one buffer overflow triggered by incoming data and a malicious payload for that particular component to be compromised. From there the other components fully trust whatever the now zombified Onstar/similar brain wants to tell them.

    On vehicles with GPS there are TWO systems that accept input from outside source. One could presumably do the same thing by broadcasting a payload at a vulnerable gps receiver.

    The saving grace appears to be that we haven’t yet found an exploitable vulnerability in any such subsystem. If the car manufacturers did a good job, there are no such points of entry. We don’t know.

    What we do know now however is that it only takes one such point of entry, and then everything else on the CAN bus is trivial to compromise.

  9. I wonder if CAN is accessible through the system that allows you to sync a car’s mp3 collection with a home collection through wifi. I’m sure it isn’t directly accessible, but it possibly could be through an exploit. If that were the case, I’d think you could crack someone’s WEP key, ‘sploit the sync system, and use that as a vector to upload the malicious code to the on-board computer. I’m sure there are people out there who could do it. I wonder if we’d see a recall, or would Ford just tell us to secure our wi-lans.

  10. Addendum: Now that I think of it, modern car audio systems have multiple points where they access external data sources. Bluetooth for both handsfree and streaming audio comes to mind. Data driven (usb style, rather than analog audio + serial control) iPod connectors, and cd players that can read mp3s burned to a data cd or stereos with usb ports for mass storage devices could each provide the only vector it takes to compromise a Canbus vehicle, given an exploitable vulnerability in the radio.

    Imagine being able to root an entire car just by sticking a cd in the radio for a minute or two.

  11. I think it’s good that cars have bad security. The only things that need security are: locks, brakes, and steering. All of which should also have a manual override. Everything else should be easy to modify.

    Also, I want a copy of CarShark! It looks way better than the commercial crap that I bought.

  12. this is entirely a non-issue. Anyone who thinks this is a legitimate security issue has no understanding of automobile communications. The very NATURE of the physical layer in CAN means that anyone who can get on the wire can change commands. As long as you know the message, you can change it. ECMS are completely incapable of adding an encrypt/decrypt step to their communications not only that, the increased latency that those extra steps would entail would almost certainly lead to reduced performance and thus your brakes not responding as quickly as they could otherwise. The only risk lies in the bridge, and that is generally uncommon. How many of YOU have OnStar. Likewise, @brad, you can’t just connect to the OBD port and upload code into an ECM, not how it works. The security risk is not on the local communications, it’s purely in OnStar and related systems. Even then, it STILL requires physical access. Instead of bothering to hack onstar they’d be better off just installing their own CAN->Cellular link.

  13. Yea i read this on slashdot a few days ago, and really honestly if someone wants to get you they are not going to hook up a small EE lab to your obd port

    yes in the future this might be a problem, but the entire presentation of this information today is just scaremongering, and that is where it looses credit

  14. @DanS – right on. The shortest path to securing this right-away is to allow the user to override any of the control surfaces, independent of any computer connection. (get rid of fly-by-wire systems)

    @Omar – where do I start?

    * “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.

    * “The very NATURE of the physical layer in CAN means that anyone who can get on the wire can change commands”
    –> That is true, but your argument is like saying we should encrypt the cat-5 cable. That’s not how it works, encryption is implemented at higher layers, such as the transport or session layer.

    * “The security risk is not on the local communications, it’s purely in OnStar and related systems”
    –> What about car stereos that connect to the network? They run operating systems, connect to the network, and play media from CD/USB

  15. *sigh* alright brad, where do *I* start

    -j2534 != injecting code, and will not get the kind of results I think you’re expecting. I work in the industry, our ECMs are not so easily changed. There’s changing settings, and then there’s changing the underlying code. These are wholly separate operations.

    -Ethernet != CAN. They were designed for different purposes, CAN is actually serial, simply changing the priority on a message will allow you to overwrite the original sender, I do it every day for testing, pick up a CANCase with a CANylizer license and you’re good to do whatever you want.

    Stereos: I don’t know of any that actually hook up to the local network, if it doesn’t display vehicle information (diagnostics etc.) it’s not on the link. Even if it was, what you’re suggesting is that the car stereo is poorly designed and allows code to be injected from playing back a media file of some sort. And then… what?

    This whole thing is the weirdest proof of concept I could imagine. It’s like saying you’re thermostat doesn’t have a password, a burglar could set your heat really high!

  16. This makes a lot of assumptions about the underlying OS and how secure it is.

    Certainly not enough information here to link 3G or LTE connected cars directly to the CAN bus.

    It’s also important to know that every OEM does things differently when it comes to integration. There is definitely no single approach that would work for every vehicle.

  17. This is laughable… OBDII is great, I think I enjoy working on cars so much because it’s simple and straight forward and not needlessly and overly complicated or obscured with layer upon layer of ridiculous security.

    Yes what the article described is a problem however the SOLUTION shouldn’t be a knee jerk “OMG MOAR SECUR NAOW!!!”

    Problem #1: Brakes and steering are electronically controlled
    -Ask anyone who who has had an alternator die on them how they’d feel if they were unable to properly control the brakes or steering when it happened. I’m a huge advocate for electronic throttle control, both before and after the Toyota fiasco, I will never buy a car with non-manual brakes and steering.

    Problem #2: The Engine Control system isn’t segregated from the rest of the car’s system, particularly. There’s no good reason for Onstar needing to control your engine, brakes, steering, etc. or “update” it’s mapping. Honestly aside from plugging directly into the OBD port, or an emergency cut-off signal (like those used in anti-theft systems) there should be no way any external system should have any control what-so-ever of the self-contained engine control system

    Sabotaging via OBD port based reprogramming is much much much more difficult than any of you think it is, yes the protocol is simple, but in order to do anything worth while would require extremely intimate knowledge of the specific model of computer and engine that the vehicle uses.

    In general we shouldn’t really fear these kinds of attacks anymore than fearing someone cutting our brake lines, or sabotaging our cars in any other non-computer related way…. if you’re really worried about it, then install a hidden switch on the OBD serial wire to leave it turned off when you don’t want people plugging in… most WELL DESIGNED cars I’ve re-programmed actually required several jumpers to un-write-protect the computer module anyway.

  18. I think all this stuff is just striking a nerve after the toyota bs fiasco. Obviously I’m reacting more strongly than others because I work with this sorta stuff every day.

    @twistedsymphony for uhh, #1. I feel you, I understand entirely, I’ve lost electrical power on the highway before. But uhh, how do you think airplanes work? End of the day, the only way we’ll be able to continue advancing automotive capability and safety is with electronics. What’s important is that there are sufficient fail safes and backups.

    We as humans will never be able to match the response times of computers, at some point we will have no choice but to trust them. Take for instance radar based automatic braking systems. I don’t trust them now, but at some we’ll all have to trust that our car is capable of braking for us if it detects that we’re going to hit something.

  19. I don’t see any lack of security. To the guys responsible for this bullshit: just finish your thesis, publish your shitty papers and stop spamming the world. We don’t give a fuck that someone can sabotage our cars by breaking into it and plugging a goddamn laptop when there are much easier ways not involving grand theft auto..

  20. from my view, the import of this article isn’t “someone with physical access can fuck with your car,” though that is certainly what the paper is literally about, it’s “you car is a networked device with safety-critical devices that can be controlled externally.”

    the intent is to bring the idea of security up at all in designing the internal networks of cars.

  21. “the intent is to bring the idea of security up at all in designing the internal networks of cars.” — That’s as pointless as trying to bring up the security of my CPU address bus…

  22. There are OBD-II bluetooth dongles on Dealextreme. How long it takes to put a small dongle to its place and connect it via GSM phone also left in the car?

    Or how long we have to wait Chinese manufactures create a OBD-II GSM module :)

    Scary, but not news to me.

  23. I’m amazed at how much hate is being posted in these comments. This is great information. I imagine most people aren’t going to see this and want to maliciously control your car, but someone may want to use this information to design something useful for their car.

  24. @vmspionage I wish to subscribe to your newsletter.

    @sevendeuce OBD-II projects that snoop on the ECU are nothing new to HAD. All these doofuses are doing are stirring up panic for advanced media whoring.

    Next week I’m going to release my epic paper on how hackers can disable your brakes with nothing but a pocket knife.

  25. A few misunderstood items here.

    1.) GM ships almost all their cars with OnStar now. It has access to both GMLAN’s, the low speed (body) and high speed (engine, transmission, etc).

    2.) The head units in GM cars are on the low speed network. They don’t bridge.

    3.) The OBD2 port on GM cars exposes both high and low speed CAN (GMLAN)

    4.) The OBD2 port is the easiest access point to the bus. It is NOT the only. There are plenty of connectors that are accessible from the outside (under) the car.

    5.) Cutting a brake line is fine and dandy, but I bet 99.9% of people will notice before they get up to speed. Being able to kill the brakes remotely, while at speed, is dangerous. Or locking just ONE of the tires (prob more dangerous).

    6.) GM uses the SAME PCM (they’re not called ECUs) in every single one of their vehicles now. Literally, the same part number, just different firmware.

    The point is, the bus is easily accessible, easy to muck with, and with a few hundred dollars, a visit to Dealextreme and sparkfun, you can have a GSM connected canbus controller that’s capable of doing some severe damage.

    Or, you can do cool stuff, which many people are right now.

    To add to that, OnStar is making it’s way into other brands other than GM. GSM cracking isn’t rocket science anymore (a few grand in hardware does it), so it can start to get pretty scary if someone “evil” got any ideas.

    **I own a GM vehicle with everything on the bus and have played with it. I will be making a few modifications to my car that sit on that bus. I’ll also be changing the factory PCM code (HPTuners) for better performance.

  26. Yeah, you can get stupid results by doing stupid things.

    Better read the CAN specification about the ‘malfunctioning controllers may send malicious frames to the bus’ issue. A CAN controller is required to go error passive (i.e. not transmit anything) once there are to many error-frames, which would involve having two controllers send the same message id at the same time. And the kind of software bug you need to get ‘valid’ frames (accepted by receiver) to be sent by a defective controller instead of the original controller is intentional wrongdoing.

    I like the explanation that having access to the car makes no difference for the malicous effect it may bring. One could also e.g. sensors, brake pads, tires or the engine to do something in the wrong situation or by an RF signal. Or disable the airbag by modification (without the driver noticing it). In any case there would be an extra device or detectable modification involved to achieve this.

    I can imagine that these systems are set up to work as good as possible. But only in an unmodified environment and still possible to detect errors of the usual kind, which can include other controllers sending invalid data.

    There is probably no difference to other hacks and security issues like in a plane, a train, the traffic lights or a lift? Did you guys think that all these systems are strongly secured in their functionality against intentional wrongdoing on hardware level? No one will pay for this kind of development unless it is an everyday problem. If it can be shielded or firewalled then this is the solution of choice.

    It is like the lift stalls and someone modified the brakes intentionally once he had access to it. So what do you do? Developing brakes that can not be set out of order is impossible. You can only install a lock in the door and make changes detectable.

    Doing something useful with the self-owned car may be a good thing, but you still need to pass the technical check and the show stops when people get injured or killed. Sending ‘random frames’ via ‘extra’ equipment on the CAN-Bus while driving is intentional wrongdoing and people could go to jail for it. This is not case-modding of the home pc.

    The problem is, that these modifications are too complex to be identified by just a look at the ‘new part’ or reading a sheet of paper. So what are technical check organizations supposed to do? Forbid them all? Probably.

    wbr

  27. Although GSM/3G may provide the ‘normal’ attack vector, there are also others such as TMC messages with buffer overflows. The research already speaks of hacking GPS units to bridge high and low speed can buses to inject malicious packets.

    One would think that with enough will, it would be possible to ‘terminate’ a particular car by transmitting data over a FM link. Scary!

    The worse thing about any of these attacks is that the insurance companies/investigation agencies will simply blame the driver.

  28. What a complete load of sensationalist bs! Anyone with at least a basic knowledge of the CAN bus within cars could tell you this. Can’t belive they wote a whole damn paper on it and got it plastered all over the global news!

  29. @CD0 – you presumably posted this out of jest, however it has been recognised that external connectors (FireWire) can be used to compromise computer security…

  30. “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.”

    I wonder if any car crashes were actually murders that were completely overlooked? Have a code lock up one wheel when the driver hits highway speed and erase itself after the crash. Just one of the reasons this is unacceptable.

  31. What bothers me the most is that in the not too distant future we might have government mandated “automation” in our cars. I believe their goal (and the insurer’s) is to have mandated self-driving cars. Having under-the-vehicle connectors that are easily accessible as some poster mentioned before, is of concern if you are somebody’s target, so no reason to be paranoid. A professional thief won’t bother to go under the car. If they really want it, it will be “gone in 60 seconds” :P

    Stuff like On-Star is more scary. Having someone else be able to control your car remotely stinks of big brother. If all cars have this in the future, I’ll be one of the owners who clip and short the antenna. I don’t care about their claims on how it is “good for you”. I’ll put a good alarm in it, take care of where I park it, carry a GPS and an extra set of keys so I don’t have to subscribe to your “service”.

    About this hack, I wonder if it is possible to put a board “in between” the car’s ECM and be able to fool a DMV computer.

  32. Who the hell cares? Do you want the government to lock our cars down? Do you want all those awesome tuning chips to become un-usuable? If you leave your car door unlocked while you’re not around, you deserve to get hacked.

  33. This post is tagged odb-ii, referring to the obscure Ole’ Dirty Bastard protocol. I think it should be tagged OBD2, referring to the more common On Board Diagnostics 2 protocol.

  34. The bottom line here is that a lot of control can be exerted over a car simply by interfacing with its (easily accessible) data buses. Although there are certainly security concerns involved, as a lot of people have already mentioned, the “hacker” side of me finds this at least a little bit interesting for non-malicious purposes. I’m sure I’m not the only one here who likes to connect, monitor, and control just about every aspect of life with a computer, and if I can have full access to every part of my car just by plugging into a port under the dashboard, I’m inclined to see that as a plus. :)

    1. There is a doctor who works in a central PA hospital and he is a hacker. He has been stalking me for years. He took the opportunity to hack into a Jeep dealership’s computer and when my vehicle was being serviced, code was injected. The code allows him to follow my vehicle, even when 150 miles away. My RKE and overhead console module was disabled at my request as I suspected those systems were enabling his tracking efforts. Now I know.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.