A Remote Attack on the Bosch Drivelog Connector Dongle | Hacker News Reader

A Remote Attack on the Bosch Drivelog Connector Dongle

argus-sec.com

83 points_-_T_-_25 comments

I went out of my way to buy a vehicle with no GSM chip built in whatsoever (that's not easy in 2016). Car companies care as little about protecting their tech as they care about trying to fix USAs lovely car dealership system.

I know this post is about a dongle, but you can remove a dongle from a car at least. You can't remove the GSM chip from most new cars that's uploading your location to heaven knows where and how many people have hacked their database this week.

Can't you disconnect / destroy the antenna?

I knew IOT devices generally have weak security, but I didn't anticipate them so easily being connected to physically dangerous objects like cars. I wonder how common this will become.

This is actually more common than you'd think (and keep in mind that the Drivelog is relatively secure, even by non-IOT standards).

Just to clarify, the no-name Bluetooth OBD-II adapters a lot of people use come with a default PIN of 0000 or 1234 - that can't be changed - and the OBDII port is usually powered even with the vehicle switched off and locked.

However, how much you can do really varies depending on the vehicle. I have a 2010 Prius and the OBD-II port is powered when locked and switched off, but the computer isn't active (so the port can't be used) unless the vehicle is switched on. Also the port itself is mainly read-only in my case, other than opening windows there isn't much I can do through it (I wanted to add remote-start, but it's not possible).

Just to clarify...the ports ARE NOT read only. They are very much writeable. The devices you mention just give a readonly interface.

The OBDII protocol itself is read only. OBDII requires a subset of parameters to be readable through an SAE (society of automotive engineers) developed protocol using the standard port. This occurs through reading of data that is regularly broadcast onto the CANBUS itself. In effect, OBDII runs on top of the CANBUS, with the connector in the cabin allowing access to OBDII via the CANBUS.

However, the ports are much more capable and include direct connects to just about every system. CANBUS actually interconnects The CANBUS itself is typically a 'security through obscurity' approach where tuners are forced to reverse engineer CANBUS packets to access the networked exchange of information within the vehicle. In fact, 7 of the 16 pins in the connector are 'manufacturers discretion'. CANBUS gives access to it all, if you speak the language. OBDII is a 1pg sheet of translations.

You can see the results of this through examples like that published in 2015 by Wired[0]. That was possible because the infotainment system and the engine, and transmission, and body control module, etc. are all connected to the same CANBUS...and information on the network is fully trusted once you know the language.

[0]https://www.wired.com/2015/07/hackers-remotely-kill-jeep-hig...

https://hackaday.io/project/6288/logs

Someone hacked VW Canbus to play video games on the dashboard of a polo.

I've owned cars where the ODBII port couldn't do (that) much more than the required subset of reads, and only a second port with access to the CAN network (that required disassembling part of the dash to access) was able to do things like what that link describes

>The OBDII protocol itself is read only

I'd say "read mostly". Clearing the CEL with mode 4, for example, would cause your vehicle not to pass a state inspection until it went through a drive cycle...which can be quite a while.

Mode 8 is more troublesome. It's not as standardized, so you have to know vehicle and model specifics. But you can actively manipulate real physical things in the car, canister vents opening/closing, etc.

So, not as wild west as unconstrained CAN bus access, but not really read-only either.

>So, not as wild west as unconstrained CAN bus access, but not really read-only either.

I'd say mode eight makes it absolutely the wild west. In addition to clearing the CEL, I can use my CAN bus to program everything from the TPMS IDs for my wheels all the way to the pre-sets in my radio along with everything in-between including the amount of power steering and brake assist applied.

I'm not convinced all of those things are done via mode eight, but rather, by direct CAN bus access. I know, for example, some models of cars only expose a limited number of actuators over mode 8, mostly emissions stuff.

Do you have a reference? In any case, "mode 8" is a subset of what unconstrained CAN bus access gives you.

Edit: The best info I can find is in this whitepaper: http://www.autosec.org/pubs/cars-oakland2010.pdf

You can see packet dumps on page 10. These aren't obd-ii packets. They are CAN bus "DeviceControl" packets. These are the ones they used to manipulate braking, etc.

The context I'm trying to convey is that a dongle that exposes the OBD-II port wirelessly should probably expose only the "safe-ish" parts of OBD-II. No direct CAN bus access, no access to mode 8, mode 4, etc.

>The context I'm trying to convey is that a dongle that exposes the OBD-II port wirelessly should probably expose only the "safe-ish" parts of OBD-II. No direct CAN bus access, no access to mode 8, mode 4, etc.

Yes, it should but what does that mean in the context of a device you plug into your OBD-II port which can be made to run anything an attacker wants? Most of these devices are running full systems similar to LTE radios, etc., which have been demonstrated to be so vulnerable that it's possible to hijack the embedded computer to run code of choice. Just recently we saw the radio disclosure from Google and from several years back there was this one from a research team at Intel:

https://www.youtube.com/watch?v=q4pRYZjzL_E

