Semi-OT: Hackers Remotely Kill a Jeep on the Highway

Exactly. Even if a "compromised" node does not have direct *physical* access to a "special" bus, the fact that the compromised node can effortlessly masquerade as ANY node on the bus(ses) to which it has direct contact means any other gateway/bridge nodes *will* propagate forged messages that it generates *to* that "other bus" AS IF the messages were created by the genuine node instead.

This also assumes those gateway nodes are smart enough to recognize

*specific* traffic on "bus #1" as only legitimate *on* bus #1. I.e., if a node on bus #1 forges a message that a node on bus #2 would normally generate, the gateway *may* be naive enough to transport the message across the protection domain even though it was detected on the "wrong" bus! Because the code is written to assume that traffic on bus #1 is legitimate, regardless of content (security vulnerability).

Looking at a factory service manual for a Nissan Murano (we're in the market for a new vehicle so I've been reading a lot of service manuals) shows one or two CAN busses (depends on whether or not the vehicle has the Advanced Driver Assistance System (ADAS) installed -- gizmo that acts as a proxy for the driver). The *first* CAN bus always has the following nodes:

- Engine Control Module

- Antilock Brake System

- Tranny Control Module

- Steering Angle Sensor

- All Wheel Drive Control Unit

- Automatic Backdoor Control Module

- Combination Meter (this is a display)

- Power Steering Control Module

- Audio / Visual Control Unit

- HVAC Control

- Body Control Module

- Intelligent Power Distribution Module

When the ADAS is present, it resides on a separate CAN bus along with the Driver Seat Control Unit and a Gateway Module (to the first bus).

So, hack any of these modules -- regardless of how "critical" they are for the vehicle to "operate as a means of transportation" -- and you can effectively masquerade as *any* of the other nodes on the same physical bus. And, potentially, as any node on the "other" bus as well! I.e., if the A/V Unit is hacked and emits a message that *should* have originated from the ADAS *via* the gateway, how can any node on the first bus know that it was NOT propagated to the bus by the gateway? How does any node know that it was not generated *by* the ADAS???

See above. Physical separation/isolation doesn't buy you anything. The (e.g., CAN) protocols don't authenticate the sender/recipient. You have to layer an additional protocol on top of it to even

*begin* to address these issues. And, why would you do so -- *if* your design attitude is that "connection to the bus indicates your authority to *use* that bus"??

The recent alleged airliner hacks took advantage of this "design naivite" -- "if we see a command on the network that tells us to fly sideways, we'll assume it was generated by would legitimately create such a command; NOT some guy sitting in the coach cabin hacking into the in-flight ENTERTAINMENT SYSTEM!"

And a "firewall" can be any sort of packet filtering mechanism that may, in fact reside anywhere in the network. E.g., a VPN effectively gives you a secure tunnel (which may or may not be encrypted).

This is why I took the action of embedding authentication protocols in my network fabric (which is physically secure). So, you can subvert any node that you can gain access to (physically, etc.) and ONLY forge the transactions in which the compromised node could legitimately participate!

E.g., in my world, the A/V Unit would never be able to generate the "Transmission is in Park" message (well, it *could*... but the fabric would never route that message to anything that would recognize it *as* the "Transmission is in Park" message and act on it as if true!) Instead, you'd be able to claim the user is calling for the "Rear Window Defogger" to be active; or the "ACbrrr Active" signal; etc. (i.e., the signals that the A/V Unit *does* legitimately emit on that vehicle!)

