Illmatics

Actually the Jeep Cherokee was running QNX [1] which is not 'Linux-based'...it's a totally different OS initially released many years before Linux. Frankly I'm not sure one can link the Cherokee hack to lack of a secure remote update mechanism. Of course signed images and secure updates are key elements of a secure embedded system. But the fatal flaw was IMHO a very unfortunate decision to route their IPC (DBUS) over IP with no authentication. A system is only as strong as the weakest link! [1] Excellent white paper link from authors of the Cherokee Hack: http://illmatics.com/Remote%20Car%20Hacking.pdf#page=20

Via documented OBD mechanisms? Yeah, probably not much. Via a standard Bluetooth<-> CAN interface plugged into the OBD port? Lots can be done, because generally the OBD port will expose the main CAN network and once you reverse engineer whatever inter-module messaging the manufacturer is using, you can act as a real module (for example, the throttle pedal) and all sorts of Bad Things are possible. Here's a great write-up, which is also a good primer on automotive control reversing techniques for the uninitiated: http://illmatics.com/car_hacking.pdf

This 10 year old article may be of interest if you are into stuff like that: https://illmatics.com/Remote%20Car%20Hacking.pdf

So the answer is yes, and no. > https://illmatics.com/carhacking.html is a good starting point. But there are a bunch of buses on a modern car, some of them are critical, some less so. Some are firewalled off, others are open. As you know you can get access to a lot of the car's inner workings by plugging into the ODB2 port. Its perfectly possible to brick some cars by fuzzing the ODB2 port. In principle, most things in cars _should_ fail safe. even if they are electric or talking over a bus of somesort.

Many mobile devices (especially those connected to a MVNO) are on one big giant subnet with "L2" style connectivity to each other. This is how Charlie Miller and Chris Valasek were able to remotely compromise vehicles with a vulnerable infotainment system via a pwned femtocell. "To find vulnerable vehicles you just need to scan on port 6667 from a Sprint device on the IP addresses 21.0.0.0/8 and 25.0.0.0/8."[0] [0] http://illmatics.com/Remote%20Car%20Hacking.pdf, pdf page 46.

Given how shoddy (http://illmatics.com/Remote%20Car%20Hacking.pdf) automobile software is, the idea of safety-critical components parsing radio broadcasts from other vehicles and acting upon that is very worrisome. I do not trust vehicle software manufacturers to get this anywhere near right.

Looks very cool! I coincidentally spent most of the weekend reading about OBD-II and CANs. I'd like to get a RasPi/Arduino with a temperature sensor connected and send CAN messages to regulate interior temperature for example. From what I gather, CAN messages are not broadcasted through the OBD port for sniffing, but once we know the proprietary CAN commands (VW in my case), we can send them through? Ie. For finding what car button sends what message, does one have to splice some cables to tap into the CAN bus? Dr. Charlie Miller & Chris Valasek wrote a nice paper on the subject back in 2013, and they hacked together their own cable: http://illmatics.com/car_hacking.pdf Being able to control the car's to implement my own features from reverse camera to remote start sounds very appealing.

Related: http://illmatics.com/Remote%20Car%20Hacking.pdf I used to think that, however vulnerable this kind of installation might be, at least it'd be limited in scope to the IFE and climate control stuff, because no one would be stupid enough to make it possible for the IFE and climate control stuff to talk to the actual driving controls, if for no other reason than because there's no sensible excuse for doing so. Boy, was I optimistic. Now I'm not, but I'm gladder than ever that my car was made in 1997.

Remote Exploitation of an Unaltered Passenger Vehicle Dr. Charlie Miller Chris Valasek August 10, 2015 http://illmatics.com/Remote%20Car%20Hacking.pdf

On page 53 of the "Adventures in Automotive Network and Control Units" paper there's a photo of what happened to the researchers garage after a command to run diagnostics on the brakes left the vehicle unable to stop even at slow speeds http://illmatics.com/car_hacking.pdf

Exactly! Because in the Jeep case there was an architectural failure where the attack surface (the radio controller) was connected directly to the vehicle control system via a CAN bus, speaking bare unauthenticated protocols that were designed before the idea of internet-accessible cars was conceived. So once your initial attack face was compromised, the game was up. This is the writeup if you want details, certainly I'm no expert on this particular hack: http://illmatics.com/Remote%20Car%20Hacking.pdf What I'm saying is that Tesla seems to have learned from that experience and gone with a very different architecture where vehicle commands simply aren't accessible to the public-facing computer, from which motor/brake/steering control systems only get general direction (e.g. waypoints). That's not saying it can't have a hole. But they don't seem to have made the kind of messup that would permit an attack like the Jeep hack.

You state in a different comment chain that bus segregation does not mean no communication, so I do not understand how that is consistent with your claim that they are isolated. The Jeep Cherokee also did not have only a single CAN bus as evidenced by the diagram on page 8 [1]. The problem was that the radio unit was on both CAN buses. I ask for justification of your statement because you counter-argued the previous comment that stated: “It really should be illegal to have network connected cars. Any software security engineer knows that.” by stating that the safety critical systems are segregated and thus “the network bus in which your 'compromised' infotainment system is able to operate is completely separate from Engine, ABS, AEB, ESP, Airbags etc.” which implies that solution achieves the desired security properties. I claim the desired security properties are: “safe enough to bet the lives of 471,000 people on them and take responsibility if they were wrong”. I think, and I think most people would agree, that is accurate assessment of the potential consequences of catastrophic failure. That is a consequence comparable to the detonation of a nuclear warhead in a city, so we should apply similar standards to the required level of security. Hardly any software engineer would make a claim that their software can be trusted with an amount of lives within 3 orders of magnitude of that number (note 3 orders of magnitude is 471 which is comparable to an airplane crash, so 3…

They're private subnets, right? From the paper:[0] > Looking at the network configuration of the Uconnect system we can see that it has several interfaces used for communications. It has an interface for the internal Wi-Fi communications, uap0, and another PPP interface, ppp0, presumably used to communicate with the outside world, via Sprint’s 3G services. # ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 pflog0: flags=100<PROMISC> mtu 33192 uap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 address: 30:14:4a:ee:a6:f8 media: <unknown type> autoselect inet 192.168.5.1 netmask 0xffffff00 broadcast 192.168.5.255 ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1472 inet 21.28.103.144 -> 68.28.89.85 netmask 0xff000000 > The 192.168.5.1 address is the address of the Uconnect system to any hosts connected to the Wi-Fi access point. The IP address 68.28.89.85 is the one that anyone on the Internet would see if the Uconnect system connected to them. However, port 6667 is not open at that address. The 21.28.103.144 address is the actual address of the interface of the Uconnect facing the Internet, but is only available internally to the Sprint network. > After a little experimentation, it was observed that the PPP interface’s IP address would change each time the car was restarted, but the address space always fell within two class-A…