A New Wireless Hack Can Unlock 100M Volkswagens | Hacker News Reader

A New Wireless Hack Can Unlock 100M Volkswagens

wired.com

113 pointscraigjb78 comments

Big hardware companies like VW seem to still focus on "security by obscurity", because they're not used to a connected world with plenty of attackers with lots of free time on their hands.

I'm quite worried about the future of networked cars.

And worse then sue to try and keep exploits hidden.

It is like the vehicle industry is stuck in the 1990s. We've moved so far beyond that elsewhere, software designed to be updated, working WITH not AGAINST white hats, and having designs secure on paper first before you implement.

Vehicle manufacturers put convenience and speed ahead of solid security principles, and it is only going to get worse with more wireless connectivity making it into vehicles year upon year.

Considering who's been the target of some of the more conspicuous hacks lately, my guess we're going to see some fairly draconian legislation during the upcoming Presidential and Congressional terms.

Don't look for the CFAA to be nerfed anytime soon, let's put it that way. The politicians will hit back at hacker culture with the only weapon they have.

Nobody (including me!) expected extremely cheap software-defined radio transmitters and receivers to be available. A short key and a rolling code seemed like a good enough obstacle for a door lock 20 years ago.

I don't know about not expecting it, I think as a general rule all expensive technology will likely be cheaper in the future, or simplified so that it's accessible to the masses. It's difficult to think of a counter example?

I don't think this actually needs fancy software-defined radio hardware. That looks like a cheap, generic 315/433MHz ASK receiver for the keyfob, and those have been widely available for decades. They're essentially what you'd find in the car side of a remote-unlock system, or in most bargain-basement RF remotes of any kind.

"ASK" is amplitude shift keying (shifting/changing between two amplitudes). In cheap transmitters (like the ones on keyfobs) one of the amplitudes commonly is "on", the other "off". This is morse, literally the first modulation ever invented to be used with radio waves.

Receivers for much more complicated modulation schemes have been built by amateurs for many decades, so I think in the case of analyzing the keyfobs' security SDRs were not a necessary tool.

But of course with the advent of cheap Rx and Tx capable SDRs the amount of people able to decode (and transmit) all kinds of modulated signal in all kinds of frequency bands has exploded, and for example my ability to quickly change from running a cell-tower to receiving satellites signals to decoding/analyzing/transmitting the keyfob radiwaves and unlocking a car is only one "./configure ; make" away, once I have acquired a sufficiently advanced SDR. No need to build, solder, tune, debug an electronic circuit tediously custom built for one application.

Yes, but SDR allows for the quick and easy experimentation, even if the hack ends up being implemented on other equipment.

The other aspect that makes SDR so appealing is wiring up software blocks in GNURadio that used to be implemented in hardware. This drastically reduces the testing cycles and lets you basically guess, measure, and muck around until it works.

I'd rather buy a Google robot car than a Ford (etc) robot car. When it's all about the software you want a software company, the actual car part is a commodity.

Same with computers, TVs, phones, IoT, routers etc.

They develop their software in a waterfall like method because they develop their hardware the same. These are still core engineering companies that don't fully value software.

I asked one of these companies about security, apparently the major governments insist by law on weak encryption and they only have to stand up to 15 minutes of hacking... Pretty terrible right?

Do you know for a fact that they do develop their software in a waterfall like method? I somehow doubt that a bit. At least they publicly say:

"Volkswagen Group IT consistently uses agile workstyles and intensive cooperation with universities, technology partners and Volkswagen Group departments to develop digital solutions."

http://www.volkswagenag.com/content/vwcorp/info_center/en/ne...

Of course, cars do have a lot of legacy (not least because of inertia caused by regulatory processes) but I think they do a bit of what they say.

Having worked on VW Software Projects i can assure you they drank all of the scrum koolaid.

How did hardware and software work together to iterate on a product? Or did they outsource it?

Worked for a vehicle company, it's "agile" as long as it fits within the limitations set by waterfall.