[In my case, this assumes you have also cracked the rolling encryption keys to even *generate* CURRENTLY RECOGNIZABLE forms of those messages! If you appear to be spewing jibberish (bad keys), then your node is intentionally and deliberately cut off from the rest of the system; it's either malfunctioning or has been compromised! (Imagine a VPN for each virtual communication path in the system, enforced in the *fabric* itself!)]
Reply to
Don Y
Loading thread data ...

Why not? If that is what safety requires, that is how it will be done. That is why the brakes are split into two circuits. It doesn't require "two" displays. It only requires that the engine speed and car speed are reported through separate electronics in the display. I know my car does that anyway... because it costs less.

If you need security, you do what it takes for security. Two buses are not a problem. Yes, it's that simple.

--

Rick
Reply to
rickman

That is based on the assumption that there are messages that can travel from the insecure bus to the secure bus. Obviously that has to be prevented in all cases.

Yes, I suppose a total idiot might design a secure system this way. Or they would design it to preserve security.

Why would the ADAS need to *control* any of the units on the secure bus? The ADAS might have commands to query devices on the secure bus, but if you allow control that is a way for hackers to get in.

How does the A/V unit get hacked? Does it have a wireless connection? If so, that is a problem and needs to be corrected.

--

Rick
Reply to
rickman

Am 23.07.2015 um 12:26 schrieb Don Y:

Only if the node it's masquerading as is on the same bus as the compromised one. And only if the firewall/gateway node is given no means to recognize the fact that there are now two data streams purporting to be from the same node.

That error case is not a practically relevant one. Gateways have enough work on their plate as-is. They have to know which message they're supposed to receive on which bus, and which they're to echo/send, or they just couldn't handle the work load. Otherwise they would flood each network with the traffic of every other one.

In practice, it's not. Car network designers really aren't _that_ daft (presently publicised bad example case possibly excluded).

That's quite a small, old-fashioned layout by today's standards. A current-model passenger car would have between twice and four times as many CAN ECUs as that, and putting drive train control units on the same CAN network as, say A/V or HVAC ones has gone out of fashion about a decade ago.

There are still some nodes that are so central that it would be hard to the point of impossible to isolate their security-sensitive functions from their other ones, e.g. the steering wheel group. These days buttons and levers on and around the steering wheel (for very good reason, too) control a wild mix of systems, only some of which are critical (cruise control, driver assistance, control over what gets displayed in the combination display, blinkers, wipers, radio, telephone, ...). And then there's the airbag sitting in the middle of all that. And the meaning of buttons will change based on what the multimedia central display currently shows, or what options were ordered with the car. Good luck trying to implement security isolation zones in _that_!

And then new legal requirements like "E-Call" practically require to break any isolation barriers between established critical systems and others like the multimedia/navigation/telephone ones that are by _huge_ popular demand about as architecturally open and as connected as a desktop PC, and consequently about as security conscious as those.

It's basically a miracle they largely managed to keep MS bloody Windows out of those boxes so far, and now they're supposed to perform survival-critical emergency tasks! That's insanity, and I'm quite sure everybody involved knows it.

For starters, the gateway itself knows that (because it should have been sending that message, not receiving it). And it doesn't take much engineering to make such extra message trains recognizable. About the simplest one is a rolling counter in the original messages. That doesn't allow yet to detect which of two message streams is actually genuine, but it does allow detection that something's foul in the state of Denmark.

Reply to
Hans-Bernhard Bröker

So why would there be only one bus to the steering column? My car has no CAN bus I'm pretty sure and has half those functions so that many wires. Reducing this to two buses should be duck soup.

Using one UI for both secure and insecure functions is problematic and should not be done.

Why would any of that have to connect to the secure systems? If it is needed to send a command to not allow the car to start or even to shut it down, that command would need a protocol that can not be duplicated, a secure protocol through a secure control point.

Really? What critical emergency tasks are handled by the cell phone interface in a car?

--

Rick
Reply to
rickman

Am 23.07.2015 um 22:36 schrieb rickman:

Because the electric pass-through mechanism from fixed to rotated assembly is brittle enough with just a few wires. Adding wires makes it worse.

That assumes the distinction is just two-fold. So: is the navigation system's next-turn indicator to be secure or not? Or the indication motor temperature gauge? Or the one for outside temperature?

How much place would you need in the central behind-the-wheel combination display to be able to reserve a dedicated area (and isolated hardware to control it!) per security level? There's only that much space available...

It's really not that simple. Automotive security involves not just data security. Some of it is safety-oriented UI design. E.g. all those user input devices are on and around the steering wheel for a reason: not because their function is safety-critical, but because it's safety-critical that the driver should keep his hands on the wheel, which _is_ safety-critical.

And then there's that other unholy beast, called "the market", which flat-out _demands_ that of course it must be possible to navigate the entire 6000-entry MP3 collection while driving, and without taking the hands off the wheel. So now you "have to" put multi-purpose navigation buttons on the wheel, and a free-text display behind it that can show full ID3 tags, or people and magazines will laugh at your "prehistoric" infotainment system.

Because it's the secure systems that diagnose a crash. eCall, in case you missed it, is an upcoming government requirement to implement an Automated Crash Response via cell-phone emergency calls, coupled with GPS and manual interaction. Basically, OnStar by law.

Reply to
Hans-Bernhard Bröker

If I had to guess? Someone decided they could save something on the order of $5 per car by just running one network, and someone else approved it.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com 
Email address domain is currently out of order.  See above to fix.
Reply to
Rob Gaddi

An awful lot of these failures come from thinking (erroneously) that nobody would bother carrying out a given type of attack, rather than the attack itself being too subtle for the defender to conceive of.

Reply to
Paul Rubin

You snipped the part of my post that you should have read.

Nothing you have mentioned nullifies the need for isolation of the communications function of secure and insecure operations.

I have worked on military radios which solve exactly the same type of problems. So clearly it is doable. Their requirements are for as near absolute security as possible so that it impacts price. But that can easily be mitigated by not focusing on attacks through the manufacturing channels (yes, the military worries about back doors built into commercial chips) and accepting commercial levels of security rather than state secret levels. That is, being as secure as credit card processing rather than NATO communications.

None of that requires that the comms capability have any *controlling* access to the safety systems. Don't make easy problems hard.

--

Rick
Reply to
rickman

+42

"We don't need to reinforce the doors to the cockpit and provide DURABLE locks. think of all the fuel that would be consumed transporting those extra few pounds back and forth and back and forth across the country day in and day out! Who the hell would bother disturbing the flight crew?? That would be just plain SILLY! At the very least, the offender would be scolded and ordered back to their seat. And, probably face a HEAP of trouble when the aircraft *lands*! ... Huh? What's that? You mean the offender doesn't INTEND for it to land??? WTF??"

In my case, why "protect" the network drops in my guest bedroom from accessing/hacking my automation system? Do I trust folks enough to invite them into my home -- but *distrust* them and want to protect myself from THEIR malicious hacks?

This stupidly ignores the possibility that their *laptop* may initiate an attack based on malware already contained on it (or, attempt to connect to other machines in my home that don't normally "see the outside world") *or* malware that infects them during their visit! "They" (my houseguests) may have no role in the event -- other than plugging the laptop into the network connector!

Reply to
Don Y

Management: You guys need to get these new features working, STOP working on things that don't sell cars !

Engineers: If we don't fix these bugs, someone might be able to hack our hardware !

Management: Don't worry about hackers, they are not that smart.

Reply to
hamilton

Am 24.07.2015 um 20:22 schrieb Don Y:

I'll have to ask you to refrain from using that particular argument.

Earlier this year in the Alps, 150 people, including an entire class from a school not to far from here, died in a plane crash _enabled_ by exactly those: reinforced door and a durable lock to the cockpit. The reason was that the cockpit door prevented all attempts to stop a suicidal co-pilot from taking down the plane and everyone on board.

Reply to
Hans-Bernhard Bröker

Here it is. So you could start your car from your smart phone, etc. (comp.risks): ================================== Date: Tue, 21 Jul 2015 13:03:21 -0700 From: Lauren Weinstein Subject: Fiat Chrysler "connected car" bug lets hackers take over Jeep remotely

formatting link

Uconnect, a "connected car" system sold in a number of vehicles produced by Fiat Chrysler for the US market, uses the Sprint cellular network to connect to the Internet and allows owners to interact with their vehicle over their smartphone--performing tasks like remote engine start, obtaining the location of the vehicle via GPS, and activating anti-theft features. But vulnerabilities in Uconnect, which Fiat Chrysler has issued a patch for, made it possible for an attacker to scan Sprint's cellular network for Uconnect-equipped vehicles, obtaining their location and vehicle identification information. Miller and Valasek demonstrated that they could then attack the systems within the car via the IP address of the vehicle, allowing them to turn the engine of the car off, turn the brakes on or off, remotely activate the windshield wipers, and take control of the vehicle's information display and entertainment system. Miller and Valasek also found that they could take remote control of the steering of their test vehicle, the aforementioned Jeep Cherokee--but only while it was in reverse.

Thinking about what hackers will do to *autonomous* vehicles.

Reply to
Mel Wilson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.