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.
Now everything from the car could be read but nothing can be controlled.
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.
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".
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.
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).
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. 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.
Someone hacked VW Canbus to play video games on the dashboard of a polo.
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.
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.
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.
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:
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.
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.
"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.
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.
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.