AutoSec 2020 - Towards Effective Identification and Rating of Automotive Vulnerabilities

Transcript

We know that automobiles are getting more advanced and providing more smart functionality to users with each iteration. We also complexity is a natural adversary of security as it makes configuration errors and security oversights very probable with an increased attack surface. Every application, service, or aftermarket product that interacts with the automobile environment has the potential to introduce vulnerabilities. This complexity, when combined with the fact that many vehicular subsystems were not originally designed with interconnectivity in mind, has the potential to cause a significant impact on security. Therefore, we can expect to discover vulnerabilities in vehicular subsystems. However, what do we do with this information? Often we wish to patch or mitigate the vulnerabilities but in what order? Particularly, how do we gain a sense of the realistic impact of vulnerabilities and discover any underlying patterns? For instance, do 3rd party aftermarket products regularly introduce vulnerabilities in an otherwise secure vehicular ecosystem? Finally, we need to comprehend the difference between safety and security. Security can be considered a subset of safety, yes, but it demands seperate, careful consideration.

Vulnerabilities are not all the same. They vary in severity and impact. In traditional computing environments, vulnerability prioritization is done on the basic of quantification systems. However, before quantification, we have to consider vulnerability identification: what is the vulnerability? Where did the vulnerability originate? When was the vulnerability first discovered? When was it patched? Is is a zeroday? How involves its relevant technical details? Who recognizes the OEMs and manufacturers or aftermarket products that was responsible for introducing the vulnerability.

The common vulnerability scoring system or CVSS is a standard deployed in scoring vulnerabilities in computing environments. It suits our purpose because it is well known, and can be adapted to rate vulnerabilities affecting a range of systems – that is, it isn’t specific to one system. Most importantly, it reflects the complexity involved in exploitation of the vulnerability and the subsequent impact. This is important to gain a realistic comprehension of the impact. For example, if a vulnerability involves complete root access to a system, it appears to be highly significant. However, it is only exploitable by means of a physical connection to the OBD2 port, it is less impactful since exploitation is relatively difficult. On the other hand, if it’s exploitable over the Internet remotely, then it is much higher impact.

So for instance, the VMware guest to host escape vulnerability, we have the following vector string. Each vector in the string is an attempt at gauging a metric relevant to the vulnerability. For example, AV is the Attack Vector which is set to Network. This indicates that the vulnerability is remotely exploitable – which makes the vulnerability score higher. UI refers to User Interaction which indicates whether exploitation depends on user interaction. If yes, the score will be lower. These are the exploitability metrics. Then, we have the impact metrics – the more entities that are affected in the CIA triad, the more severe the vulnerability is. Ultimately, an equation is used for the purpose of quantification such that we obtain a CVSS score out of 10 – 10 being the most severe.

With some comprehension of the general CVSS rating, let us move on the automotive realm. We begin with vulnerability identification. This is the first step in building a vehicle vulnerability database. We propose the CVV identifier. It is similar to the CVE naming system, however, capture automobile specific vulnerability information. We begin with the static prefix CVV, followed by the year in which the vulnerability was discovered. Next, we identify the component where the vulnerability is rooted. Different key:value pairs for components are depicted in the table on the right. If the vulnerability is rooted in the infotainment system, we assign it the component ID of 01. Finally, 5 arbitrary digits uniquely identify the vulnerability with the only condition for these digits being that they have not been previously used.

As a real-world example, we assign a CVV identifier to the “Nissan Leaf vulnerability”. The details can be discovered on the linked webpage and in our paper, however, in summary: it was discovered that an application component was deploying VIN as a “secret” for authorization to online services in a HTTP GET request. In terms of assigning an identifier: It was discovered in 2016, in an app/service related component and has a unique number. Therefore, CVV immediately captures time, location, and a searchable attribute of the vulnerability.

That’s for the identification, next we perform quantification. CVSS needs to be adapted for the automotive platform. We provide a set of rules to map CVSS vector values to reflect appropriate scenarios in the automotive space. For example, what do we consider user interaction? In the traditional scenario, it could be a user clicking an email link, however, in the vehicle context, it is a user plugging in a vulnerable 3rd party component and that’s just one example. Attack vector is considered physical when a vulnerability involves physical access to the vehicle hardware. Scope of the vulnerability is changed when keyfob allows physical access which allows access to the OBD2 port. There are several other such rules that are a part of our recommendations.

Next, we rate a real-world vehicle vulnerability. Researchers from University of Twente performed experiments around tracking connected vehicles by identifying the unique digital signatures broadcasted by the vehicles. The NVD NIST link shown provides the detailed vector string and indicates a base score 6.2.

Drilling down in the details, we observe that Attack Vector is marked as Local since the attacker needs to be in the vicinity of the vehicle – this bring down the CVSS rating. However, Attack Complexity is Low since it can be implemented with off-the-shelf equipment and doesn’t require advanced technical skill. Similarly, other vectors are marked. For example, no User Interaction is required, Scope remains unchanged etc.

In conclusion, we focussed on the aftermath of vulnerability discovery. How do we assess the true nature and impact of an automobile vulnerability? How do we track vulnerability introduction? Was it introduced in the design phase? Development phase? Later part of the lifecycle? We can break down a complex attack into multiple vulnerabilities and assign an identifier and rating to each. Ultimately, vulnerabilities are difficult to quantify since they are inherently qualitative in nature. Therefore, validation of the assigned vulnerability rating is limited to an intuitive judgement of the score. Having said that, we noticed that vulnerabilities relevant to the infamous Jeep Cherokee hack gave us the highest score of 9.3 out of all the vulnerabilities we rated. Other vulnerabilities were similarly found to be intuitively accurate. In the future, we wish to perform a more formal validation with industry experts and adjust the scale as necessary. Finally, it would benefit researchers to maintain a central repository focussing on automobile vulnerabilities CVVs and their ratings. This repository can be then be queried to discover patterns such as what components contain the most vulnerabilities. In our analysis of a limited subset of vulnerabilites, we discovered wireless and third party components to be introducing the most security weaknesses.