|
Well, that depends. Clearly somehow Chrysler set it up so that can be changed, so "hardwired" may not mean what you think it does in this case. I'd have to look at the wiring diagrams to tell you for sure, but basically, the intent of the design was to have the computers be able to control the steering in reverse so the parking assist can do its thing. If it's physically impossible for it to control the steering in forward gear good on them, that's the kind of hardwired safety interlock I love to see, though they obviously should have had one for engaging the park assist as well. CommieGIR posted:I feel like something like this needs two factor authentication and a basic firewall with privileges given to the driver. Say the company wants to connect to the vehicle, they should be required to call the user and the user should be able to randomly generate a pin that the user themselves must give to the company to allow them to connect, barring that a firewall with a randomly generated pass code that is given to the driver at purchase and the driver can change at will. That's cool and all but that all gets implemented in firmware too. So that presents its own attack surface which must be validated and tested too. In fact the bug that allowed this, from the sound of the article, is likely in the authentication code that allows the connection in the first place. e: Galler posted:Neat, they are supposed to be at DEF Con this year. Maybe I'll go to that talk. kastein fucked around with this message at 16:37 on Jul 21, 2015 |
#
?
Jul 21, 2015 16:33
|
|
|
|
| # ? May 13, 2024 20:48 |
|
|
CommieGIR posted:I feel like something like this needs two factor authentication and a basic firewall with privileges given to the driver. Say the company wants to connect to the vehicle, they should be required to call the user and the user should be able to randomly generate a pin that the user themselves must give to the company to allow them to connect, barring that a firewall with a randomly generated pass code that is given to the driver at purchase and the driver can change at will. But that's just one attack vector, and it barely begins to deal with the problem. The entire infrastructure inside the cars being sold today is vulnerable, there's a dozen computers stashed away in the body and they all communicate to each other with zero data validation. Attacking over wireless is certainly extremely serious because it's the easiest way to get in, but anyone with physical access could perform the exact same attacks.
|
|
#
?
Jul 21, 2015 16:35
|
|
|
i have a few friends that work for one of the companies that chrysler contracts for a lot of the entertainment systems and software stuff and they are all freaking out right now lol
|
|
#
?
Jul 21, 2015 16:36
|
|
|
xzzy posted:But that's just one attack vector, and it barely begins to deal with the problem. The entire infrastructure inside the cars being sold today is vulnerable, there's a dozen computers stashed away in the body and they all communicate to each other with zero data validation. Well, technically anyone with physical access could simply cut the brakes or sabotage the engine. You will never totally stop intrusion, only deter it or make it too difficult/time consuming to be an attractive route. But yeah, that's really creepy. No data validation whatsoever? What the hell?
|
|
#
?
Jul 21, 2015 16:42
|
|
|
CommieGIR posted:Well, technically anyone with physical access could simply cut the brakes or sabotage the engine. You will never totally stop intrusion, only deter it or make it too difficult/time consuming to be an attractive route. No data validation from computer to computer inside the car, any more than you use authentication on a serial port connecting a GPS receiver to your laptop. The connection out to the rest of the world drat well better have some, but apparently it had a vulnerability in it 
|
|
#
?
Jul 21, 2015 16:47
|
|
|
CommieGIR posted:I feel like something like this needs two factor authentication and a basic firewall with privileges given to the driver. Say the company wants to connect to the vehicle, they should be required to call the user and the user should be able to randomly generate a pin that the user themselves must give to the company to allow them to connect, barring that a firewall with a randomly generated pass code that is given to the driver at purchase and the driver can change at will. Uhhhhhh vehicle manufacturers have, for the most part, been pushing legislation that says car software being looked at or modified by anyone other than the manufacturer is illegal. I highly doubt anything short of major reactive legislation would get them to lock themselves out of their products.
|
|
#
?
Jul 21, 2015 16:47
|
|
|
CommieGIR posted:Well, technically anyone with physical access could simply cut the brakes or sabotage the engine. You will never totally stop intrusion, only deter it or make it too difficult/time consuming to be an attractive route. Seems like cutting a brake line would result in brake failure quite soon after it happens, and I can't think of any way to sabotage an engine that would make it only kick in later down the road instead of making it obviously down on power right away. I mean if your car starts up and isn't running on all cylinders, you probably aren't going to head onto the freeway like nothing is happening. A hack like this allows you to go get into a situation you wouldn't normally get into in a normally functioning car (i.e. driving 70mph in crowded traffic) and then disable critical systems. My knowledge of CAN is not as strong as I'd like, but isn't it just a single-wire communication protocol in most vehicles? Seems like it'd be fairly easy to design some sort of battery-powered box that just taps a CAN wire and instantly gets access to everything. Put in a modem to run remote controls, or a GPS receiver that kicks in over a certain speed and then execute commands to gently caress someone's day in a bad way. Sigma X posted:Uhhhhhh vehicle manufacturers have, for the most part, been pushing legislation that says car software being looked at or modified by anyone other than the manufacturer is illegal. I highly doubt anything short of major reactive legislation would get them to lock themselves out of their products. And all that's going to do is make detecting vulnerabilities like this harder for people who aren't trying to exploit things for ill-gotten gains.
|
|
#
?
Jul 21, 2015 16:47
|
|
|
Well it looks like I'm gonna keep my '96 Camry running as long as possible Holy Christ what a cluster gently caress.
|
|
#
?
Jul 21, 2015 16:48
|
|
|
Sigma X posted:Uhhhhhh vehicle manufacturers have, for the most part, been pushing legislation that says car software being looked at or modified by anyone other than the manufacturer is illegal. I highly doubt anything short of major reactive legislation would get them to lock themselves out of their products. Oh, I know. I've ran into this before when trying to get information on a specific ECU. kastein posted:No data validation from computer to computer inside the car, any more than you use authentication on a serial port connecting a GPS receiver to your laptop. The connection out to the rest of the world drat well better have some, but apparently it had a vulnerability in it I still don't understand how they just seem to maintain an open connection to the vehicle computer without some thoroughly strong encryption or security.
|
|
#
?
Jul 21, 2015 16:54
|
|
|
xzzy posted:But that's just one attack vector, and it barely begins to deal with the problem. The entire infrastructure inside the cars being sold today is vulnerable, there's a dozen computers stashed away in the body and they all communicate to each other with zero data validation. Here's how I'd do it. Have an onboard file server where software/firmware updates can be staged wirelessly. Only allow the file server to access the secure network if certain conditions are met (vehicle off, in park, etc., maybe even location specific). To actually update the files, a technician has to either connect a secured laptop through a wired connection, or wirelessly (which would require entering a dealer controlled code on the dashboard, or some auxiliary panel to compete the handshaking) and select which files they want to update from those stored on the file server. If the application or hardware being updated doesn't like the look of the file - ie certain digital signature are missing or invalid, it won't allow the update to take place.
|
|
#
?
Jul 21, 2015 16:54
|
|
|
Linedance posted:Here's how I'd do it. Have an onboard file server where software/firmware updates can be staged wirelessly. Only allow the file server to access the secure network if certain conditions are met (vehicle off, in park, etc., maybe even location specific). To actually update the files, a technician has to either connect a secured laptop through a wired connection, or wirelessly (which would require entering a dealer controlled code on the dashboard, or some auxiliary panel to compete the handshaking) and select which files they want to update from those stored on the file server. If the application or hardware being updated doesn't like the look of the file - ie certain digital signature are missing or invalid, it won't allow the update to take place. Sort of like a short range wireless system, you have to be within a certain distance and able to physically access the car. I mean, you can fake most of the digital signatures no doubt, but they need to require the car to be closer. I don't understand the need to have long distance communication with the vehicle computer.
|
|
#
?
Jul 21, 2015 16:56
|
|
|
CommieGIR posted:Well, technically anyone with physical access could simply cut the brakes or sabotage the engine. You will never totally stop intrusion, only deter it or make it too difficult/time consuming to be an attractive route. A fun read. http://arstechnica.com/security/2013/07/disabling-a-cars-brakes-and-speed-by-hacking-its-computers-a-new-how-to/ Video link to demonstration is in there too.
|
|
#
?
Jul 21, 2015 16:58
|
|
|
Galler posted:Neat, they are supposed to be at DEF Con this year. Maybe I'll go to that talk. According to the article they're presenting at black hat, the week before defcon where all the actual interesting stuff gets presented (if you can afford the registration fee) Defcon remains a venue for utilikilts and cyberpunk cosplay. (I may go to Defcon this year anyway)
|
|
#
?
Jul 21, 2015 17:07
|
|
|
There's a lot of confusion and misunderstanding involved in you guys suggestions, but it's a good start.IOwnCalculus posted:My knowledge of CAN is not as strong as I'd like, but isn't it just a single-wire communication protocol in most vehicles? Seems like it'd be fairly easy to design some sort of battery-powered box that just taps a CAN wire and instantly gets access to everything. Put in a modem to run remote controls, or a GPS receiver that kicks in over a certain speed and then execute commands to gently caress someone's day in a bad way. There is a single-wire CAN, but most automakers implement double-wire. All the two wire type gives you is better electrical noise immunity and throughput. Basically, here's how CAN bus works. You assign each "message" a priority (which is a number from 0 to 2047 or 0 to 536870911, depending on if you use 11 or 29 bit CAN) - lower numbers are higher priority. So for example (this is a real example, BTW) message AIRBAG_WLAMP (airbag warning lamp) is message-ID/"priority" 0x12, which is 18. Very, very high priority to tell the driver that the ACU has reported a system fault. A "message" contains anywhere from 0 to 8 bytes of data, which is in a format decided by the automaker. The format is different for each kind of message, or can be - you use the message-ID (which is the priority of the message) to determine what format the data will be in. For example, AIRBAG_WL has a DLC (Data Length Code) of 8, meaning it contains 8 bytes of data. Only bit 3 of byte 0 is defined, it's a 0 or a 1 that indicates whether the airbag warning lamp should be turned on in the instrument panel. This message is transmitted every 100mS by the ACU in many VAG products. The clever part of how this all works is that because of how the bus data protocol works, any computer on the bus can transmit. HOWEVER, per the spec (ISO 11898, if you wish to read it yourself) only one specific computer is allowed to transmit a given message-ID/priority of message, for example only the ACU can transmit AIRBAG_WLAMP while only the instrument panel can transmit MAIN_CLUSTER (message-ID 0xC, or 12.) When you transmit, you watch the value that's on the bus. A 0 overrides a 1 because of how it's wired, and the ID is transmitted least significant digit first, so the sender who is sending a lower number (higher priority) sees the same data they are transmitting, while the one transmitting a higher number (lower priority) sees different data from what they sent and immediately stops talking. It's very clever, and all hinges on only one control module being able to transmit a specific kind of message. The whole point is that if something's wired to the bus it can probably be trusted though. That's fine, if someone cares enough to design a malicious CAN bus controller and figure out what make/model/year you have and tailor it specifically to kill you via your car, they probably could have killed you in any number of other ways too. I don't worry about that, personally. What I do worry about is when some idiot decides the entertainment system should be on the same CAN bus (because that way we can auto disable it when you aren't in park, oh, and we can have the firmware updatable over the air and also send you advertising for maintenance services every x miles if we decide to later!!!) and leaves a hole in its security that allows its firmware to be hacked. Once that firmware is hacked, you now essentially have a computer the hacker controls hardwired to the CAN bus and who knows, they can break the protocol and send any message-ID they want even if they weren't supposed to. Some of those are going to be stuff that can either command or mislead all the vehicle control systems into doing anything they are physically capable of doing within the limits of their hardwired safety limits. The problem with this is it being possible over the air, remotely, by anyone who downloads the right tools, not "CAN bus is insecure and can be hacked if you're physically connected to it" IMO. Yeah, it is - physical access trumps all. That is not going to change. Security lies in preventing physical access. What is important here is that once the attacker controls any computer on that network wirelessly, they have physical access no matter where they are, basically. kastein fucked around with this message at 17:11 on Jul 21, 2015 |
|
#
?
Jul 21, 2015 17:08
|
|
|
kastein posted:There's a lot of confusion and misunderstanding involved in you guys suggestions, but it's a good start. I'm used to debugging 1553 bus code, which is just CAN for airplanes really.
|
|
#
?
Jul 21, 2015 17:13
|
|
|
Last I read about hacking cars was some attempts to wirelessly hack into ford sync stuff a few years back. As I recall their poo poo was pretty locked down. I want to say there was no physical connection between the infotainment system and the rest of the cars computers. But I'm probably wrong. Might just have been a solid firewall. Huge grain of salt, I'm a mech e. Not a double e or soft wear guy.
|
|
#
?
Jul 21, 2015 18:43
|
|
|
I am also in the business of designing, writing, programming and testing engine controllers for consumer and commercial vehicles and I can't think of too many (any) reasons why an infotainment system needs to be on the Vehicle CAN bus. As mentioned before, OTA ECU updates would be nice but we clearly can't have things.
|
|
#
?
Jul 21, 2015 19:20
|
|
|
I'd be 100% alright with keeping two separate CAN buses, with them joined by a one way bridge so the infotainment system can do stuff like display the power output on the head unit (example: Viper) or report DTCs to OnStar, but infotainment messageIDs leaking onto the powertrain/vehicle control bus does not fly with me, not without a solid firewall type setup in place as I described before. It wouldn't even be hard to implement a one-way type setup... dirt simple microcontroller w/ two CAN controllers, one CAN transceiver (the one I like is the Microchip MCP2651FD, though the Atmel ATA6660 is a pretty solid buy too) on each side, then just don't even wire the TXCAN pin on the powertrain side. The "bridge" microcontroller wouldn't be able to ack any messages, but it shouldn't need to since they're all going somewhere in the powertrain bus anyways and will be acked by someone else, so it can just listen in and chat with the infotainment bus on the other side as it sees fit. I really don't care if your latest and greatest infotainment center gets hacked so long as it can be covered under warranty and doesn't have repercussions up to and including operator (or innocent bystander) death and dismemberment. And yeah, I would love to see OTA updates... because who the hell updates their firmware on a car? Approximately no one. But we can't have nice things like you said. kastein fucked around with this message at 19:33 on Jul 21, 2015 |
|
#
?
Jul 21, 2015 19:31
|
|
|
There are some legitimately very useful things which the head unit needs info about car operations for; speed sensitive volume control, triggering a switchover to display backup or lane assist cameras, showing vehicle status, etc. But I can't think of any reason why you'd need bidirectional communication.kastein posted:And yeah, I would love to see OTA updates... because who the hell updates their firmware on a car? Approximately no one. But we can't have nice things like you said. What worries me about the USB update method they are using is that it presents a real security danger as well. Vehicle ownership records are generally attainable as public records (which is how you get those drat "your warranty has expired!" letters). It would be pretty trivial to send out a bunch of USB sticks loaded with hacked firmware along with an official-looking letter telling people how to update their vehicle's firmware.
|
|
#
?
Jul 21, 2015 19:44
|
|
|
Whoever does that and sends out a few tens of thousands of fake update sticks that rewrite the firmware to just play Never Gonna Give You Up on the display/speakers nonstop will be my loving hero forever.
|
|
#
?
Jul 21, 2015 19:47
|
|
|
Shifty Pony posted:There are some legitimately very useful things which the head unit needs info about car operations for; speed sensitive volume control, triggering a switchover to display backup or lane assist cameras, showing vehicle status, etc. But I can't think of any reason why you'd need bidirectional communication. Other reasons would include stuff like the new DCC (driver comfort control), Race mode, etc etc that you adjust using the nav unit. We're all gonna die sooner or later, at least maybe you'll get a thrilling 100+ mph adventure out of it when it happens. I'm fully convinced that the first time I get my 58 back on the road I'm going to get murdered by some idiot in a 6000 pound truck or suv not paying attention.
|
|
#
?
Jul 21, 2015 19:50
|
|
|
kastein posted:And yeah, I would love to see OTA updates... because who the hell updates their firmware on a car? Approximately no one. But we can't have nice things like you said. Why would they want to update stuff anyway since it just means they can sell the fixes as features on the next model year. Ford Taurus 2016 - now with less hackable death exploits
|
|
#
?
Jul 21, 2015 19:51
|
|
|
kastein posted:Whoever does that and sends out a few tens of thousands of fake update sticks that rewrite the firmware to just play Never Gonna Give You Up on the display/speakers nonstop will be my loving hero forever. A nationwide rickrolling was one of the first things I thought of when I read that wired article. Image every late model Chrysler product in the US all rolling down their windows and blasting Never Gonna Give You Up.
|
|
#
?
Jul 21, 2015 19:53
|
|
|
atothesquiz posted:As mentioned before, OTA ECU updates would be nice but we clearly can't have things. kastein posted:And yeah, I would love to see OTA updates... because who the hell updates their firmware on a car? Approximately no one. But we can't have nice things like you said.
|
|
#
?
Jul 21, 2015 20:03
|
|
|
Shifty Pony posted:A nationwide rickrolling was one of the first things I thought of when I read that wired article. Image every late model Chrysler product in the US all rolling down their windows and blasting Never Gonna Give You Up. You mean rolling up the windows almost all the way and locking the doors.
|
|
#
?
Jul 21, 2015 20:29
|
|
|
Roll all the windows up, set blower on full, set heat to max and lock the doors. You are welcome terrorists.
|
|
#
?
Jul 21, 2015 20:30
|
|
|
Pham Nuwen posted:According to the article they're presenting at black hat, the week before defcon where all the actual interesting stuff gets presented (if you can afford the registration fee) Yeah, I think the article is wrong. Their names are on the Defcon page and the topic is much more defcony. I'll be at BlackHat
|
|
#
?
Jul 21, 2015 20:32
|
|
|
BlackMK4 posted:Teslas do this. That's what I meant, I know it exists but should probably be done away with. I guess I should have phrased it "OTA ECU updates would be great but we clearly can't protect our cars properly so we should stick with flashing the controllers the old fashioned way."
|
|
#
?
Jul 21, 2015 20:41
|
|
|
I thought Tesla was really proactive on exploit hunting?
|
|
#
?
Jul 21, 2015 20:53
|
|
|
Humbug Scoolbus posted:I thought Tesla was really proactive on exploit hunting? Sure, I believe they held some competition for hacking their car too (remote or or within the car, I don't remember). However it's a lot harder to hack or maliciously modify a vehicle when the remote avenue does not even exist.
|
|
#
?
Jul 21, 2015 21:00
|
|
|
So I guess this justifies my plan to hoard as many 90's Japanese vehicles as possible.
|
|
#
?
Jul 21, 2015 23:15
|
|
|
Worked with ECUs before for system implementation and this doesn't surprise me at all. Hopefully they can take the chance to stop using CAN and use something that can handle more data. Also separation of systems with some hardware encoding bridge to exchange data. Infotainment doesn't need to be connected to vital systems.
|
|
#
?
Jul 22, 2015 00:21
|
|
|
Uncle Jam posted:Worked with ECUs before for system implementation and this doesn't surprise me at all. Hopefully they can take the chance to stop using CAN and use something that can handle more data. Uncle Jam posted:Also separation of systems with some hardware encoding bridge to exchange data. Infotainment doesn't need to be connected to vital systems.
|
|
#
?
Jul 22, 2015 00:33
|
|
|
What is the "official" purpose for the long-range wireless capability? Is it OnStar type poo poo, a backdoor for law enforcement to shut you down if the car gets stolen or you're being bad, or something more benign like serving advertisements for nearby gas stations / restaurant chains who've paid into that particular flavor of infotainment system? Or something else? I guess what I'm getting at is (and someone correct me if this is too simplistic), is there any reason why someone who doesn't care about this poo poo can't just find out where the receiving antenna is (or the module that contains it) and unplug it, eliminating all possibility of someone taking control of the car this way? Something like the car freaking out and shutting down, or important systems not working if it detects that the wireless link to the mothership is down? I'm afraid I don't know much about this type of system - you can pry the keys to my dumb OBD1, cable throttle V8 car out of my cold dead hands, thanks. Black88GTA fucked around with this message at 00:43 on Jul 22, 2015 |
|
#
?
Jul 22, 2015 00:41
|
|
|
Slavvy posted:So I guess this justifies my plan to hoard as many 90's Japanese vehicles as possible. All very well and good until some out of control Grand Cherokee absolutely crushes your AE100 Corolla. Just by virtue of us all using the same roads it affects everyone so I don't feel too smug about my seven year old Mazda which doesn't have any type of wireless connection to anything.
|
|
#
?
Jul 22, 2015 00:47
|
|
|
Shifty Pony posted:There are some legitimately very useful things which the head unit needs info about car operations for; speed sensitive volume control, triggering a switchover to display backup or lane assist cameras, showing vehicle status, etc. But I can't think of any reason why you'd need bidirectional communication. Don't forget about AI's favorite mobile electronics trick, fake engine noise!
|
|
#
?
Jul 22, 2015 00:50
|
|
|
BigPaddy posted:Roll all the windows up, set blower on full, set heat to max and lock the doors. You are welcome terrorists. My Dad's Chrysler does this without any hacking at all
|
|
#
?
Jul 22, 2015 06:45
|
|
|
kastein posted:This won't improve matters at all security wise but would be helpful. Why let a good crisis go to waste? It's just good practice to separate management networks from production networks. Somebody with a $250 Security+ cert could have told them that.
|
|
#
?
Jul 22, 2015 06:56
|
|
|
BigPaddy posted:Roll all the windows up, set blower on full, set heat to max and lock the doors. You are welcome terrorists. I would say any chrysler where the windows roll all the way up, blower motor works and blend door gives you a choice is still well ahead of the pack.
|
|
#
?
Jul 22, 2015 07:00
|
|
|
|
| # ? May 13, 2024 20:48 |
|
|
8ender posted:My Dad's Chrysler does this without any hacking at all Feature, not a bug.
|
|
#
?
Jul 22, 2015 07:06
|
|