The Crisis of Connected Cars: When Vulnerabilities Affect the CAN Standard(blog.trendmicro.com)
blog.trendmicro.com
The Crisis of Connected Cars: When Vulnerabilities Affect the CAN Standard
http://blog.trendmicro.com/trendlabs-security-intelligence/connected-car-hack/
18 comments
I know that Volvos have two separate CAN buses, one for important safety critical systems and one for interior functions and infotainment.
They are joined with a proxy/firewall that provides separation and limits the functionality available between the two.
I'm guessing this attack would only work in this case if the attacker could physically access the OBD port to gain entry to the safety critical bus.
They are joined with a proxy/firewall that provides separation and limits the functionality available between the two.
I'm guessing this attack would only work in this case if the attacker could physically access the OBD port to gain entry to the safety critical bus.
I believe devices on the CAN can typically see, and therefore spoof or simulate, packets from other devices. I'm not sure that physical access is really necessary because modern vehicles ship with networking capabilities (e.g. OnStar) that already have access to the CAN.
[1] http://opengarages.org/handbook/ebook/
[1] http://opengarages.org/handbook/ebook/
... All it takes is a specially-crafted attack device, introduced to the car’s CAN through local access, and the reuse of frames already circulating in the CAN rather than injecting new ones (as previous attacks in this manner have done)....
Generically (and IMHO) the original "bad" idea remains that of mixing together the actual "security related" and "vehicle operation" items with the entertainment and navigaton system AND allowing external connections (via SIM or similar, OTA and the like).
It is just like most computer vulnerabilities, the ones requiring physical access have in my opinion an almost null impact in practice (if such a physical access is made difficult or impossible), whilst anyhting "remote" is really preoccupying.
One of the suggested mitigations of putting the OBD-II connector inside a hardware locked case (presumably with a mechanic lock with key, IMHO safer than an electronic one with a password) goes in this direction, no physical access, less risk.
It is just like most computer vulnerabilities, the ones requiring physical access have in my opinion an almost null impact in practice (if such a physical access is made difficult or impossible), whilst anyhting "remote" is really preoccupying.
One of the suggested mitigations of putting the OBD-II connector inside a hardware locked case (presumably with a mechanic lock with key, IMHO safer than an electronic one with a password) goes in this direction, no physical access, less risk.
> One of the suggested mitigations of putting the OBD-II connector inside a hardware locked case (presumably with a mechanic lock with key, IMHO safer than an electronic one with a password) goes in this direction, no physical access, less risk.
As long as we give owners the key. Reminds me of farmers who can't service their own tractors [1].
[1] https://www.theguardian.com/environment/2017/mar/06/nebraska...
As long as we give owners the key. Reminds me of farmers who can't service their own tractors [1].
[1] https://www.theguardian.com/environment/2017/mar/06/nebraska...
tl;dr if you have physical access to the CAN bus, you can cause enough errors to render it inoperable, by tampering with CAN frames and flipping bits around.
If you have physical access to the CAN bus you can also make it inoperable by shorting the two wires together... not sure the takeaway is supposed to be with this.
If you have physical access to the CAN bus you can also make it inoperable by shorting the two wires together... not sure the takeaway is supposed to be with this.
The takeaway is that by tampering only with CAN messages sent by a particular system, you can force that system to disconnect from the network. For example, an attacker might use this exploit to disable the airbag, or disable the engine while the car is driving, or cause other safety problems.
As I'm currently on vacation I don't have the means to study this further, but on the quick lookout I found at least one problem in how this is described. If I understand correctly it alters frames so that the device goes off bus. From their claims this is not detectable with modern tools. If I'm not missing something then I can guarantee you that the dashboard reports errors when a device is off bus. Also at least modern VW and BMW vehicles offer a lot of data (to the diagnostic tool) on the state of the can networks (dropped frames/etc). I'll have to dig deeper, but on the first glance it looks like they found a way to buss off devices, but over-prpmise on the stealthines of the vuln.
Edit: typos
Edit: typos
Interesting in that fixing it would be difficult, as it's a documented part of the protocol.
I suppose, though, manufacturers could at least focus on isolating the OBD-II port from most of the CAN bus, and putting the unfirewalled CAN bus connectors in a place that's harder to get to. There seems to be a lot of variation there now. Some cars isolate at least some functions, others have the OBD-II port completely connected to everything.
I suppose, though, manufacturers could at least focus on isolating the OBD-II port from most of the CAN bus, and putting the unfirewalled CAN bus connectors in a place that's harder to get to. There seems to be a lot of variation there now. Some cars isolate at least some functions, others have the OBD-II port completely connected to everything.
The problem is not OBD-II. Rather the risk is when another vulnerability occurs on another system attached on the CAN bus like an infotainment system. If that infotainment system is vulnerable and the vulnerability allows to control the CAN bus then you have the real problem.
I don't see the difference. Both have no need for unfettered access to the entire CAN bus.
See this for example: https://www.autoblog.com/2015/01/21/2-million-progressive-sn...
OBD-II messages are a subset of CAN bus messages, identified by bits in the header, so it should be simple to filter/firewall down to just what's needed for that physical port.
See this for example: https://www.autoblog.com/2015/01/21/2-million-progressive-sn...
OBD-II messages are a subset of CAN bus messages, identified by bits in the header, so it should be simple to filter/firewall down to just what's needed for that physical port.
I am surprised how this is news seeing how it is an obvious mechanism to anyone working with CAN. If you have access to the CAN bus you can pump whatever message you want on the bus since it has no authentication.
Techmeme summary: Researchers find indefensible vulnerability in CAN protocol that controls airbags and sensors including antilock brakes in all modern vehicles
I mean... isn't CAN a trusted unauthenticated bus? So if you have access you can pretty much do anything you want. Right? Am I missing something?
CAN should have authentication built in. That's the root of the problem, and without fixing it everything else becomes hard.
That's easy to say but if you look at CAN it's just a set of small serial frames over RS-485 designed to be usable by an 8-bit (or smaller) processor. Like a simple SPI/TWI bus, but off-board.
Sure, I am upset that it's not more secure, as I am about the same thing with SCADA and (shudder) MODBUS, but I recognize where how the problems emerged: these busses are, by current standards, old.
Sure, I am upset that it's not more secure, as I am about the same thing with SCADA and (shudder) MODBUS, but I recognize where how the problems emerged: these busses are, by current standards, old.
While you're not wrong, it wouldn't require throwing out 8-bit MCU support to bring CAN into this century. In particular, replacing the CAN CRC with a short auth tag would not be beyond the capability of many small MCUs at low speeds (10s of messages/s).
I will be honest, it seems very unprofessional if vehicle safety engineers have allowed complex, network-connected entertainment systems to have write access to the same CAN bus that the brakes and throttle are on.
After all, if a hacker can remotely reprogram anything on that CAN bus, for sure they can remotely trigger a fatal crash.