I guess this is a point people will argue for days, all I can say is I have been there. There is strong emphasis on incremental feature delivery with little risk management. It usually came down to engineers pulling magic wands from somewhere and soothing the software into a workable state.

Haha, that's a funny description of waterfall which more or less matches the agile process at my bank.

http://www.halfarsedagilemanifesto.org/

Perfect.

Didn't agile (or a least scrum) start from car manufacturers ?

http://the-agile-pmo.org/?p=54

It doesn't mean adoption was far reaching even if it did.

so "waterfall == bad and agile == good".... is that your point?

I would beg to differ... I've got pretty extensive experience of both and can say for sure that there is a negligible difference between the two as far as productivity goes.

That view is against popular opinion, but the only thing that really makes a difference is the commitment and intelligence of the people on the team... not the development process.

Also.... agile development is a less-good fit with hardware development... and the embedded software that goes on the hardware has to fall in line with that.

I've also had good experience with both. For me waterfall is perfectly fine if you don't have a hard deadline and agile is great for reducing risk (from what I've experienced).

I know agile and hardware doesn't go too well together and software of course is told by management to be more agile (because some manager heard it's great). The customer expects fixed incremental feature delivery (which they measure your performance on and scale your bonus with) and somehow as a software engineer you have to be agile in step with the waterfall process.

I think in general agile is better for software and waterfall is better for hardware - the problem is somehow they have to go together. It's not the best to say the least - often shipping with errors and bugs.

You realize that the concept of agile development was based on concepts practiced by the auto industry, right?

Not the American auto industry. You're thinking about Toyota not Ford.

The American auto industry has been practicing lean manufacturing techniques for quite some time now.

I think the companies themselves do, but they do an extreme amount of outsourcing too. I'm speaking from experience obviously, maybe it's a bad example.

Would just like to add that some of the security issues are to do with limitations set by governments. I think China and the US in particular insist on crappy security and it's cost effective to simply apply that everywhere else. Forbid anyone have something a government can't pry into...

I think for car manufacturers, they are limited to 128 bit encryption and cars only have to stand up to about 15 minutes of hacking - that last one isn't particularly well defined either.

Have you got a source for either of your claims?

"128-bit encryption has now emerged as the standard of illegality.[16]" [1]

[1] https://cyber.law.harvard.edu/privacy/Encryption%20Descripti...

That doesn't seem to have much to do with cars...

