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

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: 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.

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.

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.