July 2, 2015 at 13:12Head Unit - as a target for a hacker
Recently, more and more often the topic of hacker threats in the automotive world has been raised. Moreover, this topic excites everyone - auto manufacturers, OEMs, information security consultants, and, of course, the authorities of the European Union and the USA are interested in this topic (they even give research grants, etc.). Since in the IS industry very often all the motions are an attempt to "scare", I would like to understand the situation "now" and the potential situation in the "future" without unnecessary pathos and paranoia, although in our business it is better to "overdo it" than "not overdo it" . In the course of my work, I am involved in the security of ConnectedCar systems, including Embedded products for Automotive systems. And in light of the foregoing, I would like to talk about the near future and the new risks associated with IoT, cars and hackers.
Why did I focus on the Head Unit? Yes, of course, there are many delicious goals in the Car Network, and much more critical in terms of control. Still, the HU (hereinafter referred to as the Head Unit, or even more precisely IVI - in-vehicle infotainment, if we talk about the logical component) is an entertainment system, navigation, and management of non-critical things, such as air conditioning and interior lighting. In a normal car, the HU does not have a direct connection to critical ECUs (ECU - a controller that controls a certain node - engine subsystem, power supply, ABS, etc.). Nevertheless, in view of the “computerization” of management, interesting things are obtained - opening door locks, a window regulator or a trunk is controlled by HU, which is already more “critical”. So it’s not so simple. The second - there is no “direct network connection” via CAN, but does not mean that there is no logical connection with critical ECUs. For example, there are such schemes where HU is connected to a certain CAN gateway, and from the gateway there is already access to more interesting things. Here I would give an analogy with the “internal penetration test”, that is, already having access to the HU, you crack the intermediate link - the gateway, and from this gateway you go and attack some important ECU. I will not delve into the problems of CAN security and access to the ECU, all this has long been known, and Charlie Miller and Chris Valasik (by the way, I drank beer with him at CONFidence 2011, this has nothing to do with the matter and he hardly even remembers me but hunting still boasts, so I’ll mention it here) they even reviewed these problems, including authentication problems and bruteforce for the ECU via the CAN bus, so anyone who has not had time to familiarize themselves with this can where HU is connected to a certain CAN gateway, and from the gateway there is already access to more interesting things. Here I would give an analogy with the “internal penetration test”, that is, already having access to the HU, you crack the intermediate link - the gateway, and from this gateway you go and attack some important ECU. I will not delve into the problems of CAN security and access to the ECU, all this has long been known, and Charlie Miller and Chris Valasik (by the way, I drank beer with him at CONFidence 2011, this has nothing to do with the matter and he hardly even remembers me but hunting still boasts, so I’ll mention it here) they even reviewed these problems, including authentication problems and bruteforce for the ECU via the CAN bus, so anyone who has not had time to familiarize themselves with this can where HU is connected to a certain CAN gateway, and from the gateway there is already access to more interesting things. Here I would give an analogy with the “internal penetration test”, that is, already having access to the HU, you crack the intermediate link - the gateway, and from this gateway you go and attack some important ECU. I will not delve into the problems of CAN security and access to the ECU, all this has long been known, and Charlie Miller and Chris Valasik (by the way, I drank beer with him at CONFidence 2011, this has nothing to do with the matter and he hardly even remembers me but hunting still boasts, so I’ll mention it here) they even reviewed these problems, including authentication problems and bruteforce for the ECU via the CAN bus, so anyone who has not had time to familiarize themselves with this can Here I would give an analogy with the “internal penetration test”, that is, already having access to the HU, you crack the intermediate link - the gateway, and from this gateway you go and attack some important ECU. I will not delve into the problems of CAN security and access to the ECU, all this has long been known, and Charlie Miller and Chris Valasik (by the way, I drank beer with him at CONFidence 2011, this has nothing to do with the matter and he hardly even remembers me but hunting still boasts, so I’ll mention it here) they even reviewed these problems, including authentication problems and bruteforce for the ECU via the CAN bus, so anyone who has not had time to familiarize themselves with this can Here I would give an analogy with the “internal penetration test”, that is, already having access to the HU, you crack the intermediate link - the gateway, and from this gateway you go and attack some important ECU. I will not delve into the problems of CAN security and access to the ECU, all this has long been known, and Charlie Miller and Chris Valasik (by the way, I drank beer with him at CONFidence 2011, this has nothing to do with the matter and he hardly even remembers me but hunting still boasts, so I’ll mention it here) they even reviewed these problems, including authentication problems and bruteforce for the ECU via the CAN bus, so anyone who has not had time to familiarize themselves with this canto do here . In short, whatever one may say, but HU is a very good entry point. This is the most convenient goal for me, and I can explain why:
1) User info
It is on HU that we have an OS that has access to the data of the user himself. After all, an attack on a car can be part of an attack for the user - espionage, for example. By the way, it should be said that almost the entire so-called User Expiernce is concentrated in HU, for example, such a feature as automatic payment for parking, or fuel, which means more interesting data.
2) A convenient place for fixing in the system - a place for BackDoor.
On HU, usually everything is mounted in ReadOnly - but there are options for how to gain a foothold in the system, that is, make BackDoor and have constant access to the network. Yes, technically, there may be difficulties in overcoming the protection of the vendor, but in the end it is the most convenient place for fixing in the system with subsequent stable access. Add that HU OS can be QNX, Linux, or even Windows CE!
3) Attack development
It also follows from point 2. It is with the HU that it is convenient to attack the ECU (Gateway) to increase privileges and other evils. It should be added that it is HU that has the most powerful computers in terms of performance for cars, there may be different CPUs and RAM and different OSs from different car manufacturers, but in general (since you need to render some kind of GUI there, work with network traffic , play music and do it all in parallel) it is obvious that they use quite powerful pieces of iron from the Embeded point of view. As a rule, ARM Cortex 6, for example, Tegra 2 or 3. Anything can be.
4) Convenient location for remote attack
In sophisticated cars, HU has many applications, many network connections to the Internet, not to mention USB, BT and Wi Fi. That is, it is a little easier to attack than, say, Wirless TPMS, since in the first case there are many different vectors, including from the Internet.
Car safety is almost the same as ICS security, only with PLC controllers are we connected to a smartphone that is connected to the Internet =)
Summing up all this “analytics” I found out for myself that HU is the most delicious and desired goal although there are undoubtedly many other goals and possibilities - baseband GSM modem, Wirless TMPS, direct access to CAN (local attack), attack on sensors and radars, etc. In other words, car security is not IoT security, or rather not only.
Before continuing, I would like to ask a good question - why, actually, can anyone be interested in hacking an unhappy car? In general, there are several options:
1) Espionage
Targeted attack on a specific person. For example, monitor his movements without a “physical bug”. It is true why duplicate the functionality of a car. In a modern car, everything is already there: GPS, GSM, Wi-Fi and BT. It is only necessary to “securely” fix everything, and if this can be done remotely, without physical intervention, all the better. The price of the attack, for my taste, is still high for such a goal, but let's not guess and play analysts - there is an architectural opportunity. In addition, there are options to attack ConnectedCar on the Internet, without interacting with the car itself, but more on that later. In principle, in order not to produce points, here you can also enter the ability to access the payment functions, which I already mentioned.
2) Destructive actions
In general, the goal is rather dubious, but again - ABS disabled at the right time is a rather dangerous thing. Thus, an EM gun can very well bring out all the electronics of a car at the right time, at the right speed, in the right place (at a sharp bend) - this can be very dangerous. Such facts have already been in the history of the automotive industry, although the attacks were random (EM pickups from base stations). Accordingly, if the ECU can be output "programmatically", then in potential we can get the same effect. But still, this is an option for the film, rather.
3) Unauthorized physical access
We can say about hijacking, a rather "natural" vector, though rather related to local physical attacks and vulnerabilities of the "local network". Nevertheless, the MiTM version has already been demonstrated in practice and, as a result, “opening the doors of a car”.
Next, let's talk about less obvious vectors:
4) Route manipulation
So far, cars on autopilot are only in the testing and refinement phase, but nevertheless, even without this uber feature, we can manipulate the route - provided that the driver trusts what he says navigator. And if the navigator says that the road is closed, there is a traffic jam and you need to go differently, that is, there is far from a zero chance that the driver will agree.
5) “Locker”
Purely for humor, when we discussed these problems at the 21st meeting of DefconRussia , the idea of monetization, the “locker,” was proposed. You get into the car, start, and on the screen there is a red veil and a hellish font demanding to send money to the next number in order to unlock HU. It's funny that in this context, the “locker” can still really “block” doors, windows and anything else 8) In the case of any mass vulnerability or an unscrupulous maintenance center, it’s quite a working option.
Enough for a start. I think you can think of something else, and I propose to do in the comments ...
In this part, we’ll talk about the possibilities of attacks. I will say right away that I will speak purely theoretically, but nevertheless, much of what has been said is the experience of real practical attacks on real systems. For obvious reasons, I will not talk about that part of my work on NDA, but I will make a squeeze in the form of conclusions about the existence of such vectors so that I can imagine what kind of attacks are possible in theory. First, a little about the HU device. As a rule, this is a box with outputs for various panels, displays, sensors, GSM / 3G modem, card / USB input, bluetooth device, etc. Inside this box is memory, ROM and, of course, the CPU, usually on an ARM chip. There we also have the main entertainment OS with all the tricks: navigation, control of some elements of the cabin (yeah, door locks, for example, or a power window), video / mp3 player, sometimes even a web browser ... I want to make a reservation and say that HU are very different from different manufacturers and from different generations of products. Somewhere there are several CPUs and OSs, where there is even a hypervisor and the OS with all the user good is generally virtualized. I can confidently say that the German auto industry follows the path of "isolating the user from the car," although this is still a thorny path. In the simplest case, this box will have a common OS, but all the same, the HU itself is “isolated” at the network level, which I also mentioned.
OSs are different, and I already wrote about QNX, Linux, and so on. In IVI, it is not necessary to have a RealTime OS if there are no corresponding tasks (and there are rarely such cases that RealTime is directly needed), but QNX is used by some manufacturers there (HARMAN, the most striking example). If we talk about Linux, then GENVI and Tizen are prominent representatives.
About isolation at the network level: HU is somehow connected to the ODB connector, which, in turn, is connected to the switch. In addition, usually there is still access to the audio system, telephony (usually the MOST bus is used here), and yes, there are direct CAN connections to some ECUs. Where, then, can an attacker make an effort to penetrate and gain a foothold in HU?
Let's start with the simplest thing - local interfaces allow you to interact with the OS of its services and applications. The vector seems rather dubious, because the attacker should somehow get closer to these interfaces, but nevertheless, one more thing needs to be understood - many “secrets” are hidden exactly on the client “device”, that is, certificates and passwords that (already proved, and more than once) are shared and universal for the entire class of systems. Yes, yes, the approach - “no one should know, and then everything is in order” (Security Through Observation) is a fairly common feature in the automotive industry 8) In addition to this goal, there are also hybrid attacks on local interfaces, that is, in fact, the source of the attack may be remote, but the penetration mechanism is local: for example, you downloaded an Mp3 file that has tags and tags (let's say there’s a BoF split), uploaded to HU,here- even there was, although not in detail). There can be quite a lot of such topics: map updates, POIs, fake updates ... In addition to directly “attacks through file format parsing errors,” there are unexpected options for exploiting errors in the update logic, for example, maps of a navigation system. Well, local interfaces are not only files and imports: these are BlueTooth, WiFI hotspot (yes, there are such features!) And USB. For example, it turned out to be a fairly popular decision to make EthrenetOverUSB. That is, USB is quite an Ethernet input to the local HU network. Next, we’ll hook up on SSH, log in as root (remember that one password for all machines ...) and that’s all, the song is sung. And the same thing via Wi-Fi hotspot - such as HU opens such a hotspot and exposes its SSH out. I’ll say it again - this is not just speculation,http://www.mazda3hacks.com/doku.php?id=notes:sshnotes I also saw this with other vendors. So I'm waiting for the hackers to find more good, and they will find!).
The most delicious vector is through the Internet, and there are a lot of opportunities, and these opportunities are only growing. Here you can start with the classics of client-side attacks, the same browser and its plug-ins. Yes, it has long been fashionable to have a browser in the car that can read PDFs and Word! This may be a certain assembly of WebKit, well, or Chrome, so the classic problems and difficulties are on the face. It will not be superfluous to say that it also happens that the browser may well work from root. But this is all more or less obvious and understandable (except for the browser from root, I refuse to understand this). In addition to the browser, there are a bunch of applications using the Internet and services, from Navigation to Facebook.
I want to say a little about HTML5 security and WEB technologies - for some reason, these things become “built-in” and the whole ConnectedCar logic rests on them. Now just imagine what SSRF / CSRF or XSS can lead to? So, if, for example, the HU interface and all the garbage, including applications, are HTML5 + JS, then having XSS, we get access to the internal API - vehicle coordinates, VIN, fuel supply, current speed and more, which usually turns into an API from sensors . And if we talk about CSRF / SSRF, then we can interact with the internal API - and manipulate something inside the car (if not the ECU, then navigation logic, profiles, applications, or develop an attack yet). This is especially unpleasant, considering the ConnectedCar services - binding a car to a service and remote manipulation or access to data.
As an example, a recent BMW hacking incident . The problem was that important traffic was encrypted with a symmetric key, which can be pulled out using the methods of what is now fashionably said to be “reverse engineering”. With this key, data was encrypted for all cars, so pulling out such a key from one car, you can safely use it for everyone else. The data and commands themselves were transmitted via HTTP, no SSL. Actually, all this allowed us to spoof and emulate the “open doors” command, to carry out MiTM - if figuratively, see the details for the link.
In general, there are many different vectors
Not really a HU problem, but on the other hand, RDS / TMC parsing often takes place in a navigation software that works exactly where we need it. The most famous problem is banal spoofing . The fact is that TMC data is not encrypted, and transmitted as is (this problem is solved only for "private" and "digital" radio, where private keys are used). Thus, any hacker with HackRF can spoof false data on traffic jams and traffic conditions on the air. But besides this vector, RDS can be fuzzed for vulnerabilities in format processing, although there is nothing special in TMC to fuzz, but in Radio Text, for example, the probability of BoF or something like that may not be zero.
Separately, I note the v2v network technology. I really like the idea of a worm that will jump from car to car - think for yourself, for example, Wi-Fi (IEEE 802.11p) is one of the solutions. I hope that by this time they will learn not to roll out network interfaces to 0.0.0.0 and open SSH, otherwise there will be a very interesting instance of the worm 8) The
dream of the virmaker of the near future ...
Continuing the theme of worms, for cars, on the same DefconRussia funny vectors were revealed, including the operation of service software in Sevris centers. A car arrives, a technician makes diagnostics, a machine infects a technician's workstation through vulnerabilities in software. The next client arrives at the same service center, and already the technician infects the car. I want to say separately that it is very often possible to meet a situation where IVI / HUs of the same family and generation are installed on cars of different brands, which simplifies the task of a hypothetical worm.
Well and speaking about Internet services - everything is also very interesting. Think, if you forget the ConnectedCar Internet proxy or the API backend, which is on the Internet, then the traffic of the machines (updates, registration, some features of the ConnectedCar) will be under your control. Again, there are a lot of similarities with mobile security, and ConnectedCar and HU have the same problems.
Worms, so far only in theory ...
What would not be completely boring was a little about what used to be fiction - robotic cars. The world expects that in 2040 this technology will be successfully implemented, which means that what we are doing now will become a platform for engineers of the future and security issues are not in last place here. After all, then the attack vectors and the profit from them will be completely different. It is difficult to say what HU will be in 2040, but one can guess that the whole logic of navigation and decision-making will be somewhere nearby, so I would like that what I am writing about now and what hackers show at conferences in 2040 would be “obvious »And protected as something ordinary and elementary (after talking with security experts who work for the auto industry, at least specifically German, I can say that they are aware of all this and on the right track, which pleases).
I see the future exactly 8)
I would also like to write about how HU and the auto network are protected (each has its own, but so to speak, basic approaches). These approaches are quite different, who see some risks, some others, but overall there is progress and it will only grow.
For example, in the current situation, it is necessary and important to have an update mechanism (on the client HU). If they find a bug, or what happens, you need to quickly deliver the update, update the entire firmware or component (otherwise, you can get a pretty penny on the recall of machines). Moreover, such a process should be quite protected. Signature, certificate - all matters. In general, there is progress in this matter and this is good.
Regarding the protection of HU itself, things are very different for everyone, but there is a general tendency to move towards isolating the OS as far as possible from the main network and processes. For example, they isolate not only at the level of network segmentation, but also up to the full virtualization of the OS. But in general, the problem is and will be - if the OS needs to have access to the ECU of the locks, then it will also have a cruise control or OBD-II, which means there will be a way to manage the locks, influence the driving mode and access to status auto. But while virtualization has not entered our life so tightly, we have rather common problems: lack of ASLR, wrong access rights to local files, etc. Not everyone has a keychain, and many applications need to store user secrets on HU, so the availability of secure storage is as popular in IVI as on smartphones. I'm not talking about SELinux, I understand that it can be hard, but still. And the same SSH - it is not needed at all on HU in production, for what reason it is there - is not clear (by the way, I want to add for honesty that the situation is changing, and now it has become more difficult to meet SSH - it is only included on development releases) . In general, the hardening problem for vendors is on the face: forgive me for the root browser (by the way, to be honest, this is also becoming a rare problem now, the developers are not stupid and everyone understands and corrects the same thing).
Separately, there is an interesting task of maintaining integrity. From my point of view, even if someone was able to execute code on the HU, he should not have the opportunity to gain a foothold in the system, even if he is root. But in practice, someone clogs up with these problems and the FS can be remounted with rw rights, while for someone HU will go into reboot at the slightest attempt to change at least something in the configuration.
And a little about virualization, as a solution to all problems. One of the main strategies for protecting an OS with "entertainment" applications, as mentioned above, is its virilization. I think in N years, one way or another it will be implemented by all many manufacturers. The advantages here, of course, are obvious: such an OS is isolated from the main auto-system, including at the network level. This is undoubtedly true, but even if such an OS is compromised, the attacker may already receive something of value. Firstly, the user data that is processed in this isolation layer, and this is enough to consider a “hack” successful - data from sensors, coordinates, destination, application data ... finally, FaceBook access token, for the sake of this, it was worth breaking HU ! Secondly, certain APIs and services will be “thrown” into the virtualized environment, including one way or another UI display, which allows in any case to develop an attack, including "down". Ultimately, it depends on many factors and each system needs to be considered separately, but in general, this approach seems to me to be true, since it complicates the task of the attacker anyway ...
I wrote a lot, but it seems nothing concrete. Nevertheless, I wanted to draw attention to one of the key objects - the Head Unit and IVI, what risks are waiting there, why and what developers / vendors are doing with it. Now there is enough information about the problems of CAN networks: general access, some ECUs can be docked and brutalized, and even more so, data can be taken, etc. But all these attacks and examples are divorced from concrete practical application in the context of the "remote attack on a car from the Internet." I wanted to show, as it seems to me, the main goal and only some of its problems (especially considering the Connected Car features) and the current situation in the industry (in my humble opinion). I didn’t want to frighten or reassure anyone, so this article does not pretend to be a vendor advertisement or a “wow, hackers can break everything, how scary to live.” But, of course they can break,Chris and Charlie will demonstrate a remote attack vector for a real car in full - remote penetration, gaining access to CAN, impact on critical ECUs. I don’t know if HU will be affected as an entry point or privilege escalation, and what kind of attack it will be, but the show will certainly come out good, and most importantly, demonstrate real features 8) All have a safe ride!
Is the Head Unit a sweet target?
Why did I focus on the Head Unit? Yes, of course, there are many delicious goals in the Car Network, and much more critical in terms of control. Still, the HU (hereinafter referred to as the Head Unit, or even more precisely IVI - in-vehicle infotainment, if we talk about the logical component) is an entertainment system, navigation, and management of non-critical things, such as air conditioning and interior lighting. In a normal car, the HU does not have a direct connection to critical ECUs (ECU - a controller that controls a certain node - engine subsystem, power supply, ABS, etc.). Nevertheless, in view of the “computerization” of management, interesting things are obtained - opening door locks, a window regulator or a trunk is controlled by HU, which is already more “critical”. So it’s not so simple. The second - there is no “direct network connection” via CAN, but does not mean that there is no logical connection with critical ECUs. For example, there are such schemes where HU is connected to a certain CAN gateway, and from the gateway there is already access to more interesting things. Here I would give an analogy with the “internal penetration test”, that is, already having access to the HU, you crack the intermediate link - the gateway, and from this gateway you go and attack some important ECU. I will not delve into the problems of CAN security and access to the ECU, all this has long been known, and Charlie Miller and Chris Valasik (by the way, I drank beer with him at CONFidence 2011, this has nothing to do with the matter and he hardly even remembers me but hunting still boasts, so I’ll mention it here) they even reviewed these problems, including authentication problems and bruteforce for the ECU via the CAN bus, so anyone who has not had time to familiarize themselves with this can where HU is connected to a certain CAN gateway, and from the gateway there is already access to more interesting things. Here I would give an analogy with the “internal penetration test”, that is, already having access to the HU, you crack the intermediate link - the gateway, and from this gateway you go and attack some important ECU. I will not delve into the problems of CAN security and access to the ECU, all this has long been known, and Charlie Miller and Chris Valasik (by the way, I drank beer with him at CONFidence 2011, this has nothing to do with the matter and he hardly even remembers me but hunting still boasts, so I’ll mention it here) they even reviewed these problems, including authentication problems and bruteforce for the ECU via the CAN bus, so anyone who has not had time to familiarize themselves with this can where HU is connected to a certain CAN gateway, and from the gateway there is already access to more interesting things. Here I would give an analogy with the “internal penetration test”, that is, already having access to the HU, you crack the intermediate link - the gateway, and from this gateway you go and attack some important ECU. I will not delve into the problems of CAN security and access to the ECU, all this has long been known, and Charlie Miller and Chris Valasik (by the way, I drank beer with him at CONFidence 2011, this has nothing to do with the matter and he hardly even remembers me but hunting still boasts, so I’ll mention it here) they even reviewed these problems, including authentication problems and bruteforce for the ECU via the CAN bus, so anyone who has not had time to familiarize themselves with this can Here I would give an analogy with the “internal penetration test”, that is, already having access to the HU, you crack the intermediate link - the gateway, and from this gateway you go and attack some important ECU. I will not delve into the problems of CAN security and access to the ECU, all this has long been known, and Charlie Miller and Chris Valasik (by the way, I drank beer with him at CONFidence 2011, this has nothing to do with the matter and he hardly even remembers me but hunting still boasts, so I’ll mention it here) they even reviewed these problems, including authentication problems and bruteforce for the ECU via the CAN bus, so anyone who has not had time to familiarize themselves with this can Here I would give an analogy with the “internal penetration test”, that is, already having access to the HU, you crack the intermediate link - the gateway, and from this gateway you go and attack some important ECU. I will not delve into the problems of CAN security and access to the ECU, all this has long been known, and Charlie Miller and Chris Valasik (by the way, I drank beer with him at CONFidence 2011, this has nothing to do with the matter and he hardly even remembers me but hunting still boasts, so I’ll mention it here) they even reviewed these problems, including authentication problems and bruteforce for the ECU via the CAN bus, so anyone who has not had time to familiarize themselves with this canto do here . In short, whatever one may say, but HU is a very good entry point. This is the most convenient goal for me, and I can explain why:
1) User info
It is on HU that we have an OS that has access to the data of the user himself. After all, an attack on a car can be part of an attack for the user - espionage, for example. By the way, it should be said that almost the entire so-called User Expiernce is concentrated in HU, for example, such a feature as automatic payment for parking, or fuel, which means more interesting data.
2) A convenient place for fixing in the system - a place for BackDoor.
On HU, usually everything is mounted in ReadOnly - but there are options for how to gain a foothold in the system, that is, make BackDoor and have constant access to the network. Yes, technically, there may be difficulties in overcoming the protection of the vendor, but in the end it is the most convenient place for fixing in the system with subsequent stable access. Add that HU OS can be QNX, Linux, or even Windows CE!
3) Attack development
It also follows from point 2. It is with the HU that it is convenient to attack the ECU (Gateway) to increase privileges and other evils. It should be added that it is HU that has the most powerful computers in terms of performance for cars, there may be different CPUs and RAM and different OSs from different car manufacturers, but in general (since you need to render some kind of GUI there, work with network traffic , play music and do it all in parallel) it is obvious that they use quite powerful pieces of iron from the Embeded point of view. As a rule, ARM Cortex 6, for example, Tegra 2 or 3. Anything can be.
4) Convenient location for remote attack
In sophisticated cars, HU has many applications, many network connections to the Internet, not to mention USB, BT and Wi Fi. That is, it is a little easier to attack than, say, Wirless TPMS, since in the first case there are many different vectors, including from the Internet.
Car safety is almost the same as ICS security, only with PLC controllers are we connected to a smartphone that is connected to the Internet =)
Summing up all this “analytics” I found out for myself that HU is the most delicious and desired goal although there are undoubtedly many other goals and possibilities - baseband GSM modem, Wirless TMPS, direct access to CAN (local attack), attack on sensors and radars, etc. In other words, car security is not IoT security, or rather not only.
What for?
Before continuing, I would like to ask a good question - why, actually, can anyone be interested in hacking an unhappy car? In general, there are several options:
1) Espionage
Targeted attack on a specific person. For example, monitor his movements without a “physical bug”. It is true why duplicate the functionality of a car. In a modern car, everything is already there: GPS, GSM, Wi-Fi and BT. It is only necessary to “securely” fix everything, and if this can be done remotely, without physical intervention, all the better. The price of the attack, for my taste, is still high for such a goal, but let's not guess and play analysts - there is an architectural opportunity. In addition, there are options to attack ConnectedCar on the Internet, without interacting with the car itself, but more on that later. In principle, in order not to produce points, here you can also enter the ability to access the payment functions, which I already mentioned.
2) Destructive actions
In general, the goal is rather dubious, but again - ABS disabled at the right time is a rather dangerous thing. Thus, an EM gun can very well bring out all the electronics of a car at the right time, at the right speed, in the right place (at a sharp bend) - this can be very dangerous. Such facts have already been in the history of the automotive industry, although the attacks were random (EM pickups from base stations). Accordingly, if the ECU can be output "programmatically", then in potential we can get the same effect. But still, this is an option for the film, rather.
3) Unauthorized physical access
We can say about hijacking, a rather "natural" vector, though rather related to local physical attacks and vulnerabilities of the "local network". Nevertheless, the MiTM version has already been demonstrated in practice and, as a result, “opening the doors of a car”.
Next, let's talk about less obvious vectors:
4) Route manipulation
So far, cars on autopilot are only in the testing and refinement phase, but nevertheless, even without this uber feature, we can manipulate the route - provided that the driver trusts what he says navigator. And if the navigator says that the road is closed, there is a traffic jam and you need to go differently, that is, there is far from a zero chance that the driver will agree.
5) “Locker”
Purely for humor, when we discussed these problems at the 21st meeting of DefconRussia , the idea of monetization, the “locker,” was proposed. You get into the car, start, and on the screen there is a red veil and a hellish font demanding to send money to the next number in order to unlock HU. It's funny that in this context, the “locker” can still really “block” doors, windows and anything else 8) In the case of any mass vulnerability or an unscrupulous maintenance center, it’s quite a working option.
Enough for a start. I think you can think of something else, and I propose to do in the comments ...
HU attack vectors
In this part, we’ll talk about the possibilities of attacks. I will say right away that I will speak purely theoretically, but nevertheless, much of what has been said is the experience of real practical attacks on real systems. For obvious reasons, I will not talk about that part of my work on NDA, but I will make a squeeze in the form of conclusions about the existence of such vectors so that I can imagine what kind of attacks are possible in theory. First, a little about the HU device. As a rule, this is a box with outputs for various panels, displays, sensors, GSM / 3G modem, card / USB input, bluetooth device, etc. Inside this box is memory, ROM and, of course, the CPU, usually on an ARM chip. There we also have the main entertainment OS with all the tricks: navigation, control of some elements of the cabin (yeah, door locks, for example, or a power window), video / mp3 player, sometimes even a web browser ... I want to make a reservation and say that HU are very different from different manufacturers and from different generations of products. Somewhere there are several CPUs and OSs, where there is even a hypervisor and the OS with all the user good is generally virtualized. I can confidently say that the German auto industry follows the path of "isolating the user from the car," although this is still a thorny path. In the simplest case, this box will have a common OS, but all the same, the HU itself is “isolated” at the network level, which I also mentioned.
OSs are different, and I already wrote about QNX, Linux, and so on. In IVI, it is not necessary to have a RealTime OS if there are no corresponding tasks (and there are rarely such cases that RealTime is directly needed), but QNX is used by some manufacturers there (HARMAN, the most striking example). If we talk about Linux, then GENVI and Tizen are prominent representatives.
About isolation at the network level: HU is somehow connected to the ODB connector, which, in turn, is connected to the switch. In addition, usually there is still access to the audio system, telephony (usually the MOST bus is used here), and yes, there are direct CAN connections to some ECUs. Where, then, can an attacker make an effort to penetrate and gain a foothold in HU?
Local interfaces
Let's start with the simplest thing - local interfaces allow you to interact with the OS of its services and applications. The vector seems rather dubious, because the attacker should somehow get closer to these interfaces, but nevertheless, one more thing needs to be understood - many “secrets” are hidden exactly on the client “device”, that is, certificates and passwords that (already proved, and more than once) are shared and universal for the entire class of systems. Yes, yes, the approach - “no one should know, and then everything is in order” (Security Through Observation) is a fairly common feature in the automotive industry 8) In addition to this goal, there are also hybrid attacks on local interfaces, that is, in fact, the source of the attack may be remote, but the penetration mechanism is local: for example, you downloaded an Mp3 file that has tags and tags (let's say there’s a BoF split), uploaded to HU,here- even there was, although not in detail). There can be quite a lot of such topics: map updates, POIs, fake updates ... In addition to directly “attacks through file format parsing errors,” there are unexpected options for exploiting errors in the update logic, for example, maps of a navigation system. Well, local interfaces are not only files and imports: these are BlueTooth, WiFI hotspot (yes, there are such features!) And USB. For example, it turned out to be a fairly popular decision to make EthrenetOverUSB. That is, USB is quite an Ethernet input to the local HU network. Next, we’ll hook up on SSH, log in as root (remember that one password for all machines ...) and that’s all, the song is sung. And the same thing via Wi-Fi hotspot - such as HU opens such a hotspot and exposes its SSH out. I’ll say it again - this is not just speculation,http://www.mazda3hacks.com/doku.php?id=notes:sshnotes I also saw this with other vendors. So I'm waiting for the hackers to find more good, and they will find!).
Attack through applications in the name of IoT
The most delicious vector is through the Internet, and there are a lot of opportunities, and these opportunities are only growing. Here you can start with the classics of client-side attacks, the same browser and its plug-ins. Yes, it has long been fashionable to have a browser in the car that can read PDFs and Word! This may be a certain assembly of WebKit, well, or Chrome, so the classic problems and difficulties are on the face. It will not be superfluous to say that it also happens that the browser may well work from root. But this is all more or less obvious and understandable (except for the browser from root, I refuse to understand this). In addition to the browser, there are a bunch of applications using the Internet and services, from Navigation to Facebook.
I want to say a little about HTML5 security and WEB technologies - for some reason, these things become “built-in” and the whole ConnectedCar logic rests on them. Now just imagine what SSRF / CSRF or XSS can lead to? So, if, for example, the HU interface and all the garbage, including applications, are HTML5 + JS, then having XSS, we get access to the internal API - vehicle coordinates, VIN, fuel supply, current speed and more, which usually turns into an API from sensors . And if we talk about CSRF / SSRF, then we can interact with the internal API - and manipulate something inside the car (if not the ECU, then navigation logic, profiles, applications, or develop an attack yet). This is especially unpleasant, considering the ConnectedCar services - binding a car to a service and remote manipulation or access to data.
As an example, a recent BMW hacking incident . The problem was that important traffic was encrypted with a symmetric key, which can be pulled out using the methods of what is now fashionably said to be “reverse engineering”. With this key, data was encrypted for all cars, so pulling out such a key from one car, you can safely use it for everyone else. The data and commands themselves were transmitted via HTTP, no SSL. Actually, all this allowed us to spoof and emulate the “open doors” command, to carry out MiTM - if figuratively, see the details for the link.
In general, there are many different vectors
RDS Spoofing
Not really a HU problem, but on the other hand, RDS / TMC parsing often takes place in a navigation software that works exactly where we need it. The most famous problem is banal spoofing . The fact is that TMC data is not encrypted, and transmitted as is (this problem is solved only for "private" and "digital" radio, where private keys are used). Thus, any hacker with HackRF can spoof false data on traffic jams and traffic conditions on the air. But besides this vector, RDS can be fuzzed for vulnerabilities in format processing, although there is nothing special in TMC to fuzz, but in Radio Text, for example, the probability of BoF or something like that may not be zero.
v2v
Separately, I note the v2v network technology. I really like the idea of a worm that will jump from car to car - think for yourself, for example, Wi-Fi (IEEE 802.11p) is one of the solutions. I hope that by this time they will learn not to roll out network interfaces to 0.0.0.0 and open SSH, otherwise there will be a very interesting instance of the worm 8) The
dream of the virmaker of the near future ...
Hybrid worms
Continuing the theme of worms, for cars, on the same DefconRussia funny vectors were revealed, including the operation of service software in Sevris centers. A car arrives, a technician makes diagnostics, a machine infects a technician's workstation through vulnerabilities in software. The next client arrives at the same service center, and already the technician infects the car. I want to say separately that it is very often possible to meet a situation where IVI / HUs of the same family and generation are installed on cars of different brands, which simplifies the task of a hypothetical worm.
Well and speaking about Internet services - everything is also very interesting. Think, if you forget the ConnectedCar Internet proxy or the API backend, which is on the Internet, then the traffic of the machines (updates, registration, some features of the ConnectedCar) will be under your control. Again, there are a lot of similarities with mobile security, and ConnectedCar and HU have the same problems.
Worms, so far only in theory ...
The future is near - cars without a driver
What would not be completely boring was a little about what used to be fiction - robotic cars. The world expects that in 2040 this technology will be successfully implemented, which means that what we are doing now will become a platform for engineers of the future and security issues are not in last place here. After all, then the attack vectors and the profit from them will be completely different. It is difficult to say what HU will be in 2040, but one can guess that the whole logic of navigation and decision-making will be somewhere nearby, so I would like that what I am writing about now and what hackers show at conferences in 2040 would be “obvious »And protected as something ordinary and elementary (after talking with security experts who work for the auto industry, at least specifically German, I can say that they are aware of all this and on the right track, which pleases).
I see the future exactly 8)
Is everything so bad? Defend yourself sir!
I would also like to write about how HU and the auto network are protected (each has its own, but so to speak, basic approaches). These approaches are quite different, who see some risks, some others, but overall there is progress and it will only grow.
For example, in the current situation, it is necessary and important to have an update mechanism (on the client HU). If they find a bug, or what happens, you need to quickly deliver the update, update the entire firmware or component (otherwise, you can get a pretty penny on the recall of machines). Moreover, such a process should be quite protected. Signature, certificate - all matters. In general, there is progress in this matter and this is good.
Regarding the protection of HU itself, things are very different for everyone, but there is a general tendency to move towards isolating the OS as far as possible from the main network and processes. For example, they isolate not only at the level of network segmentation, but also up to the full virtualization of the OS. But in general, the problem is and will be - if the OS needs to have access to the ECU of the locks, then it will also have a cruise control or OBD-II, which means there will be a way to manage the locks, influence the driving mode and access to status auto. But while virtualization has not entered our life so tightly, we have rather common problems: lack of ASLR, wrong access rights to local files, etc. Not everyone has a keychain, and many applications need to store user secrets on HU, so the availability of secure storage is as popular in IVI as on smartphones. I'm not talking about SELinux, I understand that it can be hard, but still. And the same SSH - it is not needed at all on HU in production, for what reason it is there - is not clear (by the way, I want to add for honesty that the situation is changing, and now it has become more difficult to meet SSH - it is only included on development releases) . In general, the hardening problem for vendors is on the face: forgive me for the root browser (by the way, to be honest, this is also becoming a rare problem now, the developers are not stupid and everyone understands and corrects the same thing).
Separately, there is an interesting task of maintaining integrity. From my point of view, even if someone was able to execute code on the HU, he should not have the opportunity to gain a foothold in the system, even if he is root. But in practice, someone clogs up with these problems and the FS can be remounted with rw rights, while for someone HU will go into reboot at the slightest attempt to change at least something in the configuration.
Virtualization
And a little about virualization, as a solution to all problems. One of the main strategies for protecting an OS with "entertainment" applications, as mentioned above, is its virilization. I think in N years, one way or another it will be implemented by all many manufacturers. The advantages here, of course, are obvious: such an OS is isolated from the main auto-system, including at the network level. This is undoubtedly true, but even if such an OS is compromised, the attacker may already receive something of value. Firstly, the user data that is processed in this isolation layer, and this is enough to consider a “hack” successful - data from sensors, coordinates, destination, application data ... finally, FaceBook access token, for the sake of this, it was worth breaking HU ! Secondly, certain APIs and services will be “thrown” into the virtualized environment, including one way or another UI display, which allows in any case to develop an attack, including "down". Ultimately, it depends on many factors and each system needs to be considered separately, but in general, this approach seems to me to be true, since it complicates the task of the attacker anyway ...
Instead of conclusions
I wrote a lot, but it seems nothing concrete. Nevertheless, I wanted to draw attention to one of the key objects - the Head Unit and IVI, what risks are waiting there, why and what developers / vendors are doing with it. Now there is enough information about the problems of CAN networks: general access, some ECUs can be docked and brutalized, and even more so, data can be taken, etc. But all these attacks and examples are divorced from concrete practical application in the context of the "remote attack on a car from the Internet." I wanted to show, as it seems to me, the main goal and only some of its problems (especially considering the Connected Car features) and the current situation in the industry (in my humble opinion). I didn’t want to frighten or reassure anyone, so this article does not pretend to be a vendor advertisement or a “wow, hackers can break everything, how scary to live.” But, of course they can break,Chris and Charlie will demonstrate a remote attack vector for a real car in full - remote penetration, gaining access to CAN, impact on critical ECUs. I don’t know if HU will be affected as an entry point or privilege escalation, and what kind of attack it will be, but the show will certainly come out good, and most importantly, demonstrate real features 8) All have a safe ride!