Head Unit as a target for hackers

Head Unit as a target for hackers.

In recent years the problem of car hacking is raised more and more frequently. It concerns almost everyone: car manufacturers, OEM and information security specialists. Of course,  EU and  USA authorities are also interested in it and fund research in this field. As in information security industry some activities are just attempts to scare and some problems are deliberately overestimated, I would like to look into this subject without unnecessary emotions but keeping in mind that it's always best to err on the side of caution. In my own professional realm I deal with ConnectedCar system security and embedded solutions for vehicle systems. So I would like to talk about new threats in IoT and cars in the near future. This part is about potential attack vectors on Head Unit and its environment.

Is Head Unit a desirable target?

Why did I focus on Head Unit in particular? Of course there are other interesting and more control-critical targets in vehicle system. Head Unit (hereinafter it will be shorten to HU) or to be more precise its logical component IVI (in-vehicle infotainment, but sometimes I will use termin HU as IVI) includes entertainment media and navigation system and manages such uncritical for security things as air-conditioner and cab lighting. In common car HU is not connected with crucial ECUs (Electronic Control Unit is a controller of some node: vehicle subsystem, power supply or ABS). However because of  large scale of computer automation there are other interesting functions: door locks, window raisers and opening of car boot. And when I say that there is no direct network connection via CAN that doesn't mean that there are no logical interface to critical ECUs. For example in some network layouts HU is connected to CAN gateway and you can get access to more interesting components is allowed from that gateway. Or HU can be connected to some other interesting interfaces, for example Cruise Control. Here you can see the analogy with internal penetration testing, if you already have access to HU you can hack  gateway as intermediate node and then attack some important ECU from it. I won't dive deep into and ECU and CAN security issues, they are already well-known and Charlie Miller and Chris Valasek (just to show off a little bit I’ll mention that I drank a beer with Chris and other speakers on CONFidence 2011, but not sure if he even remember me) have made a review of them which includes authentication issues and brute force of ECU via CAN bus. You can find this review here - http://illmatics.com/car_hacking.pdf. In summary: HU is a very good entry point. For me it is also a handiest target and that's why:

1) User data.

HU runs operation system that has access to user data. Attack on a car system can be an instrument for spying on user for example. It should be noted that all User Experience features as automatic parking or fuel payment which provide interesting user data are also located in HU.

2) Convenient place for a backdoor.

HU file system is usually mounted as read-only but there are some opportunities to load a backdoor with permanent access to network. There can be technical difficulties of breaking  protection created by vendor but from any point of view HU is the most convenient place to take control over the system with subsequent stable access. For those who are interested which  operation systems are used for IVI, I can tell that there is a big variety:  from  QNX and Linux  to  Windows CE and Android! (in HU can be few CPU and OS, not only one)

3) Attack development.

This is also follows from item 2. HU is a component to start attack on ECUs (or CAN gateway) for privilege escalation and other evil. It should be added that HU has highest performance among all computers in a car. Different manufacturers use different CPUs and RAM units with various capacity but as a whole embedded hardware is rather powerful (as it is used to render some GUI, operate with network traffic, play music and do all these operations in parallel). Usually ARM Cortex 6 is used, Tegra 2 or 3, for example, but this may vary.

4) Suitable for remote attack.

In  fanciest cars HU runs many applications, has many Internet connections. Let alone USB, Bluetooth and Wi-Fi. So it is easier to attack HU than directly ECU, because for HU various amount of attack vectors exist including attacks from the Internet.

Car security is similar to APC/SCADA security except that our PLCs (ECU) are connected to smartphone (HU) with Internet access.

Summarizing all my ”analytics” I can conclude that HU is the most desired and useful target but for sure there are many other possibilities like baseband GSM modem, Wireless TMPS, direct access to CAN (local attack), attack on sensors and radars and so on. In other words car security includes not only IoT security.

What would be the use?

Before we go on I would like to raise a good question - why anyone in the world is interested to hack our long-suffering car? There are several alternatives:

1) Spying on a specific person.

