Slashdot Mirror
Hackers Reveal Nasty New Car Attacks
schwit1 writes "Stomping on the brakes of a 3,500-pound Ford Escape that refuses to stop–or even slow down–produces a unique feeling of anxiety. In this case it also produces a deep groaning sound, like an angry water buffalo bellowing somewhere under the SUV's chassis. The more I pound the pedal, the louder the groan gets–along with the delighted cackling of the two hackers sitting behind me in the backseat. Luckily, all of this is happening at less than 5mph. So the Escape merely plows into a stand of 6-foot-high weeds growing in the abandoned parking lot of a South Bend, Ind. strip mall that Charlie Miller and Chris Valasek have chosen as the testing grounds for the day's experiments, a few of which are shown in the video below. (When Miller discovered the brake-disabling trick, he wasn't so lucky: The soccer-mom mobile barreled through his garage, crushing his lawn mower and inflicting $150 worth of damage to the rear wall.) The duo plans to release their findings and the attack software they developed at the hacker conference Defcon in Las Vegas next month–the better, they say, to help other researchers find and fix the auto industry's security problems before malicious hackers get under the hoods of unsuspecting drivers."
The mere fact that this has been announced has already started the wrong people working on it. At this point, releasing at Def-Con is the right thing to do, because not only will that patch get fixed, but others will come to similar conclusions and keep an eye out for peers who are going to exploit this. Black hats have family too.
Here's to hot beer, cold women, and Glaswegian kisses for all.
Right now they have to hook directly into the odb plug to do this, the same person with that kind of physical access can do any number of nasty things to your car.
They are more warning about the lack of security when this stuff becomes accessible remotely (cellular or otherwise wireless) that there are going to be serious security issues as anyone breaking into that remote access path can do serious things.
So
if I'm sitting in your car, plugged in to the canbus, I can control things on the canbus....
Yeppers....
Just like if I have access to your laptop for long enough, I can get whatever is on it. (encryption will slow it down, but like I said, given time and access?)
But you'll probably notice me sitting in your car, plugging a cord into the port before I take the time to crash your car, with me riding in it.....
While this is amusing, I'm not that nervous about "security through not having some donkey plug his laptop in your car with a death wish while you are hurtling down the highway"
Having them use the "open" canbus specs, you can add aftermarket devices, and not have to take your car to the dealer for any service.
If they fully lock it down, the dealer will be the ONLY place that could work on it. And the ONLY parts you could add to your car.
I am 31337 or something.
You mean like if there was some embedded computer plugged into the same CANbus as the OBD port, that had a cellular radio on it that was already shown to be vulnerable to attack? One sold on every new car from a certain major manufacturer?
Yeah, in the future, when OnStar exists, there will be serious issues. Wait, was "future" the right word?
The underlying problem is that CANbus was designed by automotive engineers and not network security people.
But the engine controller is going to have some form of authentication required and the hackers are going to be stopped right there.
Yes, I too had noticed that authentication systems were 100% proof against hackers, especially those implemented by companies that obviously have no prior interest in security.
Or a reporter (Michael Hastings) whose award winning work caused Stanley McChrystal's resignation mysteriously dying in a single car accident with a tree; without skid marks and the engine winding up 200 feet away...
And what cars are those?
Me, I stay safe and only drive cars with carburetors.
Until one of the hacked cars hits you head-on at 60 mph.
The underlying problem is that CANbus was designed by automotive engineers and not network security people.
A good point. Another way of phrasing the problem I think is:
Systems are too often specified, designed and tested entirely in terms of their positive capabilities, rather than their negative capabilities. In the networked remote security environment, we need a design process that guarantees both.
In other words, most of our design process up to now has been all about "what a system CAN DO". But securing a system from to intelligent attackers is about what that system CAN'T do, even in the worst case. And since the number of things a Turing-complete computer with an always-on connection to the Internet CAN buut SHOULDN'T do is potentially infinite, that can be really difficult.
Tests generally only cover the positive features. It's hard to achieve complete test coverage by trying every possible combination of bad input (though fuzzers seem to be doing quite well at finding vulnerabilities, and it's embarrassing that amateurs keep finding bugs that the professional developers didn't.) Typing seems to be more useful in limiting capability, but our current type systems are very limited - for example, in most OO languages, the type system only guarantees that the call signature of a method is correct; it doesn't give any way of describing any other invariants that should be preserved during the computation; and the entire architecture of OOP is based on methods with side-effects which scales really badly to concurrent processing.
I think we've reached the limit of what can be safely achieved with loosely-typed imperative side-effectful OO languages like C++. These languages give us enormous power to create positive capability, but very little in the way of assuring negative capability. I'd like to think that Haskell or Erlang might be a way forward, but I've yet to wrap my head around either of them. I'm hoping we can eventually get something simpler, that allows creativity where it's needed but also lets us place hard limits on what unexpected interactions can arise.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC