“Fashionable science fiction policeman in red” by Etienne Girardet on Unsplash“Fashionable science fiction policeman in red” by Etienne Girardet

In this post we’ll look at possible attack surfaces of a car. When talking about attack surfaces we refer to all possible ways to attack a target, from different vulnerabilities in individual components to those that possibly affect the entire vehicle. When we talk about the attack surface, we are not looking at how a target can be exploited. It is only about finding possible entry points into the target system. In our particular case, for the purposes of this post, we are only referring to threats that occur at the OBD-II interface. In more detail, we have limited the scope to the CAN protocol, which can be accessed via OBD-II.

Threat Rating Systems in the Automotive Sector

In the automotive sector, the following standards are used in industry, research and legislation are ISO 26262 ASIL as well as MIL-STD-882E. Unfortunately, both focus on safety failures and are not suitable for handling malicious threats. The reason for this is that we want more details than just risk = probability × severity. If the circumstances call for one of these two systems, Craig Smith [1] advises to use MIL-STD-882E from the Department of Defense (DoD). The main problem with the ASIL (Automotive Safety Integrity Level) system is that it too often falls into the Quality Management (QM) ranking, which is basically pretty useless for our purposes. The Department of Defense’s system usually results in a higher ranking, which also means a higher value for the cost of a human life. Furthermore, MIL-STD-882E is designed to be used throughout the entire life cycle of a system, including disposal, which fits well with a safe development life cycle. For this reason, malicious threats in the automotive sector are often categorized in the DREAD Rating System [2]. It was developed by Adam Shostack while working at Microsoft.

Threat Identification

In order to get a detailed model, the first step is to find out what potential threats are present. Then we will start to analyze and assess the specified points using the DREAD system. An adversary could exploit the CAN bus interface in multiple ways. One possibility, which makes multiple attack vectors and attacks feasible, is to install a malicious diagnostic device. This enables the attacker to send and receive packets on the CAN bus. With this you can try to start the vehicle directly even if you do not have the real physical key. Another point of attack that is made available is the ability to upload malware. As already mentioned in the motivation it is possible to create a rather detailed model of the state of a vehicle at a certain time by means of the messages that flow on the CAN bus. Thus another thread would be the possibility of tracking vehicles via malicious diagnostic devices. The attacker could now equip the diagnostic device that he puts into the vehicle with a dedicated Universal Mobile Telecommunications Service (UMTS) module. This would enable remote access to the CAN bus, transforming a normal internal attack into an external threat [3] [4].

Threat Modelling

Based on a commercial passenger car with an OBD-II dongle as our system model, we conducted a threat analysis. The threats were categorized according to the STRIDE method. The following pages do not provide a complete threat analysis using the STRIDE method. Considering the limited scope and goal of this work, some threats were of higher priority as well as interest. The next sections will therefore only deal with the relevant threats.

\(T_\alpha\)- Malicious Device plugs directly into OBD-II

Threat Description The attacker has direct physical access to plug his malicious device into the vehicle’s OBD-II interface, then uses it to execute his commands or payload. This enables him to do anything that is possible via the OBD-II specification.
Threat Target All ECUs that can be addressed via the OBD-II interface.
Attack Techniques Attacker manage to gain physical access into the vehicle.

This threat is virtually impossible to prevent. As soon as the attacker has physical access to the interface, he can, for example, bypass all upstream hardware security modules or simply plug them off. \(T_\alpha\) could only be effectively prevented by additional physical security mechanisms. One possibility would be to physically separate the hardware security modules from the accessible OBD-II interface in such a way that it is no longer possible for an attacker to either:

  1. Separate the module from the vehicle
  2. The use of the OBD-II interface becomes unusable as soon as the module is disconnected

However, this would require some modification of the OBD-II standard and is not really feasible.

\(T_\beta\)- Attacker compromises a running service on dongle

\(T_{\beta_I}\) Dongle refers to hardware where our firewall approach runs on

Threat Description Attacker gets access to a shell on the firewall, then uses this to execute commands to disable or disturb it.
Threat Target Ethernet/USB interface of the respective dongle or the Wi-Fi interface.
Attack Techniques Attacker manages to compromise a service running on the device.

\(T_{\beta_{II}}\) Dongle refers to hardware that plugs into our firewall approach

Threat Description Attacker gets access to a shell on the dongle, then uses this to execute commands.
Threat Target Cloud-Services of dongle, Internet interface of the respective dongle or the Wi-Fi interface.
Attack Techniques Attacker manages to compromise a service running on the device.

The threat class \(T_\beta\) is a includes threats that may or may not occur frequently, depending on the security standards applied in the development of the dongle. Of course, such services are never 100% secure from any attacks. One reason for this is that the attack surface is very large due to the use of cloud services, an internet interface (e.g. by means of a SIM module in the dongle) or a Wi-Fi interface. The very fact that the service communicates with a cloud service via an API means that these service and API endpoints must be regularly maintained and also updated. If this is not done, the risk of a possible attack increases many times over. Another point that makes this type of threat so dangerous is that it often affects all users of the service. Thus, on the one hand, it is a very appealing attack for attackers, as the possible effects are much greater than with individual attacks that only affect one individual. On the other hand, such attacks can often be easily carried out from anywhere and thus do not require direct physical access to the respective vehicles.

\(T_\gamma\)- Attacker can send arbitrary CAN commands

Threat Description The attacker is able to send any CAN message without restriction to the OBD-II accessible CAN bus.
Threat Target Anything that communicates via CAN and is connected via the bus accessible to OBD-II.
Attack Techniques The attacker must know information about the CAN layout to be used as well as the corresponding IDs and the payload.

This threat is enabled by either \(T_{\alpha}\) or \(T_{\beta}\). The attacker is thus able to control, for example, displays in the instrument cluster or the opening and closing of the electric windows. Generally speaking, it is possible for him to contact all ECU’s that communicate via CAN and can be reached via the OBD-II interface. This enables a wide range of attack vectors. Nevertheless, nothing is gained by the ability to send CAN messages alone. It is also necessary to know the exact content of the messages to be sent for the respective semantics.

\(T_\delta\)- Attacker can read communication on CAN-Bus

Threat Description The attacker is able to intercept and read CAN messages either directly via the OBD-II port or by means of a vulnerability in the respective dongle.
Threat Target Anything that communicates via CAN and is connected via the bus accessible to OBD-II.
Attack Techniques By capturing, deconstructing and analysing the individual CAN messages, many conclusions can be drawn. In general, however, no specific skills are necessary for taping the CAN bus traffic. Only if you want to decode them.

No direct physical damage can be caused by this threat, as it is only a matter of reading access to the CAN bus. Nevertheless, the privacy of the respective user can be violated. It is possible to listen to all communication on the CAN bus that is accessible via OBD-II. By analysing the traffic, a variety of conclusions can be drawn. For example, statements can be made about the individual driving behaviour of each driver in road traffic. Here again, the situation is analogous to \(T_\delta\). In itself, there is no direct danger from this threat as long as the attacker does not know the respective layout of the recorded data and thus cannot decode the data correctly or ascribe a direct purpose to it.

\(T_\epsilon\)- Damaging ECUs by executing specific commands

Threat Description The attacker succeeds in permanently damaging the ECU’s by clever manipulation of the control units.
Threat Target All entities of the vehicle that do not only perform observing, recording or displaying activities. In other words, all control units that control active/mechanical components.
Attack Techniques Detailed information about the individual ECU targets is required, as well as the associated details of the CAN messages required to damage the desired ECU.

In order to damage individual ECUs by means of specific messages, the attacker needs a profound understanding of the respective vehicle system as well as the ECU to be damaged. In most cases, such an attack is not possible without extensive prior testing and analysis of the hardware. Of course, one can actively try to damage the hardware by sending harmful and unwanted CAN messages. However, a try-and-error approach offers little chance of success.

\(T_\zeta\)- Person endangerment by deactivating safety functions

Threat Description The attacker deliberately deactivates certain safety mechanisms. Also included are actions that indirectly endanger the driver.
Threat Target This applies to all safety-critical components as well as to all occupants of the vehicle.
Attack Techniques A sound knowledge of the structure and format of internal safetycritical components is required. This includes the knowledge of the individual ECUs which are responsible for the control of the respective areas, as well as the CAN ID and the respective coded payload of the message.

This threat is a very dangerous one, as it may actively cause physical harm to people. On the one hand, an attacker could succeed in deactivating critical safety systems such as the airbag, the ABS (anti-lock braking system) or the ESP (electronic stability program). Thus, in the event of a driving manoeuvre where the respective system is required, a possible accident would be the result. Furthermore, an attacker could, for example, display the wrong speed. As an example, he could simply display a much lower speed than is actually being driven at the moment. Thus, the driver could be harmed if he is at that time in a certain road passage where maintaining a certain minimum speed is critical to safety.

\(T_\eta\)- Permanent infiltration of the vehicle system by uploading malware

