AutoSec 2020 - Ransomware Targeting Automobiles

Transcript

The idea of a ransomware in the automotive context seems relatively novel. We would like to begin by stating that to the best of our knowledge, no ransomware have been observed on the automotive surface in the wild. Then why are we considering this a threat for vehicles? There are 2 primary reasons for that:

• ransomware have grown to be the top threat to cybersecurity in the the recent years. Ransomware-as-a-service on the dark web is highly developed and threat actors are constantly evolving targeted and manual attacks on organizations for the purpose of higher ransom demands. These demands are now in the magnitude of 100s of 1000s of dollars.
• malware operators have enjoyed phenomenal success in exploiting poorly configured IoT devices. For example, the Mirai botnet exploited default credentials. Since vehicles are members of the IoT, they are now exposed to advanced threats such as ransomware.

Therefore, it seems highly probable that these opportunistic attackers will shift their focus on the automotive platform eventually. There is a need for recognizing and eliminating vulnerabilities before their active exploitation in the wild – especially since transportation systems safety is a critical concern.

In traditional computing environments, the focus of ransomware attacks has traditionally been the denial-of-data. Certain novel variants are also observed branching out to denial-of-privacy where they threaten to release private data unless they are paid the ransom. In the context of vehicles, denial-of-data is relatively convoluted to achieve since it is unclear how much irreplaceable data resides on the average automobile. There’s undoubtedly data on the infotainment system but may not be enough for a ransom extraction. We therefore anticipate attackers adopting denial-of-privacy and denial-of-service attacks. DoS attacks are highly probable in the vehicular context since uninterrupted access to services is critical. Denial-of-privacy attacks may focus on extracting the personal data resident on the infotainment system, for instance, texts, call logs, GPS data etc. Figure 1 illustrates attacker’s view of the attack surface. There was two sets of controls to bypass: the external set seek to prevent unauthorized access from public networks and interfaces on, for instance, the IVI system. The internal set seek to prevent access to the more mission-critical subsystems such the ECUs on the CAN. If we consider the multics rings of access, the CAN network can be ring 0, whereas the IVI system can be ring 2. Therfore, the quality of these filters now dictates the security of the automobile. During this paper, we triaged our efforts towards testing the external filter.

Automotive security can be especially challenging since many assumptions that are true in traditional IT environments are incorrect for automobiles. For instance, cybersecurity standards proposed are relatively new and untested. Also, the lifespan of a vehicle can be approximately 15 years which implies that at some point we will be driving in an automobile where security controls are 15 years old. Unless over-the-air updates becomes easily accessible for automobiles. Moreover, the computing resources are limited in automobiles which makes advanced dynamic detection and response mechanisms infeasible. Finally, security testing is limited to a blackbox-only approach in automobiles since the relevant proprietary technology implemented within is not always publicly documented. In contract, both white and blackbox testing are common in standard IT systems. We have documented several other differences which makes automotive security challenging.

Taking an adversarial approach to ransomware in the context of automobiles, we attempted to mimic discovery and attack patterns that are commonly observed in malware. The fist step is always reconnaissance – which is a careful study of the target system. In our case, the target was an infotainment system sitting on a QNX box. QNX RTOS or real-time OS is a popularly used in automobiles, medical devices, transportations, robotics etc. It can be configured to run any number of services required of the platform which provides an opportunity for misconfiguration and ultimately potential exploitation. In our case, we performed preliminary port scanning of the platform as shown in Figure 2, which revealed an open tcp port 8000 which ultimately turned out to be a QCONN service. QCONN services are run on development nodes to achieve connectivity with the test platform during debugging exercises. When integrated into production environments, QCONN becomes a vulnerability since the service runs unauthenticated and allows execution of arbitrary code on the platform. We tested this hypothesis by connecting to the service using the gdb debugger and uploading and executing arbitrary binaries on the system. Finally, we performed stress testing to gauge system response against resource exhaustion. During testing, we executed a simple fork bomb that creates replica processes meant to exhaust processing and memory resources.

So what did we learn during testing? Since automobiles have limited computing resources with no protections against resource exhaustion by runaway processes, at least none that we observed, there are highly vulnerable to denial-of-service attacks. At the same time, vehicles have a strong requirement for uninterrupted testing – even from the IVI system. A minor distraction during driving is enough to cause an incident. Traditional ransomware do not alter data impartially. There seek artifacts-of-interest such as PDFs, DOCx etc. using a list of hardcoded file extensions. For the IVI system, there is a need to delineate such artifacts-of-interest or the data to be protected or kept private since ransomware are likely to use such data for extortion.

Ultimately, for financially-motivated threat actors the decision to attack a vulnerable component boils down to 2 considerations:

• the level of complexity involved AND
• the associated reward, which, in this case, is the financial gain
• the associated gain is further broken down into:
  • the level of impact and the multiplier N. the more the impact, the higher the gain.
  • the multiplier N becomes large in the case of vehicles. Here, N denotes the number of entities that can be infected using the same, unaltered killchain. Again, the higher the value of N, the higher is the gain.

Therefore, there is reward, but so far the level of complexity involved has deterred ransomware operators from focussing on automobile platforms.

We are now equipped with the knowledge necessary for constructing a killchain for ransomware operators in the automobile context. Crypto or DoS ransomware need to achieve host infiltration and subsequent execution in order to affect undesirable changes in the system. Next, they perform service and data enumeration to discover artifacts-of-interest. Next, key generation or secret generation ensures attackers possess a unique knowledge for which the victim will pay the ransom. This secret needs to be protected until ransom payment. Finally, victim’s access to the data/service is removed, thus causing interruption and demanding ransom payment. For automobile platforms, bulk of the security effort is geared towards preventative controls, however, there is a lack of threat detection, response, and recovery solutions for threats that bypass preventative controls.

So how would ransomware bypass preventative controls. The most common attack vectors likely to utilized are shown in the image. Configuration and design errors are have been the favorite of IoT attackers for a longtime. Aftermarket or 3rd party addon products that weaken the security of the automobile platform are another likely target. And finally, ransomware operators have been known to seek exploitation of poorly authenticated remote access services. Any such services exposed on “smart” automobile platforms are prime opportunities for infiltration.

Once inside, a traditional crypto-ransomware will seek to implement a hybrid cryptosystem for a denial-of-data attack. Listing 2 shows implementation of the hybrid cryptosystem where a symmetric key is deployed in data encryption and an asymmetric public key is used to encrypt the symmetric key. Ransomware seek abstraction to avoid implementing crypto from scratch and in the Listing shown we have deployed the openssl library for this abstraction. Ultimately, any cryptographic library available on the platform will serve the attacker’s needs.

In the case of a Denial of Service ransomware, resource exhaustion is easily achieved by hogging compute cycles until a ransom is paid. In our initial experiments, we observed complete resource exhaustion as shown. Figure 4 shows cpu and memory load before and Figure 5 shows after the detonation.

In conclusion, ransomware attacks are viable on automotive platforms since we were able to satisfy all constraints in the killchain during initial testing. As other IoT systems, configuration and authentication errors will provide a likely door for entry. Once inside, the malware will attempt disruption to create the leverage necessary for ransom extraction. In our future work, we will investigate other operating systems such as threadx and INTEGRITY and extend experiments to real-world settings. Ultimately, with this paper, we wish to highlight the need for better detection, response and recovery solutions for threats that make it in.