By 2025, forecasts predict that there will be hundreds of millions of connected vehicles on the road. The decision-making process in the car is gradually handed over to machine learning and rule-based algorithms. More and more computerized features are being integrated inside vehicles to maximize our experience behind the wheel.
However, innovation comes at a cost – hackers are constantly on the lookout for ways to exploit these new technologies in order to penetrate the vehicle systems. Unfortunately, their possibilities are endless. From attacks that rely on physical access to remote attacks using off-board devices such as smartphones, and supply chain or aftermarket attacks. These threats can put an entire fleet at risk. As such, the automotive cyber threat landscape is becoming increasingly complex as the industry struggles to secure vehicle systems and keep safety and privacy a top priority.
In this article, we will focus on the field of software development with cyberattacks in mind. We will review software development in the automotive world, list the most common vulnerabilities at the hacker’s disposal, and show proven examples of exploitation based on penetration testing of Argus Cyber Security research team. Finally, we will discuss the importance of cybersecurity in significantly reducing risks.
Software Development in the Automotive World – Uniqueness and Security Concerns
There are many similarities between developing software for vehicles and other systems. As such, the Software Development Life Cycle (“SDLC”) is also similar. It involves planning, analysis, design, development and implementation, testing, and maintenance. That said, the complex and regulated nature of the automotive industry requires developers to take into account critical and unique considerations.
Technical Considerations – safety-critical core ECUs may be based on Classic AutoSAR, which communicates using CAN bus, FlexRay, or MOST protocols optimized for automotive (with the exception of connected ECUs that typically run on Linux, QNX or Android systems). Classic AUTOSAR is restricted in functionality when compared to Linux and other open-source operating systems. Given its lack of popularity, many vulnerabilities in Classic AutoSAR are yet to be discovered and hackers may find them relatively easy. On the network level, the development of in-car-oriented protocols involves various security issues; the usage of CAN bus, for example, permits any ECU to send commands to another without being authorized, allowing hackers to control an ECU as if they were a legitimate party.
Business Considerations – OEMs aim to incorporate as many connectivity platforms to the vehicle as possible by Bluetooth, NFC and Wi-Fi to our smartphones, and by dedicated protocols to other cars in the fleet and to its environment. However, wireless-enabled systems expose the car and its passengers to a whole new world of threats – the more connected the vehicle is, the higher the risks. The examples are plentiful: getting cross-fleet information creates a risk of being attacked via cars from the same fleet or through the automotive SOC. Connectivity to leading wireless standards such as Wi-Fi and Bluetooth may be penetrated via smartphone. In other words, every new technology requires a whole new set of considerations in order to prevent exploitation by hackers.
Impact and Complexity – there can be far-reaching, life-endangering implications caused by an overlooked vulnerability in the software development process. Unlike many other industries, the associated risks require developers to make zero mistakes. Moreover, it is still not simple to update the vehicle easily (e.g. using “Over-the-Air” updates) in connected cars, and therefore, every development must meet security standards planned for a few years in advance.
Above all, given the rapid pace of the cyber world along with the under-investigated automotive market, it is a matter of time from the moment an experienced hacker decides to attack a vehicle until they find a vulnerability to exploit.
Innovation comes at a price – hackers are constantly on the lookout for ways to exploit these new technologies in order to penetrate the vehicle systems
Vulnerabilities may exist in the software that runs the vehicle and are often classified into two types: design and implementation. It is crucial to take into account at least the known vulnerabilities from the early stages of the software development and through to the testing phase.
- Architecture and Design vulnerabilities are flaws in the system logic itself. While the system operates as intended, it exposes assets due to the mishandling of unforeseen edge cases.
- Implementation vulnerabilities are caused by improper implementation of the system logic. Data corruption causes the program to behave in unintended ways, depending on how data is represented and interpreted.
Argus Cyber Security’s research team provides OEMs and Tier 1s a wide range of services to support the cybersecurity of their vehicle fleets throughout their lifetime. Services include threat analysis and risk assessment, vulnerability assessments, and penetration tests, which together help to identify security gaps as early as possible.
After completing dozens of projects, the team has gained extensive knowledge in cybersecurity threats in the automotive domain and have identified many common weaknesses, CWEs (Common Weakness Enumeration. A CWE describes a vulnerability that is not related to a specific application.
Here are some examples of CWEs that malicious attackers can exploit:
- Design & Implementation CWE: Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’) (“CWE-22”). External input to the software is needed to construct a relative pathname in a restricted directory. Since the software doesn’t properly neutralize special elements within the pathname, the resulting pathname may point to resources outside of the restricted directory. Exploiting this weakness allows an attacker to read any file on the system, effectively leaking information about processes and other sensitive information stored in the file system.
- Implementation CWE: Information Exposure (“CWE-200”) is accidental or malicious exposure of information to a party that is not explicitly authorized to access this information. A significant concern regarding automotive security is privacy: for example, leakage of the driver’s personal information, sensitive OEM information, or a car database containing the details of dozens of users.
A known example to demonstrate this CWE is CVE-2017-1000250, a Bluetooth vulnerability for Linux devices. This CVE is a part of “BlueBorne”, an attack vector found in Bluetooth connections. The exploitation of this vulnerability can put any Linux infotainment system at risk.
- Implementation CWE: Integer Overflow or Wraparound (“CWE-190”) – an incorrect calculation can produce an integer overflow or wraparound, where the resulting value is larger than the predefined space. Integer Overflow occurs in CVE-2016-6250, in the libarchive (multi-format archive and compression library) before 3.2.1. This CVE allows remote attackers to perform a denial of service (application crash) or remote code execution.
- Design CWE: Improper Authentication (“CWE-287”) – when a hacker claims to have a given identity, the software will not insufficiently prove that the claim is correct. An example of this CWE is CVE-2018-13908, which leads to a lack of control in access for storing secure data. The exploitation of this vulnerability is common in automotive penetration tests.
The potential damage may include data theft, risk to customer privacy, damage to the OEM’s reputation, financial loss, loss of lives, and various other severe consequences.
The more connected the vehicle is, the bigger can be the risk
Mitigation Best Practices
An effective approach for mitigating risks is to look beyond software development and towards the broader vehicle architecture. In comparison to other industries, the automotive world is extremely complex, laying down numerous layers of protection – hardening the core and the connected components inside the vehicle, the backend, the connectivity to the car, the production lines, the supply chain, and the aftermarket products.
In order to reduce the motivation of hackers, we need to create more points of resistance. In automotive, this means reducing the cost-effectiveness across financial, technological, and practical terms. The process of protecting the vehicle is as follows:
Security by Design
The software needs to be designed from the foundation to be impervious. Examples are:
- Segmented architecture – placing a gateway and domain controllers to separate safety-critical ECUs from connected ECUs. This limits the hackers’ ability to perform lateral movement in the vehicle
- Perform a Threat Analysis and Risk Assessment (TARA) – identify potential security gaps and vulnerabilities in a vehicle platform, architecture, or component during the design phase of the vehicle and build the security concept accordingly. The risk factor for each threat scenario is assessed according to the likelihood of its occurrence and potential impact, with recommendations for mitigation and security requirements
- Design according to standards, regulations and best practices published by the automotive industry
Cyber-Secure Implementation and Prevention
The standardization of security protocols within networks, components, and OEM servers to improve overall security, as well as hardening of all parts of the production. Examples are:
- Training developers in secure coding – to make an impact already in the development stages and to see cybersecurity as a fundamental part of implementation
- Code reviews – identify potential security gaps in application software, device firmware, communication protocols and implement recommendations for closing the security gaps
- Deployment of firewalls – firewalls based on Deep Packet Inspection for filtering the payload field
- Memory protection – control flow integrity for validation of software in boot and runtime
- Deployment of threat detection systems on host modules – solutions that detect anomalies on individual systems, log those anomalies so they can be sent to OEM security analysts to investigate and determine the applicable response
- Deployment of network intrusion detection systems with optional prevention – intrusion detection and prevention modules can detect anomalies in the vehicle network, then alert, mitigate the risk in real-time or control the alert
- Penetration Testing – these projects help the customer identify vulnerabilities on the target component through its interfaces and communications channels with the outside world, and validate that security requirements were implemented effectively
- Software encryption – cryptographic algorithms and operations make it difficult for malicious actions to perform
Life Cycle Management (Security Post-Production)
The process of managing the entire lifecycle of the system from the moment the vehicle leaves the factory until decommission. Examples include:
- Manage the lifecycle of a detected threat – supported by a professional automotive Security Operation Center, which specializes in incident management, investigation and response of cyber incidents affecting vehicles and fleets
- Monitor logs from the car and the fleet – detect threats of connected car services using detection engines
- Vulnerability management – using investigation and reporting tools to analyze threats and to make the decision making as easy as possible
- Ongoing manufacturer updates and policy security updates – to significantly reduce the time-frame for a hacker to find a vulnerability and exploit it by consistently updating and upgrading the software
If you put enough protection layers across numerous platforms before the software, the risk of exploited weaknesses in the software will be significantly lower – even if it is vulnerable by design, it will be equally more difficult to penetrate.
As mentioned above, hackers will typically take the path of least resistance. The automotive industry needs to create as many obstacles as possible to discourage hackers. In order to protect a car, we need to view cybersecurity in a holistic manner, from the fleet to the last component inside the car. Therefore, developing software in a secure way is the only one step towards protecting the entire vehicle.
Get the Japanese Version
The article was posted in “Automotive Technology June 2020 edition” Technical Information Institute Co., Ltd.
Author: Tamir Rahamim, Cyber Landscape Analyst
at Argus Cyber Security