Hacker shows he can locate, unlock and remote start GM vehicles
computerworld.com
computerworld.com
Thank you for being a loyal OnStar customer. We're happy to have you as part
of the OnStar family and appreciate the confidence you have in us.
We are writing to inform you that we have recently made a security update to
your OnStar RemoteLink mobile app. As a result, the current version of the
app you have on your Apple device will no longer be functional and you
will need to update to the most recent version.
Click here to download the Remote Link app.
We hope that you will continue to use OnStar services and experience all
that OnStar has to offer. OnStar advisors are ready and available 24/7
to assist you.
Sincerely,
Onstar
Terry M. Inch
OnStar, Chief Operating OfficerThere is the acceleration module, then there is a wireless networking me dule, and there is a physical wire connecting them.
Very shitty, very dangerous design.
And then you add a radio, and a knob under the steering wheel to control it, and think - hey, I have this handy bus I can reuse so that they talk with each other. And suddenly, your radio talks to your brakes.
I don't think it's malicious design. More likely stupid one, or just a result of people being used to treating car hardware as trusted environment - where obsessing over security is just a waste of resources. It's just that when you introduce an Internet-connected device to that environment, it's not trusted anymore.
The issue is that frequently systems like OnStar sit on both buses, because they are used for things like engine diagnostics. If you investigate you'll notice that every single one of these car hacking attacks starts somewhere, pivots to an OnStar like system, then can control the car.
Doesn't really make your point less true, but fits perfectly in the features over security mindset.
Don't contribute to malice what could be explained by stupidity. Don't contribute to stupidity what could be explained by greed.
ECU's have no business being integrated into infotainment systems. It's fine to have a physical wire that can be connected for diagnostics, but don't have then permanently connected by default. Just don't.
edit: just read the article (doh for commenting before reading) and this attack is different from the previous ones. This one uses a feature that was built into the cars purposely for unlocking the vehicle and controlling the engine. That feature seems monumentally dumb from the outset - and very much implemented by design.
- Murder for hire. - Killing political opponents. - Another country could use it to kill our leaders.
I'm looking forward to self-driving cards but my only real fear is a bug being used to kill people in the manner I just described.
Even if the hardware is secure against a script kiddie hacker, it'll never be secure against a government backdoor.
Imagine the power that someone like Nixon would have as president today. It's scary.
"When the president does something, that means that it is not illegal" https://www.youtube.com/watch?v=tYdJqSG3K6c
There's such an obvious way to make money on them I'm surprised it isn't happening yet - if you have a zero-day for a car, just make a deal with your lawyer friend, that you'll crash some poor schmuck's car and your friend will help the victim sue car manufacturer for $shitton, which you'll split between the two of you.
I'm sure plenty of international "agencies" would pay very good money to be able to exploit these bugs. Gotta take out somebody driving a GM car? No sweat!
Maybe because even the Government didn't think anyone was so stupid?
a lot. You can start by looking up if any of these old timers raised anything remotely similar to that concern. Remember how insanely unprotected the Internet was in the beginning? How SMTP basically still is? That was build by some of the smartest people in the world, and they didn't have the foresight to predict that there might be adversaries, and thus build (in retrospect, quite simple) protections in.
Also, those old timers were wrong about drive by wire, there is zero evidence that it's any less safe than physical linkages.
One of the reasons it would have been extremely difficult to predict, is that the phenomenon of consumer devices having a general purpose computer (and that this might be connected to the rest of the car), much less one networked in any sense, as its interface is pretty new.
[edit: added analogy to the internet]
I guarantee you that engineers warned PM's about this kind of thing from the start.
>Also, those old timers were wrong about drive by wire, there is zero evidence that it's any less safe than physical linkages.
Let's distinguish drive-by-wire from FADEC (or what amounts to a poor-version of FADEC). An electronic throttle is fine. An electronic throttle that cannot be overridden by a casual user not. It's the implementation that's problematic.
What would they define 'other systems' as? Back then carphones were pretty new, and the height of technology, and a car 'computer' was a trip mileage counter and mpg calculator. Amy definition would either be rooted in the technology of the time, and therefore not handle new breakthroughs and inventions, or be so vague as to be unenforceable, I suspect. They would have to be pretty far forward thinking to have envisaged high bandwidth Internet connections or wireless data links, as inputs to the car systems, let alone the amount of compute power that is now routine in vehicles.
The sorts of things that are going to enforce safety here are going to be produced by the car industry engineering standards bodies eventually, but it will take time. Many of the concepts, like CAN-bus firewalls, data diodes and filters are already present in high-assurance avionics networks and (post STUXNET) in process control systems. Note that it took STUXNET for people to realise that vulnerability, now the industry is working on solutions, but so far no power stations or chemical plants have exploded. We are in the same place with vehicle security now.
And who checks these people's work? How do we make sure they don't risk outlawing ABS and ESP before they're invented?
For a relevant case study, compare and contrast with how heavy regulation, also plenty of forward-looking stuff, totally failed to predict or prevent the financial crash.
The, there's the issue of how the industry would actually adhere to these speculative regulations. You'd have plausibly millions of pages of regulation to evaluate every new development against. In practise, this means the lawyers are running the show. Just like in the banks.
Also, before your righteous anger gets the better of you, let's remember that nobody has actually been hurt due to these problems yet, except of course the manufacturer who must issue extreme expensive recalls. In the meantime, Toyota built cars with a gas pedal that stuck - this issue actually killed people. It was a purely mechanical problem - would these hypothetical forward-looking regulators have caught that issue?
Finally, I'm not one to throw around words like "communism" where they don't apply, and communists certainly didn't and don't care one bit for consumer safety or comfort - but severe overconfidence in the ability of government to plan, predict and prevent things is a central problem with communism.
I won't even bother to fight your strawmen (the financial crash could not be helped by better laws, really?), tbh it's just boring. You are right, why have laws at all? Car manufacturers are so enlightened, they obviously work for the greater good rather than simple profit, I apologize for my stupid remark.
Have a good day.
Not sprayed with gratuitous ad-hominems, not really.
> bringing up how forward-looking government regulation failed in other cases is pretty relevant.
I struggled to consider it relevant, considering how it's widely accepted that reduction in regulation is one of the main causes of the recent financial crash. Forward-looking regulation was there and was removed. I think that particular example doesn't make the point he thinks it makes.
> And never was the idea mentioned that these things should not be governed at all
It was basically inferred. If you take his points to the logical conclusions, there is no point in regulating the car industry, they hire the best minds so they will know what to do.
> "Good" advancements can be just as restricted as "bad" advancements
Of course; but it's extremely difficult to prove whether the advantages of outlawing both outweigh the advantages of allowing both. So we came up with this rule that "we legislate only after shit happens". Is it crazy to think this arrangement could be sub-optimal, and there might be a better compromise?
It wasn't a bad design for the 1990s - it's a bad design for now, however.
You'd have to go back at least ten years to find cars without it.
The real problem is that the designers of CANBUS never dreamed of a day when rogue nodes could show up on the network and start broadcasting messages they should not be broadcasting. Automotive embedded systems were closed loops and, aside from perhaps a diagnostic tool in the garage while parked, not susceptible to spoofing messages.
It's easy to say that the architecture is flawed, but that's no excuse at all. The CAN-bus allows control of the car, so non-control devices should not be allowed to send control messages on the CAN-bus.
It's the same as blaming the insecure architecture of the internet when your password gets snooped, when you should have just used a secure tunnel.
Unfortunately CAN is not as complex as an IP packet. It's essentially a one-wire serial bus with collision detection. Even RS-232 lets you clip the TX line so that a device could listen but not send. You would need to clip the TX before the CAN transceiver, and that's something nobody typically does.
But it's cheaper to use a single bus and just slap everything on there. Or in the case of something like OnStar, realize you can add extra capabilities through firmware and not fully think about the impact when your radio can send unfiltered messages to your ECM.
https://www.onstar.com/us/en/services/security.html
I hope they get this sorted before self driving cars... (50 bitcoin in 20 minutes or your car takes a drive off the pier...)
I would NOT like to think about what would happen to someone who tried this sort of thing. I expect within seconds of the first accident (or worse, injury, even fatality) causing malware being discovered, the resources of the entire NSA would be being used to track down the author. Then, when found, 'bad day' would not begin to describe the rest of their life. In fact, I can see this sort of thing being validly placed under 'terrorism' and dealt with appropriately.
People who randomly attack vehicles being driven around today (brick thrown off bridge over a busy road into windscreen et al) are not the smartest, or have poor self control or other issues, but they are actually quite rare. To pull off an automated hack would require enough intelligence that they can surely understand the consequences. Therefore, this will be done by a genuine psychopath (or sociopath? never quite sure of the terminology) or terrorist group.
I think we should be as worried about vehicular-malware-based-death as we are about dying from other terrorist attacks. So yes, I know that means the risk is small, but the general public will over estimate it, and worry inappropriately. That seems to be a matter of education, not technology, though...
I suspect whole auto industry needs to re-learn (if they ever learned in the first place) the lesson of the Therac-25 and what "fail safe" means. Some dangerous situations should not be possible.
Unfortunately, I suspect the auto industry will choose to learn those lessons the hard way. When people die from someone messing with their steering or brakes remotely, I hope whomever signed off the idea of mixing remote signalling with critical systems is found personally liable for manslaughter.
This is one of big problems with the software industry nowadays. It has a role to play in nearly every major industry but does not have the same regulatory hoops to jump through to get into that industry. In this case, I am sure multiple mechanical and electrical licensed professional engineers had to stamp all of the physical components that make up the vehicle but I would be very surprised if any software was ever signed off on by a licensed professional engineer explicitly (there is a case to be made for implied acceptance by the engineer of record for the system that the software runs on but I think it is weak).
It will be interesting to watch the ongoing situation with Chrysler:
http://www.wired.com/2015/08/chrysler-harman-hit-class-actio...
If the class action goes forward there will be a legal examination of whether a security flaw that allows remote tampering is a safety defect or not (of course it is, but I mean in the context of liability).
I pretty much expect that automakers will quickly start shipping systems with effective segregation (the cost pretty clearly doesn't outweigh the PR downside), so the interesting question really is whether the cars on the road today represent negligence or not.
He intercepted the communication from the app. So it is an app hack like we have seen numerous times. It my be different, but it sound like cookie stealing what was possible with the Facebook app and the Instagram app. Then with those credentials you can do all those things that you are supposed to do like if you where the legit user.
All those functions are functions supposed to be done by the app. So there is no hacking on the car side done. The interesting piece of information would be: can that be used to actually hack the car?
So far, sniffing the packets from the iOS BlueLink app, it appears to broker requests through a service by Covisint [http://www.covisint.com/]. From there, I cannot figure out how the vehicle communicates to receive these messages.
The payloads between iOS and Covisint contain tons of information about the vehicle, but nothing that exposes the communications between the vehicle and BlueLink or Covisint.
The vehicle has the ability to connect to Wifi... I will prod at that next. :)
From there, I cannot figure out how the vehicle
communicates to receive these messages.
The Chrysler hack was possible because the cars' built-in cell connection [i]wasn't[/i] connecting to a private network; the cars were unfirewalled and accessible to anything else that happened to be on Sprint's cellular data network.
It appears that the hacker can gain access to whatever the phone app is capable of... which is not THAT much really. You can absolutely start and stop the car but you need the key fob to actually drive the car and I don't believe you can stop it when it is actually being driven.
There is no speed or braking controls in the app. You can unlock/lock, start/stop and trigger the alarm.
In addition the the device must be near the car and the user must be using the app.
I am glad they are patching this, but it's really not on par with prior vulnerabilities as far as I can tell.
Turning off a car while you are driving it is a big deal.
OnStar is capable of performing more functions, such as locating the car when it is out of sight/sound range, slowing down the engine, locking down the ignition, and performing remote diagnostics.
I couldn't confirm this by reading the article, but it might be possible that the protocols and APIs used by the app could be hacked to perform OnStar functions that were not intended for use through the app.
So if the app sends OnStarApp( REMOTE_UNLOCK, VEHICLE_ID, APP_AUTH_KEY ), someone might try skimming the authentication credentials, and then send OnStarApp( STOLEN_ENGINE_SLOWDOWN, VEHICLE_ID, APP_AUTH_KEY ).
In GM's mind, the app is trusted software, so any message that looks like it came from the app must have been requested by the owner, through the app. And since the app can only send "safe" commands, like those performed by a radio key fob, OnStar can simply execute whatever command the app message requests without checking it. That would be the same way the CANbus works. If a valid message appears on the bus, addressed to your microcontroller, you act on it as though it were genuine.
They aren't software developers. They're automotive engineers. The design goals are different. In their world, Eve never listens to other people's conversations, cosmic rays never flip bits in memory, and no one outside the company will ever understand your car better than your own engineers.
But there are people out there who will try to figure out if they can pop the trunk release using any component of the car except the trunk release button. Hackers do that kind of thing for fun. And, in doing so, they may find out that not only can they do that, but they can also do things like shut off the engine with a maliciously malformed digital radio station signal.
Then they connect a handheld yagi to their laptop, broadcast the signal at a friend's car, and tell them to hit the "scan" button on their radio while idling in their driveway. Then it hits 88.1-3, a recording of "I'm sorry Dave, I'm afraid I can't do that" plays over the car speakers, and then the engine shuts off. It is a source of great amusement, until the "Oh, shit" thought occurs: "We did this for giggles. Someone else could do the same thing to murder people."
Then they contact the auto manufacturers, who don't do much about it. Then they present it to DefCon, and talk to the media. And we still don't have an acceptable solution. Certain models of car are potentially vulnerable to attacks that we can demonstrate in controlled tests, and which are possibly occurring in the wild in a way that cannot be easily detected.
OnStar's module is in deeply embedded inside the car and in different locations in different models. OnStar is tied into the vehicle diagnostics and electrical system. If you manage to find it, and pull its cables out or something straightforward like that, your car will probably report an engine error and not start. (This issue has been reported and discussed extensively in car hacking forums.)
I asked my local GM dealer--a very large dealer, by the way--about disabling OnStar permanently (at the hardware level). They told me (a) they don't know how to do it, (b) I'm the first person to ever ask about it, (c) they think it might void the warranty (I don't know if they are right or wrong), and (d) they're unwilling to do it.
[1] Edit: Which is something I wanted to use in the sentence, but now I see I didn't. This is not a good day for me.
Sadly, I'm not even being sarcastic.
GM dealers are all supposed to know how to disable OnStar, and indeed it is usually actually quite easy for an end user to do, with no negative impact on the vehicle. I have a 2010 Traverse and disconnected the OnStar module and antennas with no negative impact outside of OnStar -- it is in an easily accessed compartment near the back of the vehicle.
Some dealerships simply never deal with this, though, just as they are supposed to know how to disable the passenger side airbag but many have no clue and act incredulous. It just isn't that common.
GM doesn't widely share the information on disabling it because ostensibly a purpose of the system is theft recovery -- that if your car is stolen they can track it, which becomes less achievable if every thief just pulls a fuse or something. Nonetheless the information is out there and easy to find.
- Raspberry Pi
- RTL8187L USB 2.0 WiFi module
- Adafruit FONA mini GSM/GPRS module[0]. Not LTE capable.
It does imply this was in some part a TLS fail. Either none or failing to verify trust..
To clarify, the OnStar system in your vehicle talks to a data center at GM or wherever. When you use the app, it talks to that data center, and if you have an authenticated, actived session, the data center intermediates commands from the app to the vehicle.
This looks and smells like an entirely standard MITM type attack. He runs a rogue WAP, or listens in on low encryption APs, and when someone uses the app it exploits some weakness in the SSL/TLS process of the app (maybe DNS poisoning coupled with an app that doesn't demand a root signed cert from the peer). That can be fixed immediately and really is remarkably limited in utility and threat.
"Hey look, I can beep my horn from my phone!"
Hahaha, you've never been downtown in a European city, have you?
It's a matter of good idea, bad implementation. They push for features, they push for ideas, they push for new, new, new, better, better, better.
But no one thinks about safety and security until something like this happens.
I am software engineer and that's why I don't want anybody messing up with crucial systems. It's so easy to break things, there were quite a few reports about horrible quality assurance processes in car manufacturers... just NO. I buy car, and I'll be happy with v1.0 of firmware, no updates, thank you
edit : I meant keys inside the car but no one inside.
Buuuuut... we're talking about OnStar remote access, so that's not very applicable. :)
OnStar started as a data connection for diagnostics and emergency services -- it reports back various diagnostic details, and gives your location and accident details in a serious event. Once they had the cellular data connection they added utility for things like lock out assistance and remote start, and locating your car (e.g. in a big parking lot).
This is one of those hysterical overreaches that has no correlation with real world crime at all.
In this case, it may (or may not) be a hysterical over-reach, only time will really tell.
I think it does stolen vehicle tracking too.
In this day when everyone has a cell phone (versus the late 90s when Onstar first showed up), its less useful than before but if your car goes over a cliff, you are knocked out and none sees it, it could be helpful.
Why this needs to be connected to the driving functions of your car is another issue..(they'd claim "diagnostics").
* In the summer, you can start the car's a/c so it's cooled down when you get in.
* Send the address I just looked up in Google Maps to the car's navigation system, so I don't have to re-type it when I get in, I can just start driving.
* I drive an electric car, and also check battery level from inside so I'm sure I have enough range to get to my destination, and can tell the car to start charging remotely, or schedule charging windows in advance.
I find all of these internet-enabled features useful.
as for Maps, that might be a point, but why not use the phone for nav, normally you don't need to type as voice recognition is good enough
in this future in five years, do you buy GM? no? that's why they don't give a damn about security.
So although GM may not have much security pressure from the consumer, depending on the surrounding legal and regulatory environment, creating more secure cars might end up being a sensible move.
I guess what I'm saying is that I agree that currently there isn't as strong pressure for security as I'd like. But that can change and not just from the consumer/sales side.
1) If GM cars security is the best of the market will it carry any weight in the purchase decision (as compared to all the other factors)?
2) If GM cars security is not the best of the market and one of their security incidents make headlines in mainstream TV and newspapers will it carry any weight in the purchase decision (as compared to all the other factors)?
People don't pay attention when things that are supposed to work properly do so but when they don't it carries a lot of weight in the purchase decision. See the Toyota slump [1] in the U.S. market share between 2009 and 2011 caused by many factors but certainly with a contribution of the bad news related to the recalls [2]
[1] http://online.wsj.com/mdc/public/page/2_3022-autosales.html#...
[2] https://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle...
GM (or really, virtually any car manufacturer with the possible exception of Tesla) would be caught flat-footed.
Firmware in consumer products (especially where radio or network access is present) needs to have a security model. Car makers have been betting they didn't need to spend much money worrying about security; it doesn't look like that bet is going to pay off.
If this becomes a thing that any kid with $30 of electronics can do, dinosaur makers are toast.
In general businesses care about short term profit (sure in the long term a hack is bad for business but share holders don't care except in the cases were it would be fatal to the business).
Engineers are pressed to get it done anyway possible and as fast a possible. The ones that push back get fired or moved to another project.
The fact remains that adding security and encryption requires more knowhow and adds a layer of complexity which results in more time required.
This. Also incompetent engineering teams could be a major factor.
http://money.cnn.com/2014/06/01/technology/security/car-hack...
Continental, one of the world's three major auto parts suppliers, is partnering with IBM (IBM) and Cisco (CSCO) to make firewalls that control the information flow between the car's devices. Until it gets security all figured out, the German company is holding back from adding full Internet connectivity features, such as real-time information from the engine that alerts the local car shop ahead of time.
Ford (F) hardware has built-in firewalls to prevent malicious tampering, and the company has a team of noble hackers constantly probing for weaknesses.
Toyota (TM) does all that too, plus it embeds security chips in the tiny computers throughout the car, narrowing how they communicate and lessening the chance of outsider interference. The company even has forward-thinking plans this year to visit the world's largest hacker conference, Black Hat.
It should be no surprise that Tesla (TSLA) is ahead of the pack. The Model S is the most advanced and connected car currently available. It's worth noting the company's mature approach to addressing vulnerabilities. Instead of hunting down hackers who spot weaknesses, they reward them with an "Information Security" badge that works like a Willy Wonka golden ticket, granting exclusive access to Tesla's factory in Fremont, Calif. The company recently sent one to a British hacker who goes by Jon of Bitquark.
But of course the government isn't helping much either. . .
...federal regulators will soon demand that cars automatically relay information wirelessly to one another as part of the U.S. government's vehicle-to-vehicle communication program. Those car-to-car messages will one day be able to engage brakes -- or your steering wheel.
That's bad. Governments are (by far) the most violent organizations on earth. They expand to control everything they can. The actions of power are always to increase one's reliance on it. It's almost a law of nature. If we give up our ability to control our momentum and kinetic energy, it's more than a slippery slope. It's a path to black boxes in everything, including people.
Because nothing says serious security like using the word "cyber" twice in your statement.
Car theft has declined precipitously in recent years. According to the NY Times [1], in 1990 there were 147,000 cars reported stolen in NYC. In 2013, that number had dropped to 7,400. On a per capita basis, it went from 1:50 to 1:1,100; a 96% drop. This dramatic reduction in theft cannot be solely attributed to an overall reduction in crime either.
This is not an argument for the status quo. I'm just pointing out that the principles being espoused in the responses here aren't axioms, they're value judgements. As software developers, we're taught to be hyper-paranoid when it comes to security, and we should be. That's how a culture of security is built.
However, in a broad sense, a balance must be struck. Like it or not, there is an acceptable rate of car theft, and that rate is non-zero. The acceptable theft rate is defined by what consumers are willing to pay to insurance companies to take on the risk and the assessment of the balance between probability and the anticipated inconvenience of having their car stolen. Consumer choices are defined by the alternatives, though. If the solution is that cars shouldn't have these features at all, can you find that car? What else do you give up in the process? Unless automakers ignore the problem, and theft rates skyrocket, buyers are still going to seek out these network enabled features because their convenience outweighs the risks.
Of course, it could be argued that we'll see a rise in theft again as criminals learn to use new technologies to steal cars. This has already happened in some places. BMW has run in to a couple of fairly high profile cases of this recently. In one case, attackers combined the easy accessibility of the ODB II port from a broken window with a security weakness in the cars software to bypass all the theft protection. No network access required!
The linking of the CANbus to network systems is too enticing from a consumer convenience perspective. That genie is out of the bottle.
1: http://www.nytimes.com/2014/08/12/upshot/heres-why-stealing-...
It would be amazing if we as a society would spend all that money and effort in worthy problems.
On the contrary, monetization for the sake of wealth generation is a worthwhile effort in a society based on materialism & selfish desires. We have been programmed all our lives to take & want & connive(perfected to a science in the US & most 1st World countries), that's what capitalism has evolved to, IMO. This Internet Of Other Peoples' Things is just the latest, most efficient way they have found to wheedle, cajole and manipulate us fools from our money!Plus, don't forget the data collection opportunities! Hitler would love the IOOPTs.
Although, Windows 10 looks to be breaking some pretty scary ground. Google & Apple eat your hearts out!
Also his motorized combo lock breaker has made HN front page before https://www.youtube.com/watch?v=YcpSvHpbHQ4