For example someone wants to spy on all his/her movements without any taps. Certainly taps only duplicate  car functionality:  GPS, GSM, Wi-Fi and BT. The only thing is needed -  install software and it can be done remotely. I think that  price of such attack is still too high but for sure: car system’s architecture and design gives such an opportunity. Besides, ConnectedCar can be attacked from the Internet without physical interaction with the car (I will return to this theme a little bit later). And as I don't want to produce many paragraphs I will also add unauthorized access to car payment features to this point.

2) Devastating actions

This point is rather uncertain but imagine ABS is turned off at specific moment - it is rather dangerous. Imagine another dangerous scenario: all car electronics is disabled by a railgun on high speed during sharp turn. Such things have already happened by accident (electromagnetic interference from base stations was the fault). We can possibly get same results if we disable ECU programmatically. But of course such scenario is better suitable for some action movie.

3) Unauthorized physical access

Car theft is rather obvious vector but it is more connected with local physical attacks and local network vulnerabilities. Nevertheless MiTM attack that allow to open car doors has been shown in practice.

Let's talk about vectors that are not so obvious:

4) Route tampering.

Self-driving cars are still on testing and revision stage but even without this super-feature we can tamper a route if driver trusts everything  navigator is saying. So if the navigator says that the road is closed or there is a traffic jam and it's better to choose another route, the driver might follow its advice.

5)"Locker"

When we discussed these issues on 21th DefconRussia meetup - http://www.slideshare.net/AlexeySintsov/backdooring-a-car, the "locker" idea of monetisation was put forward jokingly. Imagine you are getting into the car, starting it and see ransom demands on hell-red screen to send money in order for HU to be unlocked. Funny that "locker" can really lock  doors and windows of your car :).  In case of some popular vulnerability or unscrupulous MRO centres this scheme might work.

That's enough for a start, I think it’s easy to invent even more good applications.

Attack vectors on HU

In this part we will talk about attack schemes. Mind you that I will describe them in theory but many of them were applied in practice. I can't tell about that part of my work because of NDA but I will make a review of attack vector types to make you aware of possible attacks in theory. Let's start from HU structure. Usually it is a box connected to various boards, displays and sensors that contains GSM/3G modem, card/USB plug, Bluetooth device, etc. Inside the box there is RAM, ROM and CPU, usually on AMR chip. There runs fancy OS that controls navigation, some cabin elements (for example, door locks or window raiser), video/mp3 elements and sometimes even has a web-browser. I'd like to add that HU may vary from one manufacturer to another and from one generation to another. Some of them have several CPUs and OSs, some even have hypervisor and OS with all user data virtualized. I am certain that German auto industry follows a course of protecting car crucial resources from user processes but this path is thorny. In the simplest case there will be only general- purpose OS, but as I have mentioned, HU still  isolated at network level.

OS type can vary, I've already mentioned QNX, Linux, etc. Real-time OS is not necessary for IVI if there are no specific tasks requiring it (and such tasks are rare), but QNX is used by several manufacturers (HARMAN is a striking example). GENVI and Tizen are examples of manufacturers that use Linux.

Let's talk about network level isolation. HU is connected to OBD that is connected to a switch. Usually it also has access to audio and phone systems (MOST bus is used here) and sometimes direct connections to some ECUs via CAN. Where the attacker should make efforts in order to hack HU?

Local interfaces.