Also properly implemented 128-bit encryption is generally secure for 15 minutes or 15 days or probably years (the largest key I'm aware of having been cracked is 64-bit and that took a lot of computers a looong time)

This is absolutely true. For example, the US gov depends on 128 bit equivalent crypto to stop quantum factoring attacks for the foreseeable future.

A google search of "US Government 128 bit quantum factoring".

Stop trying to blame the government for corporations not doing due diligence.

If anything, the real failure is Government not enforcing agreeable security measures like NIST and ISO across all US Organizations.

If I remember rightly, it's set as a maximum for the purpose of allowing cracking. I imagine it would take ages if they were using AES, but I think they are using something more arbitrary than that. I'll try to find out.

It seems you're interested, I'll see if I can contact them and find out more. I know they mostly adhere to the Ford specs, so it might be worth a hunt through them. I honestly can't seem to find any of the security spec we were given online.

Even so, it's worth pointing out that the car companies have the private keys for flashing the vehicles themselves, all stored nicely in a massive database. The dealerships simply plug in a code to a computer and returned is a key to unlock. I know that they bend over backwards to any requests from Government agencies.

Also, the only difference in the software is usually just a language setting, something that's a few bits in the config file. Other than that, they are identical. So a hack for one Country is a hack for all - across multiple models and multiple years.

The other might be an unwritten rule in the automotive industry. They just hire a bunch of hackers and make sure it stands up to 15 minutes.

Is that 15 minutes of brute force? Because surely as technology improves more can be done in 15 minutes.

Here's the thing, when software goes into a car it will likely have to last 10 years until it's outside of manufacturers warranty (I think that's in the Ford spec). So sure, 128 bit encryption (not sure what protocol they use) is tough to crack today, but in the next 10 years when the car is still on the road, will it still be tough to crack?

Do you have any evidence for that at all?

I'm fairly sure that automotive security testing doesn't have an arbitrary limit on time of attack...

How long do you set? How much do you test? At some point, you just have to say "enough is enough".

It was a few years back, but I think (not entirely sure) the requirement time aligned with the time it took to hack bluetooth or something. I think there was a case about hacking car wheels that reported their tire pressure via bluetooth and that was used as a time to be better than. Perhaps this story [1]. I think they were using it to get people to pull over and hijack their vehicle.

But that could be wrong, I just remember there was some discussion about that around the time we were talking about the security requirements. That's the best I can do.

[1] http://arstechnica.com/security/2010/08/cars-hacked-through-...

Of course all security assessments are time limited, but 15 minutes isn't a time frame I recognise from 10 years as a security consultant...

Security assessments are usually measured in days or weeks or for large projects months

I don't think 15 minutes is the limit of vulnerability discovery, I think it's the limit for the exploitation. I think it was weeks instead on months, time was really tight. I honestly can't remember whether they get the source code to work with.

If I remember rightly they test the CAN and all wireless signals. I think one of the things they were worried about is an owner re-flashing the on-board software and selling on the car as it might still be under warranty.

But of course now that the vehicles are both online and moving towards self-driving, the threat space is completely changing. I think we're approaching the days where a computer virus actually takes lives.

"from 10 years as a security consultant..." Out of interest what area do you consult in?

> might be an unwritten rule that's not a source, or even anything close to it. Purely hearsay.

> They just hire a bunch of hackers and make sure it stands up to 15 minutes.

Stands up to 15 minutes of what? Smashing the side window with a crowbar? Angle grinders through the driver side door? Who hires them? What sources do you have that say this? You seem very authorative in this thread, yet have nothing to support your claims.

"You seem very authorative in this thread, yet have nothing to support your claims." - Unfortunately, I can't back my credentials because of the stuff I've work/ed on. I can say it was a US company involved in automotive parts.

"Stands up to 15 minutes of what? Smashing the side window with a crowbar? Angle grinders through the driver side door?" - Exactly the point I was making. They just hire a random number of hackers (not random obviously, but probably not much research into what is truly sufficient either) and leave them alone with the system for a few days to see if they can do anything to it. If nothing happens they get a pass. It was literally a case of getting a tick in the right box.

"Who hires them? What sources do you have that say this?" - The place I work/ed.

I need to see if the specification are public. I checked with an old colleague and they weren't sure if they published them - so they are now checking themselves. They agree that it was Government defined, but now I'm interested in finding out who else had to adhere to that.

Properly implemented 128 bit encryption is still secure. Don't forget key fobs are not forced to use public key crypto systems.

Direct link to research paper: https://www.usenix.org/system/files/conference/usenixsecurit... Basically VW use the same secret keys to authenticate wireless comms across millions of cars. They change the key every few years (new car platforms, etc).

A legit service would be to replace lost keys for a few bucks rather than the $100's a dealer charges for one key.

I'm in exactly this situation. Had my VW's key stolen, and now they are asking $200 for a replacement.

It's easy to get a replacement key, but you need VW to program it. Hopefully that process becomes public.

Many cars' keys can be programmed without the maker, at least if you have a copy of the original key. And you should always have two keys, lest you lose one.

Unfortunately I don't have another electronic key.

My model (2013 Polo Vivo Blueline) came with one electronic key/remote, and one mechanical key. So I can buy another electronic key, but I can't use the remote without VW programming it.

Are you absolutely sure? The vast majority of cars have a way for you to re-program keys, key fobs, etc. provided you have at least one master (not valet) key available. You may have to look in weird corners of obscure forums, but you can probably find the procedure. I did this recently in my car and it involved pushing the brake pedal 8 times, accelerator 7, turning the wheel left-right-left, etc. It sounds like a ridiculous wild goose chase, but this is the sort of thing you can expect from car manufacturers.

Ford requires TWO working keys to progam a new one in the car.

I didn't need to do this yet, but with Toyota when I skimmed the manual, it appears I could add and remove keys myself.

It's public if you poke around enough, I wrote up a little blog post: https://medium.com/@chairface/how-to-steal-an-audi-71d53cb5d...

you'll just need the contents of the 95040 eeprom on your ECU - you can dump it from the OBD2 port with various tools

Many locksmith shops can program a key -- IF you still have a working one. If you've lost all your keys you need to have the car there, which is difficult if you can't start/drive it.

Silly silly car manufactures that leave the car systems vulnerable in almost every way because they can't think far enough ahead to actually be secure before having "cool" things like button less key fobs and button starts. Seriously... Why do so many people not care about security?

> Why do so many people not care about security?

Security costs money.

This, and their culture is mostly defined by mechanical engineers - at least at German automakers.

Security really doesn't cost much. To constantly maintain the best security does cost, but this is about something that they could have avoided with the tiniest bit of thought. Their simple approach of "it's secure as long as no one knows how to break in" is annoying and whether it affects many or not, it is about the possibility of bad things happening. GTA isn't thought of as a big crime for some reason and it can cost the owner a lot. It would be nice to think my car had someone make sure that trivial snooping would not allow access to the car or that my car's head unit cannot control other parts of the car such as breaks and steering.

> Seriously... Why do so many people not care about security?

Seriously?

That's because as of today, not having security in this domain hasn't bitten anyone hard enough, ever.

Just think about it. At least I haven't heard that despite all these car key hacks any significant number of people would've had their cars and/or belongings stolen. Nor have I heard that any one car manufacturer's sales have significantly plummeted because their cars "can be hacled".

After that, it's just pure economics. As of now, the ROI for implementing good security in cars (or anything IoT for that matter) just doesn't pay itself back. At all.

Now, I'd like for the car makers to actually do something before chaos-by-hacked-cars ensues as much as anyone and people have to actually die. But it won't happen before the incentive is there. This is one place where government regulation really, really should come into play. There should already be laws for massive fines plus complete obligations to fix every security and safety related bug in all cars sold. Sound too hard on the makers? I don't think so, just look at the mechanical side of the cars: call-backs to fix those are happening all the time, because everyone understands that you can't drive a car which may hit you with an airbag at 60 mph. Or have a broken airbag system.

economics. the benefits of security have to outweigh the costs. theft of VW's via this type of method hasn't been significant yet, and cost of implementing stronger security would've been real.

So how do you make something secure when attackers have physical access for hours? I think cars cannot be perfectly secure like we expect computers to be purely because we don't leave our computers unattended for hours in public.

Full physical access? It's hard, but seems an unrelated issue in regards to the linked post. The vulnerability here is that you can capture the key from air during transmission, without having physical access to the car or the key. We've had the technology to prevent this for a long time even before this system was designed. One could make a "good enough" argument for 1995, maybe even for 2005 although that would be seriously pushing it as that's after Blaster [1], but the fact that they're still selling vehicles with this system is really bad.

[1] The Blaster worm woke up a lot of people to the very real problem of security vulnerabilities https://en.wikipedia.org/wiki/Blaster_(computer_worm)

I'm curious how secure physical car locks are for comparison. Bike locks and house locks are not particularly effective against skilled attackers. They exist mostly to stop the stupid and opportunistic.

Car locks are as secure as the pane of glass just above them.

a modern iPhone can stand up pretty well to physical access for extended periods of time.

In fact, the attack used in this whitepaper would've likely been thwarted had VW used a secure hardware device analogous to the iPhone's secure enclave.

Thank you Volkswagen, technology, hackers, crackers and everybody involved that I can read titles like this that would totally fit into a 1999 sci-fi movie about the near future :)

These security issues are not exclusive to computer systems in cars. A valet recently used my physical car key to unlock a different car. (Same make, different model.) He only realized he was in the wrong car when the ignition wouldn't turn.

https://twitter.com/internetofshit

Reply on news.ycombinator.com