|
Can't wait to the color on this thing in real life. Hopefully I'll actually end up seeing it before it succumbs to your curse. 
|
#
¿
May 7, 2015 21:07
|
|
|
|
| # ¿ May 10, 2024 04:48 |
|
|
Das Volk posted:I took the car to a couple of track days, one at Sonoma where I don't know the line that well, and one at Laguna Seca, where I am a little more experienced. The car is loving fast, there's no way around that. But if you dare, get on the back of the 1290. The thing that's awesome about a car like the Viper is the grunt it has - a bike accelerates you faster, but the car pushes with an inertia and thrust. Bikes are like jumping to lightspeed, the Viper is like getting strapped to a Saturn V. Had a blast shooting around the track on a ride along though, totally awesome fun.
|
|
#
¿
Jun 30, 2015 21:21
|
|
|
Oh man an effort post about that stuff would be awesome.
|
|
#
¿
Jul 3, 2015 18:55
|
|
|
CAT INTERCEPTOR posted:Holy poo poo what are car makers thinking?!?!? Functionality and profit is far more important than an (until now) abstract threat. Even with the demonstrated threat, if it's not weaponized and scripted to the point that someone with minimal technical skill can perform the attack, it's highly difficult to actually perform these attacks. As this is a per car type attack, it's unlikely to be widespread - it has minimal value to common attackers such as government or criminal groups given the technical overhead for exploitation vs more traditional means of detaining/killing someone. Frankly, if someone is willing to kill you, there are many simpler ways than hacking your car. If it is trivially weaponized (download hackjeep app to sprint phone, kill people) well, that's going to be a very different problem. The sad reality is that a lack of technical expertise applied and lack of time spent on these sort of systems is really all that keeps you safe - obscurity is the protective factor, here, not proper system defensibility/etc. All of these sort of vulnerabilities are present in just about every piece of hardware and software you use, everywhere. If something is internet connected, it's highly likely it's remotely exploitable - developing secure things is possible but difficult, and more importantly, expensive. That car manufacturers haven't caught up to even the relatively poor current state of security shouldn't be a surprise, given that they have failed to create appropriate redundancy from basic hardware failure in their throttle by wire programming. We're creating security problems due to interconnected systems faster than we can fix them. It's gonna be a long, dark road ahead for at least a decade, probably more.
|
|
#
¿
Jul 21, 2015 23:02
|
|
|
kimbo305 posted:One more reason to never sign up for UCONNECT. Though if they can sniff you IP from any regular UCONNECT phone-home activity, it wouldn't help. Signup is probably irrelevant - it's almost always a flag that simply doesn't expose the functionality, rather than actually disabling the software/hardware communications, as they still want access to that sweet data and usage/travel characteristics, plus there's likely some waivers in there for law enforcement usage. So if you don't want this sort of thing in your car, do your research, and don't buy cars that have this kind of functionality.
|
|
#
¿
Jul 21, 2015 23:04
|
|
|
CAT INTERCEPTOR posted:I do have a slight clue about how many holes in software there are and how hard they are to protect - but the issue is the attack vector should never of loving happened in the first place and the ability to override steering and brakes likewise should not have existed. And actually it's very easy to defend against attack if you just simply don't have that ability in the first place If you can't override the driver's brake input, you can't have ABS - you can debate around if people actually need automatic lane change correction, self parking, etc, etc, but I'm pretty sure that stuff is here to stay and all of that requires the ability to over-ride the steering. Between that, ABS, and throttle by wire, any modern car has technology in the critical path for basically all components. The implication is there's some firmware over writing that needs to be done to disable safeguards, etc, but if they have a way to spoof the firmware update process, they own the hardware in the car and it's all over.
|
|
#
¿
Jul 22, 2015 04:25
|
|
|
CAT INTERCEPTOR posted:You most certainly can in older cars. And all that other poo poo should most certainly be able to be overridden or doesn't become active unless you press a button like self parking. Modern buttons are a courtesy notice to the computer that the user would like to do something. If the attacker controls the computer, it's over, no matter what. Given enough time, someone will find a hole in any system. You put in place hard segmentations you lose critical access to functionality that you may be required to maintain by law, or may want in order to establish the validity of warranty claims, offer GPS services, help roadside support/techs diagnose issues with the car, use to develop the software on the ECUs, fix bugs in software, etc, etc, etc. Not to mention they're probably developing this in a very distributed fashion - design of these systems is complicated and farmed out to many different groups, and there's little responsibility or security oversight on the large scale problems. Shared meta responsibilities like security are essentially impossible to implement without a business reason to drive towards it. Not to mention every developer of every component is going to say all the right words about how their systems/products are very secure and protected by industry standards. The problem is the industry standards are non-existent, and there is so much bullshit and so many little extra processors and 3rd party libraries and "disabled" functionality and potential vulnerabilities scattered around in every system that it's basically impossible to build secure devices right now because we have no secure foundation to build on. It's lovely, broken turtles all the way down, but no one cares and frankly, this likely won't change a drat thing. We are designing security flaws into our systems at a rate that exceeds our ability to fix them by an order of magnitude, if not multiple orders of magnitude, and very little is going to change that for at least a decade, probably more. Chrysler's line on this is going to be "we patched the problem, it's a non-issue" while pushing for the sort of regulations Powershift is talking about, and it's going to gently caress over home mechanics in the long run. Or they're going to have to start jailbreaking their cars to get them to work on generic parts, which is sort of the great long term irony and cycle of it - in the long run if things go the way auto makers want them to, guys like Charlie Miller are going to be the folks that let you actually work on the things that you own by continuing to defeat car security controls. Z3n fucked around with this message at 07:15 on Jul 22, 2015 |
|
#
¿
Jul 22, 2015 07:11
|
|
|
While you can absolutely design secondary networks, firewall, segment, etc, all of these things are still subject to the same core problem that we build these systems with stacks of code on code on code that no individual has evaluated or understands as a comprehensive whole. There are only a tiny minority of folks who could be reasonably trusted to write secure code, fewer who can securely architect systems in a way that meets business goals, and the number of those people who are not currently employed by the tech or gov sectors is basically zero - baseline salary for these people is in the hundreds of thousands of dollars plus likely millions in stock, and I don't think the auto industry is at the point where they're ready to pay that kind of money, nor would they see the value in it. Also, airlines have supposed network segmentation by design but that segmentation is poorly implemented and comes with a pile of other problems, like firewall issues and configuration problems that make them trivial to bypass. It's also a matter of power - your security people have to have the authority to push back release dates, be involved in seemingly trivial design decisions, enforce those decisions, validate that development has been done to spec, communicate the value of the work done to the executive tier, etc, etc. IMHO, this is a non-starter of a problem - the auto industry regularly deals with far worse repercussions for fuckups that involve people dying, that a select few could spend years developing a body of research to cause your car to shutdown is a trivial risk against the potential for someone to simply drive their car into a wall. We need some form of catastrophic tragedy as a result of our development practices before any things going to change - probably something that has a death toll in the thousands, and is a indicator of endemic failure in the way we interact with computers, not something that is the responsibility of a single company/government unit. Z3n fucked around with this message at 17:13 on Jul 22, 2015 |
|
#
¿
Jul 22, 2015 17:09
|
|
|
IOwnCalculus posted:So both have a CAN C and a CAN IHS, and it seems like most of the stuff that you'd be majorly worried about is on CAN C. In the Cherokee, the radio is connected to both C and IHS. In the Viper, it's connected to just IHS and the BCM is the only thing connected to both. (Both vehicles also have a 'LIN' that seems to be fully separated from everything else). So to do this attack on a Viper, you'd need to hack the radio, then use it to hack the BCM, and then you'd have full control. Whereas in the Cherokee, if you hack the radio, you can send commands directly to both busses. There's another layer of problems here, though, too - if the radio trusts an external source (like the update server, or remote customer service, dealership techs, etc), and fails to appropriately validate the identity of that external source, you can simply MITM those connections and access everything hrough the default administrative pathways. From there, it's a matter of attacking the configurations on the individual busses - but those busses were probably created with the expectations that the administrative pathways are trusted, so there's unlikely to be any controls preventing someone manually spoofing a command that tells the car it's actually moving at 3MPH and all wheels are locked up and it needs to fully engage the ABS systems now, meaning the driver has lost all braking force. Basically, if each component isn't individually responsible for validating input and output, and has no way of defending itself/failing securely or notifying anyone if something is happening, then eventually someone's gonna figure out how to wreck everything, due to the number of holes in the platform code, without even addressing the code that is custom to each vehicle. Without some form of logging and monitoring that someone can evaluate, you have no way of detecting attacks, and it's been well validated that any security controls or system is breakable given enough analysis, expertise, and time. Failing secure can also have really nasty consequences in a car platform as well - if the fly by wire is getting spoofed, is it acceptable to simply disable the throttle to prevent malicious inputs? What about if the computer can no longer detect if the wheels are sliding, is it better to disable the ABS system or let it engage? What if the computer doesn't even know it's not detecting actual wheelspeed anymore? It's a nasty, complex problem. The other issue is that doing all of that stuff also has a heavy influence on the development cycle without significant work - if your code is broken, is it because your code sucks or the security controls are preventing you from doing it? If the security controls are preventing you from doing it, are you violating the security guidelines or is it just that the security was implemented incorrectly? And then someone turns off the security controls for testing and development, the feature works, timelines get crunched, and turning the controls back on or testing them drops off the bottom of the task queue to meet the deadlines. And that's the story of literally everything developed ever, with a handful of exceptions that essentially prove the rule. Z3n fucked around with this message at 20:29 on Jul 22, 2015 |
|
#
¿
Jul 22, 2015 20:27
|
|
|
wolrah posted:Some of these things are simple to implement if someone bothers to rub a few brain cells together. One-way data links for example. Almost any type of network connection that supports broadcast traffic (or is always effectively broadcast as is the case in a lot of bus-type networks) can be made one-way by simply not hooking up the transmitter on the insecure end (or the receiver on the secure end, depending on which is easier). Ethernet, K-Bus, CAN, the principle works the same on all of them. You don't need rocket scientists, just an awareness of the problems and a bit of caution. This is really simple in concept but really difficult in execution. For example: How do you handle an attacker spoofing excessive legitimate traffic? 3mph is just as valid an input as 75mph, but in one situation it's going to kill you and in another it's completely harmless. Same with wheelspeed sensors. How do you fail when you detect malicious values? What is a malicious value, when, and how do you independently validate that when you can't establish trust in the system? What stops someone who has access on the bus from simply spoofing the address range? Basically, half the controls you talk about just involve knowledge of the design of the system to defeat, and the other half are vulnerable to basic attacks such as spoofing or flooding which lead to an attacker being able to introduce enough noise into the system to render good data lost in the noise, achieving their goals anyways. Part of the reason we're in this situation is because people think that the problems are "simple" without considering the massive stack of edge cases and problematic behaviors that are trivial for an attacker to perform and very difficult to defend against, because you have to have some form of validation that the traffic you're getting is actually legitimate, which involves not trusting your sensors without independent validation. The reference here is to aviation software design redundancy principals of multiple independently developed systems that require validation of error states from independent subsystems before they report errors. But that's incredibly expensive and totally unrealistic to expect in generic car design #901238. Here's the thing, if you're putting an internet connected radio and supporting computer in a car, it's going to be possible to own you through that thing, full stop, regardless of the design you have in place. The best you can hope for is to make it somewhat more difficult, and if I'm being completely honest, IMO, it's an acceptable level of risk for it to require 2 dedicated researchers 3+ months of time on this individual platform to develop functional exploits for it, especially considering they've been working on these problems for years. The number of platforms they can develop for is relatively limited and time consuming - this is far better than many industrial control systems we have currently connected to the internet right now. Most of that is due to relative obscurity of the platform design, requiring a bunch of reverse engineering work, but that's enough of a high bar to entry to keep it out of the realm of kids swatting someone, which is the current bar for people killing someone on the internet. Z3n fucked around with this message at 20:52 on Jul 22, 2015 |
|
#
¿
Jul 22, 2015 20:42
|
|
|
^^^ yeah this is quite relevant. CAT INTERCEPTOR posted:You can. Older ABS has error loops you can exploit depending on the ABS supplier- there's nothing particularly smart nor complete always overriding about older separate ABS controllers - And I'm not just talking about pulling the ABS fuse either. The issue is with the newer ones that interconnect with traction control and stability systems or more. You're looking at this from the wrong perspective. The attackers are doing exactly what you're talking about here - they're overriding the ABS controller to essentially engage it at full "antilock" capability, robbing the driver of the ability to use the brakes maliciously, rather than doing what ABS normally does which is stops the driver from using the brakes when they overdo it. They're just moving the needle on "overdoing it" to a place where the brakes stop working entirely. The system can't be separated because they're tied into the core of the car itself - proper antilock activation, speed dependent lockup prevention, safety checks, etc, is essential to the car meeting government standards for safety, and adding more systems to replicate that sort of functionality is adding significant additional complexity, reducing reliability and increasing the chances of a failure. Do you really want to have to maintain 3 individual but identical wheelspeed sensors, for your gauges, your ABS, and your traction control system because you're trying to isolate individual systems? Oh, and you're also going to need 2 pumps now too, because your ABS pump and your TC brake application pumps can't be shared. Down this pathway lies madness. quote:Dont put the access in there in the first place. There, done. And if you want a system that has wireless, air gap it from the other car subsystems. Frankly all the subsystems need is a power signal to come on and the main system can do that quite well without resorting to ridiculous levels of network interconnect. Obvious, easy, cheap, secure. This is an exceptionally simplistic view that doesn't hold up to any sort of reasonable scrutiny or real world application, such as testing for failed subsystems, maintaining a reasonable number of sensors, meeting automotive standards for design, etc. etc. etc. And a system that is wireless that is airgapped from all other car subsystems is pointless - the whole reason is to allow legitimate remote access to help drivers with emergency services, monitor car trouble, update firmware, etc. The attitude of "disable functionality until it's secure" is one that the security community has harped on about for years unsuccessfully, because it's standing in the way of progress rather than figuring out how to progress with a reasonable approach to the risks. The reality is that perfect security is impossible, attempting to achieve perfect security gets you useless software and hardware, and you need to balance the risks against the rewards. In this case, exploitation is difficult, requires a high degree of technical skill, and is not broadly applicable across individual platforms without specialized work, and that means the risks are relatively minimal. It's something automakers should fix or make more difficult, but it's also something that's will kill fewer people than have died from normal auto accidents in the amount of time it takes us to write these posts over the next 10 years. This is really not a big deal overall, it's just a symptom of a continued, worrying trend, that's likely to get a bunch of hamfisted regulations slammed down our throats that are going to damage legitimate security work far more than help us fix these issues. The field of offensive vs. defensive security at the moment is essentially laser guided missiles against forts with wooden walls. If you're willing to expend enough resources, you can build a fort that will stand up to a lot of missiles, but ultimately, the defenders operate at a huge handicap by default. Part of the problem is people thinking that less functionality is a realistic fix in a world that demands more functionality. Z3n fucked around with this message at 03:53 on Jul 23, 2015 |
|
#
¿
Jul 23, 2015 03:47
|
|
|
kastein posted:e: it might be time to make a "car electrical engineer nerd blather thread" instead of derailing this one and the terrible car poo poo thread, I guess. I have been meaning to do a big effortpost about how to do a quality job wiring a vehicle, too, but haven't gotten around to it yet. I would really enjoy reading this - both the nerd blather and the effortpost about proper wiring, as it's relevant to a lot of the bike work I do. And then Das Volk can have his thread about lucky #13 back. Alman posted:*a good post* Interesting, thanks for sharing 
Z3n fucked around with this message at 23:39 on Jul 23, 2015 |
|
#
¿
Jul 23, 2015 23:33
|
|
|
Liquid Communism posted:First rule of network security. Packets can't cross a proper air gap. Anything that can potentially cause the car to crash remotely needs to be completely physically separate from any remotely accessible electronics. That's just common sense security. As Mencken said, for every complex problem there is an answer that is clear, simple, and wrong, and security is sadly a lot of people failing to consider the complexity of development and functionality requirements and reducing things to the simple and wrong answer. These vulnerabilities will always be present, the trick is to not leave the front door open and aggressively validate the design requirements against the security risks in a way that is meaningful to those who make the decisions: Management. If you come to them with "We need to airgap ABS systems", then you better also have an answer about how the ABS system is going to communicate to the gauges, how that's not equally insecure, how this is going to fit into the manufacturing processes, and how you're going to address the automotive regulations that apply to that system, etc, etc. And if you do manage to convince them, you better also be able to justify why you're choosing to airgap ABS in relationship to the self parking motors, and the fly by wire throttle, or someone smart is going to look at what you've said and take you to the table on not mitigating those other "significant risks", based on the security concerns you had brought to the table. In terms of actually fixing the problems? Well, step one is getting to the point where there are meaningful security guidelines for all developers, and step two is validating that you're meeting those standards in development, testing, production, and final delivery. At the very least, for every car released there should be network testing checklist along with engine testing and everything else that validates that the network connections are properly specced, listening on the appropriate ports, and validating certificates for updates/etc as required. At the very least, a late stage check like that would have caught the initial vuln that made this so compelling. Without the wow factor of "scan for car, hack it remotely", this aligns right on back down to someone hacking your car by plugging a bunch of bullshit into it, which is basically on par with someone jamming some cheap explosives in it or creatively disabling some component that causes an accident, and is an acceptable risk to folks that drive cars already implicitly.
|
|
#
¿
Jul 24, 2015 04:37
|
|
|
Galler posted:Went to the BlackHat talk on that today. It was pretty interesting. No where near enough time to go into a lot of detail, but the white paper (90+ pages) will be released on Monday for those that want all the details. Really the thing that's most interesting about the exploit was the remote accessibility, as the threat of an attacker plugging into your car and doing something that causes it to crash is the same threat that's been accepted around cars since we started with the drat things. The remote stuff is easily fixed by a proper post car manufacturing QA process. Along with dyno testing and other QC/QA functionality, there should be a scan/fuzzing the car's networking equipment/IP/etc for flaws. At least at that point you can demonstrate due diligence on externally accessible interfaces, and you can catch failures by 3rd parties to meet your security requirements, which is likely what happened here - no one expected someone to come in on that vector, but no one validated that that was the case either.
|
|
#
¿
Aug 6, 2015 17:22
|
|
|
|
| # ¿ May 10, 2024 04:48 |
|
|
Yup - that's exactly it.
|
|
#
¿
Aug 22, 2015 00:31
|
|