Let's start from the simplest - local interfaces allow us to interact with OS services and applications. This vector seems doubtful: the attacker should somehow get access to these interfaces. But it should be taken into account that many "secrets" are hidden on client's device, certificates and passwords can be shared and can be default for all devices of that system class. Yes, Security Through Obscurity approach is widespread in car industry :). Besides this target you can perform hybrid attack on local interfaces - source of an attack can be remote but  penetration is made on a local HU. For example you have downloaded mp3 file with tags (that contains BoF exploit), loaded it into HU and launched it. BoF gets to tag parser and the backdoor is installed (here is the example - http://www.itworld.com/article/2748225/security/with-hacking--music-can-take-control-of-your-car.html). Card updates, POI, fake updates can be used similarly as well.  Besides "file parsing error" attacks there are some interesting ways to exploit errors in logic of updates installation, for example, updates for navigation maps. Local interfaces concept can be applied on Bluetooth, USB and Wi-Fi hotspot (yes, such feature exist too!), not only for files and import. Also EthrenetOverUSB turned out to be a very popular solution. In other words USB plays the role of Ethernet interface to local ethernet  network of the car. One can connect via SSH as root (remember that password is default) and it's all over. The same thing is for Wi-Fi hotspot - once HU creates such hotspot it can open SSH port for connection. And I'll repeat that it's not just guesses, anyone can check that (for example, Toyota and Mazda fans have already found such hack - http://www.mazda3hacks.com/doku.php?id=notes:sshnotes) I have seen that in other vendors' cars too. So I'm waiting when hackers will find more of this and for sure they will!

Attack via applications in the name of IoT.

The most interesting vector (for me) is attack from the Internet. There are a large amount of opportunities and it is permanently growing. Let’s start with classical client-side attack on browser and its plugins. Yes, it's trendy now to have browser in the car, which can read PDFs and Word documents! It could be a WebKit assembly or Chrome, so you can see common problems and difficulties. In addition in some cases browser can be run as root. That's OK (except running browser as root, I refuse to understand it). There are also many applications that use Internet and services like Facebook or navigation in addition to web-browser.

I would like to say some words about HTML5 security and WEB technologies, somehow they were made "embedded" and have become the basis for all ConnectedCar operation logic. And now imagine the consequences of SSRF/CSRF or XSS. Suppose HU interface and other applications are based on HTML+JS, if there is XSS, we can get access to internal API: get car location, VIN, fuelling, current speed and other data from sensors which is available through API. If we have SSRF/CSRF we can interact with internal API and control some things inside the car (if not ECU than navigation logic, profiles and applications) or develop attacks on internal components (privilege escalation). It is rather unpleasant taking into account that ConnectedCar services includes remote manipulation and access to data.

Let's take up the recent case of BMW hacking - http://m.heise.de/ct/artikel/Beemer-Open-Thyself-Security-vulnerabilities-in-BMW-s-ConnectedDrive-2540957.html. The problem was that the crucial traffic was encrypted with symmetric-key algorithm, and the key could be retrieved using reverse engineering methods. The key was the same for all cars (shared secret) and while you get the key from one car you can use it in other cars confidently. In addition all commands were sent over HTTP, SSL was not used. That allows spoofing, emulating command of door opening and performing MiTM attacks. You can read more if you follow the link.

Various attack vectors

RDS Spoofing

RDS/TMC parsing is often performed by navigation software in HU. The most popular problem is obvious spoofing - https://www.blackhat.com/presentations/bh-usa-07/Barisani_and_Bianco/Presentation/bh-usa-07-barisani_and_bianco.pdf. TMC data is not encrypted and is transferred as is (the problem is solved only for "commercial" radio stations, where private keys are used). Thus any hacker with HackRF can spoof broadcasted traffic reports. Also you can do some fuzzing and use vulnerabilities in format parsing. Though TMC is unhappy target for fuzzing, but there is a nonzero probability to find something like BoF in Radio Text.

v2v

I'd like also to say something about v2v technology. I like the idea of the worm that will be copied from one car to another. For example, Wi-Fi (IEEE 802.11p) maybe the way to implement it. I hope that by  time it will be widely distributed they will learn not to assign service’s interfaces to 0.0.0.0 and not to open SSH ports, otherwise interesting worm samples will be created:)

The dream of future virus maker...

Hybrid worm

While talking about car worms on DefconRussia other funny vectors were presented like exploiting software in car service centres (MRO). Imagine, while the technician is examining the car, that car infects technician's workstation using vulnerabilities in car diagnostic software. Next client is arriving to service centre and now the technician infects his or her car. I'd like to add that IVI/HU of one family and generation can be installed on different cars (even vendors) which make our hypothetical worm's task much easier.

Internet services security is also an interesting subject. If you control Internet proxy of ConnectedCar or its API backend which is located in the Internet than you control all ConnectedCar traffic: updates, registration and other features. Once again, ConnectedCar and HU security issues are similar to mobile security.

Worm concept in theory.

Future is coming - cars without a driver.

And now for something you have seen only in fiction before - robotic cars. All world is waiting for the self-driving cars will be completely introduced at 2040. So today we are creating basis for future engineers  and security topic are not on the last place. By that time attack vectors and their profit will change. It is hard to predict what will be HU like at 2040, but we can assume that decision making and navigation algorithms won’t change completely. I hope that by 2040 all these things that were showed on  conferences nowadays will become ordinary and obligatory for vendors in the future (and, of course, mitigated). I’ve talk to some information security experts in automotive industry, including German manufacturers, and I assure you that they are up to date on all hacking techniques and definitely are on the right track (but can’t say for all of course).

This is the future as I see it.

Is it so bad as it seems? Have at you now!

Now I would like to talk about basic protection techniques of HU and car network. They are quite diverse because some manufacturers see one group of threats and some see another. For example, it is important for client HU to get updates. If some bug is found, the update of all firmware or some component should be installed (otherwise recall of all car lot will cost a pretty penny, so updates over-the-air is a good idea). Of course this update process must be secured as well by using digital signatures, certificates and so on. Anyway the progress in this area is made and almost all cars will have update-over-the-air and that's good.

There is a trend towards OS isolation from network and hardware resources. Isolation can be expressed differently: from network segmentation up to full OS virtualization. But problems persists and if OS needs  access to door lock ECU, cruise control or OBD-II it will get it, hence there is a way to control door locks, drive mode and get other information about car state. Virtualization hasn't entered our lives completely yet and today we have quite common problems: absence of ASLR/NX, improper access permissions to local files and so on. Keychain is not installed everywhere and many applications have to store secret keys at HU’s filesystem. So  secure storage is in demand from IVI in  same way as from smartphones. Have nothing to say about SELinux - I understand that it demands too much resources for embedded system and I have not seen it on IVI. Also I can't see the reason to have SSH on HU at production stage (but it is worth to say that situation started to turn and now it's more and more difficult to find SSH. Now developers turn it on only during the release stage for their own purposes). A lack of hardening is becoming obvious - when you see web browser runs as root (but to  be honest and fair, developers are fixing these kind of issues on very early stage of development, so should be rare in production now).

As an aside, it is worth mentioning problem of integrity. From my point of view even if someone have executed malicious code on HU, he or she shouldn't been given any chance to save a backdoor even with root privileges. Some manufacturers ignore this problem and makes it possible to mount  filesystem in rw mode, but some IVIs will reboot with any attempt to change anything in its configuration.

Virtualization

Let's talk about virtualization as a solution to all problems. One of the fundamental protection policies for OS with entertainment applications, as I've said before, is virtualization. I think that in N years it will be applied by all manufacturers in some way. Advantages are clear:  app OS will be isolated from the main vehicle system and “important system” OS, including isolation on network level. But if such app OS will be compromised  attacker still can get some valuable data. First of all, it will be user data that is processed on that level. That’s enough to consider this attack as successful - because you are getting all data from the sensors: the location, the endpoint, application data; at least Facebook access token worth hacking HU! Secondly, some API, for example, display UI will be still accessible from virtualized OS and that will allow to continue attack "down".  Virtualization approach seems right to me because it complicates tasks of attacker.

Instead of conclusion.

I've written quite a lot but nothing concrete. Nevertheless my aim was to draw your attention to key components: Head Unit (and I mean IVI), describe the corresponding risks and what actions vendors and developers take to minimize them. Today there is a plenty of information about CAN networks: some resources have shared access, some ECUs are vulnerable to DoS and brute force attacks or you can even read data from them. But all these attacks don't have practical application if you want to perform "remote attack on car from the Internet". I only tried to show  current situation in car industry, the main target and some of its problems (taking into account Connected Car features) in my humble opinion. I didn't want to scare or encourage anyone so this note does not apply to be vendors advertisement and was not made to convince you that "wow, hackers can hack everything!". But they definitely can and this summer on Black Hat in Las Vegas same guys Charlie and Chris will show remote penetration on real car, get access to CAN, gain control over critical ECU - https://www.blackhat.com/us-15/briefings.html#Chris-Valasek. I don't know if the HU is used as entry point or for privilege escalation, but the show will be spectacular and will demonstrate real capabilities :)  Secure driving to you!

UPD:  Now we have more details about Charlie and Chris attack (http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/), and i can say that HU/IVI system was involved, looks like Cruise Control or and access to CAN but believe that more technical details  will be disclosed on BlackHat!