Honestly, at the point an attacker can run arbitrary code, short of implementing some crazy in device firewall, expect a device like this to have access to a bunch of stuff by the fact it's plugged into the OBD-II port.

The dongle is taking something that requires physical access and exposing it on a network, in this case with weak 8 digit pins. That implies a responsibility to be smart about it. I assume there's a microcontroller in front of the serial comms. That would be a good place to filter packets. These are fairly simple filters that probably only need to look at the first byte or two of a request to limit to OBD-II only, and only certain requests. That's not a crazy firewall, just simple microcontroller code.

But sure, car manufacturers should do something as well. OBD-II port is a misnomer. It's like calling an ethernet port a "WWW Port". It doesn't need to expose everything that it does. The manufacturers know these are being used by consumers. They can put a more open port somewhere else for mechanics.

fair enough correction...thank you. I was being overly simplistic.

Most of trucks in europe have gps systems which connect to CAN in order to measure driver efficiency and vehicle condition. They are also connected via cellphone network to internet (only sometimes through APN, mobile equivalent of VPN). All of them have security holes, typically much worse than this dongle, just no one cared to look at them yet.

Wouldnt it be possible to have the CAN chip only send data to the iot microprocessor? So not attaching the Tx but only Rx. As far as I understand CAN it is a bus everything is dropped on, without an actual request-response system.

Now everything from the car could be read but nothing can be controlled.

This. One-way communication needs to make a comeback in a big way.

This is fundamentally impossible in a CAN bus, and is stupid and functionality-limiting anyway. Everyone likes it when the radio turns off when the ignition does, these systems need to be able to talk to each other to get the functionality you expect.

What you need is to move away from the non-authenticated bus paradigm entirely, to a network-based system where some devices may be assumed to be hostile (which is what you have, like it or not).

This inherently involves authentication and privilege systems, so that the pedal controllers can prove to the brake controllers who they are, so that when the radio/head unit tries to interface with the brake controllers the brake controllers can go "woah, hey, you're not supposed to be touching the brakes".

This at least would require escalation from a trivial system like the head unit to a more crucial system, which is a more typical model for exploits in computer OSs.

This is a workable threat model. "Trust everyone all the time" is no longer, and hasn't been since we allowed external connectivity to automobile systems.

CAN is a request-response bus, you send a query, get ACK, then queried chip sends response. If you need to read something, you query for it. You can do queries like "start giving me rpm data every 1s", but you need to query for this, also ecu has limited resources for such queries, so you need to switch between different sets of data. Of course if something else requests such data you can listen for it too.

Most designs have a CAN transceiver that takes TTL/UART and implements the differential signalling used on the CAN bus. I've used the TJA1048 before in designs:

http://www.nxp.com/documents/data_sheet/TJA1048.pdf

You could certainly clip the TX line and make it receive-only if you wanted. But there's always one person in the room that says "hey, why not leave it in in case we change our mind about software?", or perhaps it's more "hey, let's copy the reference design and move on".

Not possible, as you need the request/response model to get the interesting information. You send "010D" (mode one, PID 0D) to get the vehicle speed value. That's "read only", but you need to send data to get data.

What does seem to be a hole is that the dongle exposes general CAN bus communications, as well as OBD-II commands/modes that are NOT read only.

Here's a chart (from wikipedia) of the different OBD-II modes: http://imgur.com/a/YpGNU

It's fairly obvious which ones would be somewhat safe to expose. They would need to block the others in the dongle, and block general CAN bus access as well.

I believe the high level problem is that the dongle exposes everything, and they are doing the parsing in software on your phone or laptop.

Well, and auto makers not having a separate CAN bus for the OBD-II connector to talk to the ECU. I believe some vehicles do, and some don't.

Is the Drivelog Connect even necessary?

"Drivelog Connect allows your car to speak to you. Your car directly connects with your smartphone. All the information becomes available at your fingertips."

Many of the features the app offers could be made available in the car's console/monitor.

Like: - automotive diagnostics, display of real-time driving behavior(should you really be looking at your Smartphone while driving), Logbook for recording and storage routes...

I don't really see benefit of this app.

Seems to me that the main thing they could do that's cheap and easy is require a button press on the device to pair. Unfortunately that's not as simple as a firmware update.

Actually, I was impressed how much security Bosch included in their device.

For a IoT device I would give this a gold star. I am sure after this report was given to them, they patched their firmware.

I dunno...the dongle gives up it's certificate so that you can brute force it offline. It's an 8 digit numeric only pin. 100 million possible PINS, when you can do 100 million SHA-256 computations in 30 minutes on a typical laptop. That seems unwise.

And it allows you to send and receive any CAN bus message you want, versus just some subset of OBDII. As far as I can tell, the features don't require anything other than querying OBDII for some very small subset of data. So if the dongle only passed those request packets, and dropped everything else, it would be miles more secure. Since it appears to be a simple passthrough device, I'm not sure there's enough horsepower in the dongle to fix that with firmware.

Reply on news.ycombinator.com