Threat Description The intruder has unlimited access regardless of what is plugged into the OBD-II interface or not.
Threat Target Any ECU where there is a possibility of uploading malicious code within the memory.
Attack Techniques To carry out this type of attack, detailed and in-depth knowledge of individual ECUs is needed, as well as a reliable way to place malicious code there.

One stage during an attack or after a successful intrusion into a system is the maintenance of access. \(T_\eta\) describes the maintenance of unrestricted access even after possible malicious OBD-II devices have been removed. This requires in-depth knowledge of the ECU’s available in the target vehicle. Possible targets are especially ECU’s that have a memory module or dedicated firmware that can be overwritten

Results of OBD-II Threat Modeling

Based on the seven threats defined and explained above, we can now establish a rating using the DREAD rating model and thus roughly classify how big or serious the individual threats are. Our defined threats can be generally divided into 2 Medium threats and 5 High threats based on the risk level. The individual threats \(T_\alpha\) to \(T_\eta\) can be further classified or sorted by determining the respective DREAD risk using the formula defined in equation . The individual values for each threat that we have specified for the calculation as well as the calculated result can be seen in table . When comparing the individual result values, it becomes clear that \(T*\alpha\) is the highest rated threat with a risk rating of 3.0. The main reason for this is that \(T_\alpha\) is a physical threat. With physical threats, the possibilities of an attacker are always greater than, for example, in the case of a remote only attack. The lowest rated threat is \(T_\eta\) with a risk rating of 2.0. This is because this type of attack requires a tremendous amount of knowledge and skill to execute. Usually a lot of research and testing needs to be done on the real physical devices/ECU’s to even find vulnerabilities that make it possible to carry out the attack. It is also interesting that, with the exception of threat \(T_\delta\), the damage for all other threats is always rated at the maximum of three high. The reason for this lies in the effect of the respective threats. \(T_\delta\) describes the possibility to read messages of the CAN bus. This means that a possible attack can also be described as passive, since it never actively changes anything on the BUS or writes anything to it. Nevertheless, sensitive data (e.g. regarding the driver’s privacy) can be collected by reading and possibly decoding some messages. Therefore, \(T_\delta\) still has a rating of two, which means medium in terms of the DREAD rating system.

$$T_\alpha$$ $$T_{\beta_{I}}$$ $$T_{\beta_{II}}$$ $$T_\gamma$$ $$T_\delta$$ $$T_\epsilon$$ $$T_\zeta$$ $$T_\eta$$
D 3 3 3 3 2 3 3 3
R 3 2 2 2 2 2 2 1
E 3 2 2 2 2 1 2 1
A 3 3 3 3 3 3 3 3
D 3 2 2 3 3 2 3 2
DREAD Risk 3.0 2.4 2.4 2.6 2.4 2.2 2.6 2.0

Since some threats enable other threats, we have created an attack tree of the seven selected threats. An analysis via attack trees provides a graphical, easy-to-understand modelling of threats. It helps us to classify the different attack possibilities of the OBD-II interface more precisely and to develop possible countermeasures to prevent such attacks. In figure you can see this tree, which can also be divided into 3 hierarchies named \(L_{I}\), \(L_{II}\) and \(L_{III}\).

The first level is the basic threat hierarchy. This means that threats from higher levels are always based on threats from the basic level. The threats \(T_\alpha\) and \(T_{\beta_I}\) are therefore needed to realise attacks with the threats from the layers below. Therefore, we also define these two threats as entry threads. In the best case, all entry threats can be eliminated or prevented or mitigated so that all further threats become obsolete or not quite as severe. The threats in our last level \(L_{III}\) are the most specific in terms of the knowledge required or the techniques used.

References

[1] Craig Smith. The Car Hacker’s Handbook: A Guide for the Penetration Tester. 1st. USA: No Starch Press, 2016. ISBN: 1593277032.

[2] Adam Shostack. “Experiences Threat Modeling at Microsoft”. In: (Jan. 2008).

[3] Q. Wang and S. Sawhney. “VeCure: A practical security framework to protect the CAN bus of vehicles”. In: 2014 International Conference on the Internet of Things (IOT). 2014, pp. 13–18. DOI: 10.1109/IOT.2014.7030108.

[4] M. Gmiden, M. H. Gmiden, and H. Trabelsi. “An intrusion detection method for securing in-vehicle CAN bus”. In: 2016 17th International Conference on Sciences and Techniques of Automatic Control and Computer Engineering (STA). 2016, pp. 176–180. DOI: 10.1109/STA.2016.7952095.