Head Unit - as a target for a hacker
Recently, the theme of the hacker threat in the automotive world has been increasingly raised. Moreover, this topic worries everyone - auto manufacturers, OEM, information security consultants, and, of course, the authorities of the European Union and the United States are interested in this topic (they even provide research grants, etc.). Since in the information security industry very often all moves are an attempt to “scare”, I would like to understand the situation “now” and the potential situation in “future” without too much pathos and paranoia, although in our case it is better to “outbid” than “nedo” . In the course of my work, I deal with the security of ConnectedCar systems, including Embedded products for Automotive systems. And in the light of the above, I would like to talk about the near future and new risks associated with IoT, cars and hackers. Specifically, in this part, I will talk about the potential vectors of attacks on the Head Unit of the car and its environment.
')
Why did I concentrate on the Head Unit? Yes, of course, there are many tasty targets in the Automotive Network, and much more critical in terms of control. After all, HU (hereafter, Head Unit, even more precisely speaking IVI - in-vehicle infotainment, if a logical component) is an entertainment system, navigation, control of uncritical things, such as air conditioning and interior lighting. In a normal car, HU does not have a direct connection to critical ECUs (ECU is a controller that controls a certain node — engine subsystem, power, ABS, etc.). Nevertheless, in view of the “computerization” of the control, interesting things are obtained - opening the door locks, the window regulator or trunk is controlled from the HU, which is more “critical”. So it's not that simple. The second is that there is no “direct network connection” via CAN, but it does not mean that there is no logical connection with critical ECUs. For example, there are such schemes where the 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 HU, you break into 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 , but still boast hunting, so I’ll mention it here) even conducted a review of these problems, including authentication problems and brute force for the ECU via CAN bus, so that those who haven’t had time to read it can do it here . In short, whatever one may say, but HU is a very good entry point. For me, this is the most convenient goal, and I can explain why:
1) Custom 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 on a user — espionage, for example. By the way, I should say that almost all the so-called User Expiernce is concentrated in HU, for example, such a feature as automatic parking payment, or fuel, and therefore more interesting data.
2) A convenient place to fix in the system - a place for BackDoor.
On the HU, everything is usually mounted in ReadOnly - but there are also options for how to gain a foothold in the system, that is, to make BackDoor and have constant access to the network. Yes, technically there may be difficulties in overcoming the protection of the vendor, but ultimately it is the most convenient place to be fixed in the system with subsequent stable access. We add that the OS HU it can be QNX, Linux, and even, Windows CE!
3) Attack development
It also follows from point 2. It is from HU that it is convenient to attack the ECU (Gateway) to enhance privileges and other evil. It should be added that HUs are the most powerful computers in terms of performance on cars, there may be different CPUs and RAM sizes and different operating systems from different car manufacturers, but in general (since there you need to render some kind of GUI, work with network traffic , playing music and doing it all in parallel) it is obvious that they use quite powerful pieces of hardware from the Embeded point of view. As a rule, ARM Cortex 6, for example, Tegra 2 or 3. Anything can happen.
4) A convenient place for remote attack
In the clever wheelbarrows HU has a lot of applications, a lot of network connections to the Internet, not to mention USB, BT and Wi Fi. That is, it is slightly 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 the security of an automated process control system, only with PLC controllers we are connected to a smartphone that is connected to the Internet =)
Summing up all this “analytics”, I deduced for myself that HU is the most delicious and desirable 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 radar, etc. In other words, vehicle safety is not IoT safety, or rather, not only.
Before proceeding, I would like to ask a good question - why should anyone actually be interested in hacking an unfortunate car? In general, there are several options:
1) Espionage
Target attack on a specific person. For example, monitor its movements without the "physical bug". True, why duplicate the functionality of the car. In modern cars everything is already there: GPS, GSM, Wi-Fi and BT. It is only necessary to fix everything “software”, and if this can be done remotely, without physical intervention, then 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 items, here you can enter the opportunity to get access to payment functions, about which I have already mentioned.
2) Destructive actions
In general, the goal is rather dubious, but again - ABS disabled at the right moment is a rather dangerous thing. Thus, the EM gun can easily bring all the electronics of a car at the right moment, at the right speed, in the right place (at a sharp turn) - this can be very dangerous. Such facts were already in the history of the automotive industry, the truth of the attacks were random (EM pickups from the base cell stations). Accordingly, if the ECU can be derived "programmatically", then in potential we can get the same effect. But still it is an option for the film, rather.
3) Unauthorized physical access
It can be said about hijacking, a rather “natural” vector, although rather related to local physical attacks and vulnerabilities of the “local network”. However, the MiTM version has already been demonstrated in practice and, as a result, the “car door opening”.
Next, let's talk about less obvious vectors:
4) Route Manipulation
So far, cars on autopilot are only in the testing and finalization stages, but nevertheless, even without this uber feature, we have the opportunity to manipulate the route - provided that the driver trusts in what the navigator says. And if the navigator says that the road is closed, there is a traffic jam and it is necessary to go differently, that is, it is far from zero the probability that the driver will agree.
5) "Loker"
Purely for humor, when we discussed these problems at the 21st meeting of DefconRussia , the idea of ​​monetization - “locker” was proposed. You sit in the car, start up, and on the screen there is a red veil and a hellish font of the requirement to send money to the next number to unlock HU. It's funny that in this context, the “locker” can still really “block” doors, windows and something else. 8) In the case of any mass vulnerability or unclean TS of the center, this is a working option.
Enough to start. I think you can think of something else, and I propose to do it in the comments ...
In this part we will talk about the possibility of attacks. I will say right away, I will speak 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 about the NDA, but I will do the squeeze, in the form of conclusions about the existence of such vectors, so that you can imagine what attacks are possible in theory. First, a little about the device HU. As a rule, this is a box with outputs to various panels, displays, sensors, GSM / 3G modem, card / USB input, Bluetooth device, etc. Inside this box, memory, ROM and, of course, the CPU, as a rule, on the ARM chip. We also have the main entertainment OS with all the devices: navigation, control of some cabin elements (aha, door locks, for example, or window raiser), video / mp3 player, sometimes even a web browser ... I want to make a reservation and say that HU is very different from different manufacturers and from different generations of products. Somewhere several CPU and OS, where there is even a hypervisor and OS with all user good generally virtualized. I can confidently say that the German automotive industry is on the path of “isolating the user from the car,” although this path is still thorny. In the simplest case, there will be a common OS in this box, but all the same - the HU itself is “isolated” at the network level, about 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 tasks that RealTime is needed right here), but QNX is used by some manufacturers there (HARMAN, the most vivid example). If we talk about Linux, here GENVI and Tizen are bright 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, there is usually still access to the audio system, telephony (usually the MOST bus is used here), and yes, there are also direct CAN connections with some ECUs. Where can an attacker make his efforts to penetrate and gain a foothold in the HU?
Let's start with the simplest - local interfaces allow you to interact with the OS with its services and applications. The vector seems rather doubtful, because the attacker must somehow get closer to these interfaces, but nevertheless, one more thing must be understood - many “secrets” are hidden 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 is “no one should know, and then everything is in order” (Security Through Obscurity) is a fairly common feature in the automotive industry 8) Besides this goal, there are also hybrid attacks on local interfaces, that is, in fact, the source of the attack can be remote, but local penetration mechanism: for example, you downloaded an Mp3 file that has tags and tags (let's say there is a BoF exploit), uploaded to the HU, started the player and voila - BoF in the tag parser, exploit in the file - the machine is lost ( now - even it was, though not detailed). There may be quite a few such topics: update maps, POIs, fake updates ... In addition to directly “attacking file format parsing errors”, there are also unexpected ways of operating errors in the update logic, for example, maps of the navigation system. Well, local interfaces are not only files and imports: these are BlueTooth, and WiFI hotspot (yes, there are such features!) And USB. For example, it turned out to be quite a popular decision to make EthrenetOverUSB. That is, USB is quite an Ethernet Ethernet input to the HU network. Next, we’re getting hooked on SSH, logging in as root (remember that one password for all machines ...) and everything, the song is sung. And the same thing via Wi-Fi hotspot - such as HU opens such hotspot and exposes its SSH outside. Once again, it’s not just guesses, any of you can check out such trivial things (for example, fans of Toyota and Mazda have already found such a joke with USB - http://www.mazda3hacks.com/doku.php?id=notes:sshnotes I also saw this among other vendors. So I’m waiting for the hackers to find more good, and they will find!).
The most delicious vector is via the Internet, and a lot of opportunities open up here, and these opportunities are only growing. Here you can start with the classic client-side attacks, the same browser and its plug-ins. Yes, it has long been fashionable to have a browser in the machine that can read PDFs and Word! This may be some kind of WebKit assembly, or Chrome, so the classic problems and difficulties on the face. It would not be superfluous to say that it also happens that the browser may well work as root. But this is all more and less obvious and understandable (except for the browser as root, I refuse to understand this). In addition to the browser, there are a lot 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 “embedded” and all the logic of ConnectedCar rests on them. Now let's just imagine what can SSRF / CSRF or XSS lead to? So if, let's say, the HU interface and all the garbage, including applications, is HTML5 + JS, then with XSS, we get access to the internal API — vehicle coordinates, VIN, fuel, current speed, and so on, which usually turns into a sensor API . 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 the navigation logic, profiles, applications, or develop the attack yet). This is especially unpleasant, given ConnectedCar services - linking the car to the service and remote manipulation or data access.
As an example, a recent BMW burglary incident. The problem was that the important traffic was encrypted with a symmetric key, which can be pulled out with the help of methods, as it is now fashionable to say, “reverse engineering”. With this key, data was encrypted for all cars, so by pulling such a key from one machine, you can safely use it for all the others. The data and commands themselves were transmitted over HTTP, no SSL. Actually, all this allowed to spoof and emulate the command “open doors”, to conduct MiTM - this is if figuratively, for details, see the link.
In general, there are many different vectors
Not exactly the HU problem, but on the other hand, the RDS / TMC parsing is often in the 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 is 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 about traffic jams and traffic situations on the radio. But besides this vector, it is possible to russify RDS for the presence of vulnerabilities in format processing, although there is nothing special about TMC, but in Radio Text, for example, the probability of a BoF or something like that may be non-zero.
Separately, I note the network technology v2v. I really like the idea of ​​a worm that will jump from one car to another - think for yourself, for example, Wi-Fi (IEEE 802.11p) is offered as one of the solutions. I hope by this time they will teach not to roll out the network interfaces to 0.0.0.0 and open SSH, otherwise there will be a very interesting instance of the worm 8)
Dreammaker's dream of the near future ...
Continuing the theme of worms, for the car, on the same DefconRussia, funny vectors were revealed, including the operation of the service software in the sevris centers. A car arrives, a technician makes a diagnosis, a machine infects a workstation by a technician through software vulnerabilities. The next client arrives at the same service center, and the technician already infects the machine. Separately, I want to say that it is very often possible to meet a situation where IVI / HU is of the same family and generation, but installed on cars of different brands, which simplifies the task of a hypothetical worm.
Well, speaking about Internet services - everything is also very interesting. Think if you connect the ConnectedCar Internet proxy or API backend on the Internet, then the traffic of the machines (updates, registration, some ConnectedCar features) will be under your control. Again, there are a lot of similarities with mobile security and the problems with ConnectedCar and HU are the same.
Worms, while only in theory ...
What would not be quite boring was a little about what used to be science 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 safety issues are not in the last place. After all, then the attack vector 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 all the navigation and decision-making logic will be somewhere nearby, so I would like what I am writing now and what hackers show at conferences in 2040 would become “obvious "And protected as something ordinary and elementary (after talking with information security specialists who work for the automotive industry, at least specifically German, I can say that they are aware of all this and are on the right track, which pleases).
I see the future exactly like this 8)
Separately, I want to write about how HU and auto network is protected (each has its own way, but so to speak, the main approaches). These approaches are quite different, who see some risks, someone else, but in general there is progress and it will only grow.
For example, in the current environment, it is necessary and important to have an update mechanism (on the client HU). If you 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 machine recall). Moreover, such a process should be fairly secure. Signature, certificate - all things. In general, in this case there is progress and this is good.
Regarding the protection of the HU itself, then things are very different for everyone here, but there is a general tendency to move towards OS isolation 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 complete OS virtualization. But in general, the problem is and will be - if the OS needs to have access to the ECU of locks, then it will be the same as cruise control or OBD-II, which means there will be a way to control locks, impact on driving mode and access to state data auto. But while virtualization is not so tightly included in our lives, we have quite common problems: the lack of ASLR, incorrect access rights to local files, and so on. Not everyone has keychain, and many applications need to store user secrets on the HU, so the availability of secure storage is also in demand in IVI, as on smartphones. I do not speak about SELinux, I understand that it can be hard, but still. And the same SSH - it is not needed at all in HU in production, for what reason it is there - it is not clear (by the way, I want to add for fairness that the situation is changing, and now it has become more difficult to meet SSH - it is included only on releases for development) . In general, the problem of hardening in the face of the vendors: forgive me, the browser as root (by the way, to be honest, this is also now becoming a rare problem, the developers are not fools and they all understand and correct this).
Separately, there is an interesting task of maintaining integrity. From my point of view, even if someone could execute the code on the HU, he should not be able to fix himself on the system, even if he is root. But in practice, someone scores on these problems and the file system can be remounted with rw rights, and for someone HU will go into reboot at the slightest attempt to change at least something in the configuration.
And a little bit about virilization, how about solving all the problems. One of the main strategies for protecting an OS with “entertainment” applications, as already stated above, is its virtualization. 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 the case, but even if such an OS is compromised, the attacker may receive something valuable already. First of all, user data that is processed in this isolation layer, and this is enough to consider “hacking” successful - data from sensors, coordinates, destination point, application data ... the Facebook access token finally needed to break the HU ! Secondly, some APIs and services will be “prokynuty” in a virtualized environment, including one way or another display UI, 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 in one way or another ...
I wrote quite a lot, but it seems nothing specific. Nevertheless, I wanted to draw attention to one of the key objects - Head Unit and IVI, what risks are there waiting for, why and what do developers / vendors do with it. Now there is enough information about the problems of CAN networks: general access, some ECUs can be reached and reset, and even more so you can remove data and so on. But all these attacks and examples are divorced from concrete practical application in the context of the “remote attack on a car from Ineta”. 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 scare or encourage anyone, so this article does not claim either to advertise vendors or to “wow, hackers can break everything, how terrible to live.” But of course they can break, and already this summer, on Black Hat in Las Vegas, all the same guys Chris and Charlie will demonstrate a remote vector of attack on a real car in full - remote penetration, access to CAN, impact on critical ECUs. I don’t know if HU will be touched as an entry point or privilege escalation and generally what kind of attack it will be, but the show will definitely come out good, and most importantly, demonstrate real possibilities 8) Safe ride for everyone!
')
Head Unit - sweet goal?
Why did I concentrate on the Head Unit? Yes, of course, there are many tasty targets in the Automotive Network, and much more critical in terms of control. After all, HU (hereafter, Head Unit, even more precisely speaking IVI - in-vehicle infotainment, if a logical component) is an entertainment system, navigation, control of uncritical things, such as air conditioning and interior lighting. In a normal car, HU does not have a direct connection to critical ECUs (ECU is a controller that controls a certain node — engine subsystem, power, ABS, etc.). Nevertheless, in view of the “computerization” of the control, interesting things are obtained - opening the door locks, the window regulator or trunk is controlled from the HU, which is more “critical”. So it's not that simple. The second is that there is no “direct network connection” via CAN, but it does not mean that there is no logical connection with critical ECUs. For example, there are such schemes where the 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 HU, you break into 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 , but still boast hunting, so I’ll mention it here) even conducted a review of these problems, including authentication problems and brute force for the ECU via CAN bus, so that those who haven’t had time to read it can do it here . In short, whatever one may say, but HU is a very good entry point. For me, this is the most convenient goal, and I can explain why:
1) Custom 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 on a user — espionage, for example. By the way, I should say that almost all the so-called User Expiernce is concentrated in HU, for example, such a feature as automatic parking payment, or fuel, and therefore more interesting data.
2) A convenient place to fix in the system - a place for BackDoor.
On the HU, everything is usually mounted in ReadOnly - but there are also options for how to gain a foothold in the system, that is, to make BackDoor and have constant access to the network. Yes, technically there may be difficulties in overcoming the protection of the vendor, but ultimately it is the most convenient place to be fixed in the system with subsequent stable access. We add that the OS HU it can be QNX, Linux, and even, Windows CE!
3) Attack development
It also follows from point 2. It is from HU that it is convenient to attack the ECU (Gateway) to enhance privileges and other evil. It should be added that HUs are the most powerful computers in terms of performance on cars, there may be different CPUs and RAM sizes and different operating systems from different car manufacturers, but in general (since there you need to render some kind of GUI, work with network traffic , playing music and doing it all in parallel) it is obvious that they use quite powerful pieces of hardware from the Embeded point of view. As a rule, ARM Cortex 6, for example, Tegra 2 or 3. Anything can happen.
4) A convenient place for remote attack
In the clever wheelbarrows HU has a lot of applications, a lot of network connections to the Internet, not to mention USB, BT and Wi Fi. That is, it is slightly 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 the security of an automated process control system, only with PLC controllers we are connected to a smartphone that is connected to the Internet =)
Summing up all this “analytics”, I deduced for myself that HU is the most delicious and desirable 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 radar, etc. In other words, vehicle safety is not IoT safety, or rather, not only.
What for?
Before proceeding, I would like to ask a good question - why should anyone actually be interested in hacking an unfortunate car? In general, there are several options:
1) Espionage
Target attack on a specific person. For example, monitor its movements without the "physical bug". True, why duplicate the functionality of the car. In modern cars everything is already there: GPS, GSM, Wi-Fi and BT. It is only necessary to fix everything “software”, and if this can be done remotely, without physical intervention, then 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 items, here you can enter the opportunity to get access to payment functions, about which I have already mentioned.
2) Destructive actions
In general, the goal is rather dubious, but again - ABS disabled at the right moment is a rather dangerous thing. Thus, the EM gun can easily bring all the electronics of a car at the right moment, at the right speed, in the right place (at a sharp turn) - this can be very dangerous. Such facts were already in the history of the automotive industry, the truth of the attacks were random (EM pickups from the base cell stations). Accordingly, if the ECU can be derived "programmatically", then in potential we can get the same effect. But still it is an option for the film, rather.
3) Unauthorized physical access
It can be said about hijacking, a rather “natural” vector, although rather related to local physical attacks and vulnerabilities of the “local network”. However, the MiTM version has already been demonstrated in practice and, as a result, the “car door opening”.
Next, let's talk about less obvious vectors:
4) Route Manipulation
So far, cars on autopilot are only in the testing and finalization stages, but nevertheless, even without this uber feature, we have the opportunity to manipulate the route - provided that the driver trusts in what the navigator says. And if the navigator says that the road is closed, there is a traffic jam and it is necessary to go differently, that is, it is far from zero the probability that the driver will agree.
5) "Loker"
Purely for humor, when we discussed these problems at the 21st meeting of DefconRussia , the idea of ​​monetization - “locker” was proposed. You sit in the car, start up, and on the screen there is a red veil and a hellish font of the requirement to send money to the next number to unlock HU. It's funny that in this context, the “locker” can still really “block” doors, windows and something else. 8) In the case of any mass vulnerability or unclean TS of the center, this is a working option.
Enough to start. I think you can think of something else, and I propose to do it in the comments ...
HU Attack Vectors
In this part we will talk about the possibility of attacks. I will say right away, I will speak 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 about the NDA, but I will do the squeeze, in the form of conclusions about the existence of such vectors, so that you can imagine what attacks are possible in theory. First, a little about the device HU. As a rule, this is a box with outputs to various panels, displays, sensors, GSM / 3G modem, card / USB input, Bluetooth device, etc. Inside this box, memory, ROM and, of course, the CPU, as a rule, on the ARM chip. We also have the main entertainment OS with all the devices: navigation, control of some cabin elements (aha, door locks, for example, or window raiser), video / mp3 player, sometimes even a web browser ... I want to make a reservation and say that HU is very different from different manufacturers and from different generations of products. Somewhere several CPU and OS, where there is even a hypervisor and OS with all user good generally virtualized. I can confidently say that the German automotive industry is on the path of “isolating the user from the car,” although this path is still thorny. In the simplest case, there will be a common OS in this box, but all the same - the HU itself is “isolated” at the network level, about 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 tasks that RealTime is needed right here), but QNX is used by some manufacturers there (HARMAN, the most vivid example). If we talk about Linux, here GENVI and Tizen are bright 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, there is usually still access to the audio system, telephony (usually the MOST bus is used here), and yes, there are also direct CAN connections with some ECUs. Where can an attacker make his efforts to penetrate and gain a foothold in the HU?
Local Interfaces
Let's start with the simplest - local interfaces allow you to interact with the OS with its services and applications. The vector seems rather doubtful, because the attacker must somehow get closer to these interfaces, but nevertheless, one more thing must be understood - many “secrets” are hidden 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 is “no one should know, and then everything is in order” (Security Through Obscurity) is a fairly common feature in the automotive industry 8) Besides this goal, there are also hybrid attacks on local interfaces, that is, in fact, the source of the attack can be remote, but local penetration mechanism: for example, you downloaded an Mp3 file that has tags and tags (let's say there is a BoF exploit), uploaded to the HU, started the player and voila - BoF in the tag parser, exploit in the file - the machine is lost ( now - even it was, though not detailed). There may be quite a few such topics: update maps, POIs, fake updates ... In addition to directly “attacking file format parsing errors”, there are also unexpected ways of operating errors in the update logic, for example, maps of the navigation system. Well, local interfaces are not only files and imports: these are BlueTooth, and WiFI hotspot (yes, there are such features!) And USB. For example, it turned out to be quite a popular decision to make EthrenetOverUSB. That is, USB is quite an Ethernet Ethernet input to the HU network. Next, we’re getting hooked on SSH, logging in as root (remember that one password for all machines ...) and everything, the song is sung. And the same thing via Wi-Fi hotspot - such as HU opens such hotspot and exposes its SSH outside. Once again, it’s not just guesses, any of you can check out such trivial things (for example, fans of Toyota and Mazda have already found such a joke with USB - http://www.mazda3hacks.com/doku.php?id=notes:sshnotes I also saw this among 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 via the Internet, and a lot of opportunities open up here, and these opportunities are only growing. Here you can start with the classic client-side attacks, the same browser and its plug-ins. Yes, it has long been fashionable to have a browser in the machine that can read PDFs and Word! This may be some kind of WebKit assembly, or Chrome, so the classic problems and difficulties on the face. It would not be superfluous to say that it also happens that the browser may well work as root. But this is all more and less obvious and understandable (except for the browser as root, I refuse to understand this). In addition to the browser, there are a lot 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 “embedded” and all the logic of ConnectedCar rests on them. Now let's just imagine what can SSRF / CSRF or XSS lead to? So if, let's say, the HU interface and all the garbage, including applications, is HTML5 + JS, then with XSS, we get access to the internal API — vehicle coordinates, VIN, fuel, current speed, and so on, which usually turns into a sensor API . 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 the navigation logic, profiles, applications, or develop the attack yet). This is especially unpleasant, given ConnectedCar services - linking the car to the service and remote manipulation or data access.
As an example, a recent BMW burglary incident. The problem was that the important traffic was encrypted with a symmetric key, which can be pulled out with the help of methods, as it is now fashionable to say, “reverse engineering”. With this key, data was encrypted for all cars, so by pulling such a key from one machine, you can safely use it for all the others. The data and commands themselves were transmitted over HTTP, no SSL. Actually, all this allowed to spoof and emulate the command “open doors”, to conduct MiTM - this is if figuratively, for details, see the link.
In general, there are many different vectors
Rds spoofing
Not exactly the HU problem, but on the other hand, the RDS / TMC parsing is often in the 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 is 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 about traffic jams and traffic situations on the radio. But besides this vector, it is possible to russify RDS for the presence of vulnerabilities in format processing, although there is nothing special about TMC, but in Radio Text, for example, the probability of a BoF or something like that may be non-zero.
v2v
Separately, I note the network technology v2v. I really like the idea of ​​a worm that will jump from one car to another - think for yourself, for example, Wi-Fi (IEEE 802.11p) is offered as one of the solutions. I hope by this time they will teach not to roll out the network interfaces to 0.0.0.0 and open SSH, otherwise there will be a very interesting instance of the worm 8)
Dreammaker's dream of the near future ...
Hybrid worms
Continuing the theme of worms, for the car, on the same DefconRussia, funny vectors were revealed, including the operation of the service software in the sevris centers. A car arrives, a technician makes a diagnosis, a machine infects a workstation by a technician through software vulnerabilities. The next client arrives at the same service center, and the technician already infects the machine. Separately, I want to say that it is very often possible to meet a situation where IVI / HU is of the same family and generation, but installed on cars of different brands, which simplifies the task of a hypothetical worm.
Well, speaking about Internet services - everything is also very interesting. Think if you connect the ConnectedCar Internet proxy or API backend on the Internet, then the traffic of the machines (updates, registration, some ConnectedCar features) will be under your control. Again, there are a lot of similarities with mobile security and the problems with ConnectedCar and HU are the same.
Worms, while only in theory ...
The future is near - cars without a driver
What would not be quite boring was a little about what used to be science 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 safety issues are not in the last place. After all, then the attack vector 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 all the navigation and decision-making logic will be somewhere nearby, so I would like what I am writing now and what hackers show at conferences in 2040 would become “obvious "And protected as something ordinary and elementary (after talking with information security specialists who work for the automotive industry, at least specifically German, I can say that they are aware of all this and are on the right track, which pleases).
I see the future exactly like this 8)
Is everything so bad? Defend yourself, sir!
Separately, I want to write about how HU and auto network is protected (each has its own way, but so to speak, the main approaches). These approaches are quite different, who see some risks, someone else, but in general there is progress and it will only grow.
For example, in the current environment, it is necessary and important to have an update mechanism (on the client HU). If you 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 machine recall). Moreover, such a process should be fairly secure. Signature, certificate - all things. In general, in this case there is progress and this is good.
Regarding the protection of the HU itself, then things are very different for everyone here, but there is a general tendency to move towards OS isolation 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 complete OS virtualization. But in general, the problem is and will be - if the OS needs to have access to the ECU of locks, then it will be the same as cruise control or OBD-II, which means there will be a way to control locks, impact on driving mode and access to state data auto. But while virtualization is not so tightly included in our lives, we have quite common problems: the lack of ASLR, incorrect access rights to local files, and so on. Not everyone has keychain, and many applications need to store user secrets on the HU, so the availability of secure storage is also in demand in IVI, as on smartphones. I do not speak about SELinux, I understand that it can be hard, but still. And the same SSH - it is not needed at all in HU in production, for what reason it is there - it is not clear (by the way, I want to add for fairness that the situation is changing, and now it has become more difficult to meet SSH - it is included only on releases for development) . In general, the problem of hardening in the face of the vendors: forgive me, the browser as root (by the way, to be honest, this is also now becoming a rare problem, the developers are not fools and they all understand and correct this).
Separately, there is an interesting task of maintaining integrity. From my point of view, even if someone could execute the code on the HU, he should not be able to fix himself on the system, even if he is root. But in practice, someone scores on these problems and the file system can be remounted with rw rights, and for someone HU will go into reboot at the slightest attempt to change at least something in the configuration.
Virtualization
And a little bit about virilization, how about solving all the problems. One of the main strategies for protecting an OS with “entertainment” applications, as already stated above, is its virtualization. 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 the case, but even if such an OS is compromised, the attacker may receive something valuable already. First of all, user data that is processed in this isolation layer, and this is enough to consider “hacking” successful - data from sensors, coordinates, destination point, application data ... the Facebook access token finally needed to break the HU ! Secondly, some APIs and services will be “prokynuty” in a virtualized environment, including one way or another display UI, 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 in one way or another ...
Instead of conclusions
I wrote quite a lot, but it seems nothing specific. Nevertheless, I wanted to draw attention to one of the key objects - Head Unit and IVI, what risks are there waiting for, why and what do developers / vendors do with it. Now there is enough information about the problems of CAN networks: general access, some ECUs can be reached and reset, and even more so you can remove data and so on. But all these attacks and examples are divorced from concrete practical application in the context of the “remote attack on a car from Ineta”. 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 scare or encourage anyone, so this article does not claim either to advertise vendors or to “wow, hackers can break everything, how terrible to live.” But of course they can break, and already this summer, on Black Hat in Las Vegas, all the same guys Chris and Charlie will demonstrate a remote vector of attack on a real car in full - remote penetration, access to CAN, impact on critical ECUs. I don’t know if HU will be touched as an entry point or privilege escalation and generally what kind of attack it will be, but the show will definitely come out good, and most importantly, demonstrate real possibilities 8) Safe ride for everyone!
Source: https://habr.com/ru/post/257287/
All Articles