
The Crisis of Connected Cars: When Vulnerabilities Affect the CAN Standard - SanderMak
http://blog.trendmicro.com/trendlabs-security-intelligence/connected-car-hack/
======
michaelt

      our attack can be enabled with any remotely exploitable
      vulnerability that allows the attacker to reprogram the
      firmware of an ECU (e.g., the infotainment system).
    

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.

~~~
nateguchi
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.

~~~
ellisv
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/](http://opengarages.org/handbook/ebook/)

------
jaclaz
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.

~~~
ellisv
> 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...](https://www.theguardian.com/environment/2017/mar/06/nebraska-
farmers-right-to-repair-john-deere-apple)

------
fenwick67
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.

~~~
schwarrrtz
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.

------
jinzo
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

------
tyingq
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.

~~~
sebazzz
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.

~~~
tyingq
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...](https://www.autoblog.com/2015/01/21/2-million-progressive-
snapshot-customers-may-be-at-risk-for-car/)

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.

------
RealityVoid
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.

------
tareqak
Techmeme summary: _Researchers find indefensible vulnerability in CAN protocol
that controls airbags and sensors including antilock brakes in all modern
vehicles_

------
IshKebab
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?

------
debatem1
CAN should have authentication built in. That's the root of the problem, and
without fixing it everything else becomes hard.

~~~
gumby
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_.

~~~
debatem1
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).

