How To Hack a BMW: Details On the Security Flaw That Affected 2.2 Million Cars

0x2A (548071) writes BMW recently fixed a security hole in their ConnectedDrive software, which left 2.2 million cars open to remote attacks. Security expert Dieter Spaar reverse engineered the system and found some serious flaws [note: if you'd prefer English to German, try this translation], including using the same symmetric keys in all vehicles, not encrypting messages between the car and the BMW backend or using the outdated DES.

Comments

Definition of "Remote Attack"

[Anonymous Coward]

Somehow I don't think the definition of "remote attack" is "disassemble the computer, attach all kinds of expensive hardware to analyze communications and firmware, hack into the firmware to retrieve the encryption keys, so only then you can use a base station emulator to trick the car into thinking your remote machine is a BMW firmware server."

The "remote attack" requires physical access, specialized skills, and intense hardware interaction. It is not something that some Romanian skript kiddie can pull off from their mom's basement.

Re: Definition of "Remote Attack"

[StevieWonderBoy]

6,000 cars were stolen this way in London last year. You are wrong. They are selling kits on the ebay that allow you to clone keys.

Re: Definition of "Remote Attack"

[drinkypoo]

And it's not just BMW, it's for all kinds of makes and models. Hell, you can go to Dealextreme and buy many unlocking tools, just by searching for unlocking tools. And I'm not talking about the kit of stamped spring steel pieces, either.

Re: Definition of "Remote Attack"

[AmiMoJo]

One of the most common attacks is actually the simplest. The thief waits in the car park with a jammer. Most cars use 433MHz in Europe, penalty 915 in the US. The victim walks away and presses the lock button on their key fob and doesn't notice that the car didn't actually respond. Once inside the thief can use the OBD-II port to steal the car.

I prefer keyless entry as you press a button on the car to lock it, and even if jammed it will always lock.

Re: Definition of "Remote Attack"

[_merlin]

You only need physical access to the Commbox from to a single car to extract encryption keys that can be used to steal many cars. That's the flaw. The cellular base station emulators are readily available.

This is why I quit web programming

[Theovon]

A company as big as BMW should be able to hire some security experts, so this should be a bit embarrassing for them.

But the truth of the matter is, doing security is not easy. Take web programming, for instance. Back when I first learned PHP, I found over and over that whatever design or coding approach seemed most straightforward and intuitive was inherently unsecure. All sorts of escaping and manual insertion of encryption functions are required, and that clutters up the code to the point of making it hard to maintain. I did manage to implement most of it in a common PHP file that I reused over and over again, but there was a huge learning curve, and it was a pain. Since then, people tell me that it's gotten a LITTLE better. For instance, database wrappers generate the SQL queries for you and automatically escape strings. But for the most part, it still sucks.

If there were a single best book to read on cyber security, then perhaps we'd have fewer problems like what BMW had. But in reality, to get good at it, you have to have a vast familiarity with the literature and tools. You do that much reading, you might as well get a PhD. And my friends with PhDs focusing on security are in academia, not industry, so we get more security papers but not more secure devices.

Re:This is why I quit web programming

[drinkypoo]

A company as big as BMW should be able to hire some security experts, so this should be a bit embarrassing for them.

But the truth of the matter is, doing security is not easy.

No, the truth of the matter is in your first paragraph. Designing and building a car is not easy. Not making complete fucking moron decisions about security is easy, if you hire someone vaguely competent. BMW decided to skip that step to save a few bucks to ensure nice corporate bonuses, and customers suffered. BMW should be on the hook for each car stolen in this fashion, and have to pay complete replacement value, because they failed to make a good-faith effort at security.

BMW software sucks big time.

[140Mandak262Jamuna]

I have a 2014 X3. The damn thing would not connect to any of my Google Nexus phones via blue tooth. They have a very limited set of handsets they support. They don't seem to test anything other than iPhone and Samsung. Supposed to connect to 4 phones at the same time. The damn module crashes all the time and forgets perviously paired handsets that worked well earlier. Their mp3 playback is abysmal. All those old mp3s I ripped from CDs back in 1990s and early 200s play back flawlessly in every mp3 player, every computer, every device I have tried. From memorex-mp3-CD-R, to WesternDigital-TV box to chromebooks to sansa ... But in X3 it would not play, repeatedly crash the module, or get into endless loops.

Root cause of the problem seems to be some rigid adherence to specs and dim-witted error recovery process. If one mp3 file has a mismatch between its header declaration and its data section, that mp3 can misbehave. OK I will concede that. But the default action on seeing this mismatch should not be the whole entertainment module to crash, reboot and rescan the 8 GB memory stick all over again for media files. When it crashes and rescans, bluetooth does not work.It reminds me of Digital workstations where none of the the IEEE exception handler I install would work. Their default handler, which is to crash the process and write a coredump would kick-in no matter what I declare as error handler. BMW seems to be using an even more extreme version of this mode.

BMW is our customer, and they buy some engineering design analysis suites that we make in my place of work. I wonder how they will behave if I crash the entire computer every time a BMW engineer feeds an incorrect data to our suites.

I am not surprised it has so much of vulnerabilities. Anything that crashes this much will fall back to single user super user mode and present a console to the attacker sooner or later.

they used encryption, hmacs, thought they knew

[raymorris]

>. Not making complete fucking moron decisions about security is easy, if you hire someone vaguely competent. BMW decided to skip that step to save a few bucks to ensure nice corporate bonuses, and customers suffered.

Their developers encrypted the relevant text messages and used hmac to ensure their authenticity, so they thought it was reasonably secure. It's not that they were INCOMPETENT developers, the issue that none of them were security experts. Because true security, security that can't be broken fairly easily by an expert who then publishes a tool for script kiddies to use, IS hard. BMW's programmers did as much as I'd expect any application programmer to do. It's then time for the security audit, by a truly qualified security person, to catch the kinds of mistakes that the author caught. I work with some very good programmers. Some of them are really good at UI design, some are good at managing large projects, some are very versatile. It's a really good team of professional programmers. I catch security errors they make all the time because I'm the security guy. On the other hand, they have to fix my GUIs to look nice because I'm not good at designing attractive GUIs.

I worked on the ConnectedDrive system

[Elledan]

While I do not work for BMW directly, the company I work for does do projects for BMW. One of the projects I worked on was the iOS app which is part of this ConnectedDrive system.

To be precise, for the 'old' version of the app (My BMW Remote App) for non-i models we started off with this black box library (CD lib) which handled all the communication with the BMW servers.

While I didn't do any protocol analysis or looked at the communication between car and servers, even for this iOS app it was pretty clear to me and my colleagues what the security implications would be if someone were to be able to obtain log-in data just for that part of the communication.

Depending on the market (America, Europe, Japan, etc.) there are some limitations to what one can do with the app (based on the type of account, IIRC), such as from what range one can see where the car is on a map and whether one can unlock doors with the app or not (not allowed in the US market, from what I recall). Where these limitations are enforced I'm not sure. It might be based on the server, in which case this hack would bypass such limitations as well.

At any rate, this security leak does demonstrate quite succinctly how important it is to properly security audit such systems before releasing it into the wild. Even for the current project I do for BMW (related to the headunits), having an active internet connection means that security is essential, including plugging buffer overruns and similar.

Nobody wants to have one's headunit go blank during navigation, in a constant reset cycle or be turned into a spying device, after all :)

Note that I'm still under NDA for all of these projects, so I can't go into much detail.