Researchers from the Argus Research Team found a way to hack into the Bosch Drivelog ODB-II dongle and inject any kind of malicious packets into the CAN bus. This allowed them to, among other things, stop the engine of a moving vehicle by connecting to the dongle via Bluetooth.
Drivelog is Bosch’s smart device for collecting and managing your vehicle’s operating data. It allows a user to connect via Bluetooth to track fuel consumption and to be alerted when service is necessary. It was compromised in a two stage attack. The first vulnerability, an information leak in the authentication process, between the dongle and the smart phone application allowed them to quickly brute-force the secret PIN offline and connect to the dongle via Bluetooth. After being connected, security holes in the message filter of the dongle allowed them to inject malicious messages into the CAN bus.
The Bluetooth pairing mechanism, called “Just Works”, has been fixed by Bosh by activating a two-step verification for additional users to be registered to a device. The second issue, the ability for a maliciously modified mobile application to possibly send unwanted CAN messages, will be mitigated with an update to the dongle firmware to further limit the allowed commands that the dongle is able to place on the CAN bus.
Bosch downplays the issue a bit in their statement:
It is important to note that scalability of a potential malicious attack is limited by the fact that such an attack requires physical proximity to the dongle. This means that the attacking device needs to be within Bluetooth range of the vehicle.
The problem is that physical proximity does not equal Bluetooth range. Standard Bluetooth range is about 10m, which is very arguable physical proximity, but it is pretty easy to buy or even modify a Bluetooth dongle with 10x and 100x more range. When adding a wireless connection to the CAN bus of an automobile, the manufacturer has an obligation to ensure the data system is not compromised. This near-proximity example is still technically a remote hack, and it’s an example of the worst kind of vulnerability.
Hijacking the WiFi subsystem (exclusively over WiFi), hijacking a TV over the DVBT signal and now this.
Something is pretty rotten in the way those gadgets are designed and then poured by the millions into the world.
Hopefully those manufacturers get their act together before anything *really* ugly happens.
And kudos to the researchers out there doing this work and publishing it.
I echo your kudos to the researchers. I think we need to really celebrate security research done in responsible and open ways. It needs to be a lucrative and desirable career so that we catch more vulnerabilities at the same time as working for better practices to design secure systems from the start.
Poorly written software that can be hacked by elaborate means thanks to shoddy programming practices.
Or maybe give the old method a chance to work… you know, threatening security researchers who expose your wretched rat shit. /s
Not to mention the range of even an unmodified bluetooth dongle isn’t much of an issue when you consider traffic. This exploit [kind of] implies physical access to plug in the specific device (arguably more of a limitation than proximity), which means tailgating or driving along side a target car isn’t at all far fetched. But hey, it’s not “scalable” right? so I don’t have to worry about alot of engines shutting off at 60mph on the freeway right?
I was thinking just that. It’s really hard to match the speed of the lane next to you, right? 8P
Is it bad that I would like to see gridlock caused by this so maybe the manufacturers wise up and realize that hacking has never been this “popular” and therefore security has never been this important?
1. No one seems concerned that this was done by A.R.G.U.S.? I mean really… (Sorry, obligatory DC joke)
2. How long before someone finds a way to make this work over cell on the Verizon Hum?
3. I get that computerizing cars has its upsides, but I’ve never had to worry about On-Star hacking a carburetor, or invasive and BS emissions test results from a computer dumber than a wristwatch…
I wonder how people will feel when manufacturers “get their act together” and really do a good job of locking down the firmware so it’s not possible to hack.
Probably like these people feel:
http://hackaday.com/2017/03/24/the-icon-of-american-farming-that-you-now-have-to-hack-to-own/
It’s quite a fine line between “You are idiots for making this device insecure” and “You are idiots for making this thing secure ”
It’s a fairly difficult engineering challenge to make things:
1) Easy for customers to use.
2) Manufacturable with non-default passwords.
3) In-the-field updateable.
4) inexpensive.
I love the challenge and I’m in awe at the wonders some groups come up with to partly address these issues.
I think with John deere it was more of a concern of proprietary source code, decimating the warranty on an extremely expensive equipment and not being able to have options in repairing said equipment. You can absolutely have secure and safe tools without locking everything down.
What?
Can you describe how propriety sourcecode decimated the warranty on those tractors? Because I don’t understand.
Also, how can a not locked down system be secure?
Many people make claims such as yours and then disappear when asked for technical details demonstrating the veracity of those claims.
I’m not sure if this is what the OP meant but what about a typical router? Think of one where you can load openwrt. It’s not locked down because any one can load a new firmware (if they have physical access) but it’s secure (as much as possible obviously. Everything has a weakness) because you can load said firmware only from the local network and you need the admin password and none of this things can be done remotely from the internet.
The problem with the John Deere example is the DRM induced downtime for farmers, which were used to little or no down time prior. It serves no real purpose other than to make John Deere richer every time something breaks. Not exactly the same thing as having OBDII wide open for anyone to exploit.
I was just thinking the same thing. It seems that people see this as two separate issues when it is really two sides of the same coin. I can’t help but feel that the Hack-A-Day writers are a little hypocritical, or at least double minded, on the issue of safety/security.
Seriously all that was needed it to implement the standard bluetooth protocols and have a pin pairing with basic encryption. WTF is wrong with these companies.
It’s even worse on the CAN side of things. Sounds like they’re using a blacklist to determine what CAN messages they’re not allowed to send, rather than a whitelist of messages they are allowed to use.
imagine a high profile target driving down the highway at high speeds, and somebody with a drone or with a car like 50meters infront or behind or even during passing by the target car, just shutting down the engine, that could be very devestating and dangerous. i can see various agencies using things like that to make it look like an accident. i wouldnt even be surprised if it was already used for things like that.
Or just tether that sucker to a phone and control it over the cell network…
Leaving a bunch of physical evidence, but it gets the job done.
“that could be very devestating and dangerous” erm, how exactly? you would be safest on a highway, just turn indicator and roll to the shoulder…
Yeah, give that one a shot from the high speed lane of a large, crowded highway. Instant 80 MPH roadblock.
Yup, worked all three times it’s happened to me..
(Snapped cam belt, busted distributor, and fuel pump quit.)
Fuel pump was the easy one, in slow lane, and an offramp appeared, nearly made it to a coffee shop… knew what it was because it started screeching not long before it quit. … anyway got a coffee… smacked on the bottom of the tank with the tire iron.. got it running lumpy and limped home on the service road.
Snapped cam belt was more interesting, I was just at steady speed in middle lane as came up to major offramp/intersection with another limited access highway, so there were multiple lanes off, so I was three lanes out from the shoulder when it let go…. slightly more nervy, but I guess the traffic was used to people suddenly realising they needed that exit.
Busted diz was a pisser, shaft snapped as I dropped a cog for hyperspace insertion, i.e. merging to fast lane as a huge bunch of slow traffic appeared… this being a manual, I dropped a few mph instantly before I got the clutch down, then it was real hairy as I had to get through 3 lanes of slowing traffic… you just have to shove your way through, take any gap you fit through…. nearly got “That guy” in an Audi though… because inside lanes had practically stopped ahead, and I had to roll a little bit further due to a bridge with narrow shoulder… exit half mile down.. so just as the shoulder widens… I roll into it and “that guy” pops out from a few cars back to try to boot down the shoulder.
And now we wait for third-party app for Bosch Drivelog to pop on Google Play that allow you to check obd error codes, have fancy dashboard with all the different gauges and also a little backdoor that lets the creator to do anything he wants with your car. I wouldn’t be suprised if with enough data gathering and a bit of ingenuity it was possible to steal your car without the key ever leaving your pocket.
What other nasty things can the hypothetical hacker do over obdii? Just turning off the engine is more of an annoyance than actually dangerous. Engines fail occasionally without any malicious outside influence and a competent driver must be able to handle that safely and move of the side of the road without killing anyone. If they can’t they shouldn’t have a driving licence. If the hackers could affect throttle, braking or steering then I’d be more worried.
Thinking about it, forcing somebody to stop on an empty county road would be an effective way to set up an easy carjacking. Any others we should be aware of?
That’s about the entirety of the risk really…. and not a terribly reliable scenario for the attacker… First off you gonna know you’re being hassled as a vehicle has to get close enough to you on normally empty roads to hook your OBD II dongle…. then if you’re half sharp, before you’ve lost 20mph you can yank the dongle, power off at key and restart.
… though actually by blatting screwy sensor values on the CAN it may be able to put you into “Limp mode” which you need a battery off reset to get out of… unless you can key dance it alive again… or just have your dongle back in long enough to clear fault.
Depending on the car, the ECU can control throttle, brakes, and steering.
Just wanted to add this is due to dongles abusing OBD-II, not a failure of OBD-II itself.
OBD-II is intended for use as a technicians diagnostic aid, something which may need to be used during a LIVE drive test in order to diagnose failures some of which may only occur intermittently ‘in the field’ and some of which may require unusual conditions to be triggered to make them happen.
Now having said that, OBD-II was invented back in the early 90s. Wireless connectivity was a non-issue, and the devices which could interface with a car ECU were laptop to compact notebook sized at smallest (Go look up the early Snap-On scan tools for an example.) Furthermore outside cars with security systems there was no manual way to trigger an engine off condition (or in many cases any other power assist features.)
The failure here comes from a combination of new systems (many proprietary/vendor specific) and direct CAN-bus connectivity to the obd connector (making for easier device enumeration, while also making it more dangerous since the PCM no longer has a dedicated diagnostic channel to act as the gatekeeper to the rest of the devices anymore, unlike previous units utilizing serial based communications.)
I would have to go dig out/through my notes for more specific information, but most of the failure is insecure devices using a port designed for professional use only, combined with sloppy design choices and QA by the vehicle manufacturers and their OEM electronics vendors.
Some great research, somewhat undermined by Bosch. I don’t think their damage mitigation statement is the best approach. They should have just been honest and asked people to update their firmware. Trying to downplay the risk of such an exploit may help their stock prices, but won’t help the users of their product ¬_¬
I didn’t use the Bluetooth one before, and haven’t thought those risks. I had two scanners now, one is from Autel, the other one from LAUNCH. I prefer the second one and think it is reliable. Don’t need to install the Firmware. Works well too.http://www.dwz.cn/6TAaOu