By 2025, forecasts predict that there will be hundreds of millions of connected vehicles on the road. In-car decision making is gradually being transferred to machine learning and rules-based algorithms. More and more computerized features are being integrated into vehicles to maximize our experience behind the wheel.
However, innovation comes at a cost: Hackers are constantly looking for ways to exploit these new technologies in order to break into vehicle systems. Unfortunately, their possibilities are endless. From attacks that rely on physical access to remote attacks using external devices such as smartphones and supply chain or after-market 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 protect vehicle systems and keep security 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 available to the hacker, and show proven examples of exploitation based on penetration testing by the Argus Cyber Security research team. Finally, we will discuss the importance of cybersecurity in significantly reducing risk.
Software development in the automotive world - uniqueness and safety concerns
There are many similarities between vehicle software development and other systems. As such, the Software Development Lifecycle (“SDLC”) is also similar. It includes planning, analysis, design, development and implementation, testing and maintenance. That said, the complex and regulated nature of the auto industry requires developers to take critical and unique considerations into account.
- Technical Considerations: Safety-critical core ECUs can be based on Classic AutoSAR, which communicates using automotive-optimized CAN bus, FlexRay, or MOST protocols (except for connected ECUs which typically run on Linux, QNX, or Android systems) . The classic AUTOSAR has limited functionality compared to Linux and other open source operating systems. Given its low popularity, many vulnerabilities in Classic AutoSAR have yet to be discovered, and hackers may find them relatively easy. At the network level, the development of car-oriented protocols involves several security problems; using the CAN bus, for example, allows any ECU to send commands to another without being authorized, allowing hackers to control an ECU as if they were a legitimate part;
- Business considerations: OEMs aim to incorporate as many vehicle connectivity platforms as possible via Bluetooth, NFC and Wi-Fi to our smartphones and protocols dedicated to other cars in the fleet and its environment. However, wireless-enabled systems expose the car and its passengers to a whole new world of threats - the more connected the vehicle, the greater the risks. There are numerous examples: obtaining information on multiple fleets creates the risk of being attacked via cars from the same fleet or via automotive SOC. Connectivity to major wireless standards such as Wi-Fi and Bluetooth can be achieved via smartphone. In other words, each new technology requires an entirely new set of considerations to prevent exploitation by hackers;
- Impact and Complexity: There can be far-reaching and life-threatening implications caused by an overlooked vulnerability in the software development process. Unlike many other industries, the associated risks require developers not to make mistakes. Furthermore, it is still not easy to easily update the vehicle (for example using “Over-the-Air” updates) in connected cars, and therefore each development must meet the planned safety standards a few years in advance.
Most importantly, given the rapid pace of the cyber world coupled with the under-researched automotive market, it's a matter of time from the time an experienced hacker decides to attack a vehicle until he finds a vulnerability to exploit.
Common vulnerabilities
Vulnerabilities can exist in the software that manages the vehicle and are often classified into two types: design and implementation. It is critical to consider at least known vulnerabilities from the early stages of software development through to the testing stage.
The vulnerability of the architecture and design are flaws in the logic of the system itself. Although the system works as expected, it exposes resources due to mishandling of unexpected edge cases.
The implementation vulnerability they are caused by an incorrect implementation of the system logic. Data corruption causes the program to behave in unexpected ways, depending on how the data is represented and interpreted.
Argus Cyber Security's research team provides OEMs and Tier 1s with a wide range of services to support the cybersecurity of their vehicle fleets throughout their lives. Services include threat analysis and risk assessment, vulnerability assessments and penetration testing, which together help identify security gaps as early as possible.
After completing dozens of projects, the team gained extensive knowledge of cybersecurity threats in the automotive domain and identified many common weaknesses, CWE (Common Weakness Enumeration. A CWE describes a vulnerability not related to a specific application.
Here are some examples of CWE that attackers can exploit:
- CWE design and implementation: Improper restriction of a path name to a restricted directory (“Path Traversal”) (“CWE-22”). External input to the software is needed to construct a relative path in a limited directory. Since the software does not properly neutralize the special elements within the path, the resulting path can point to resources outside the limited directory. Exploiting this weakness allows an attacker to read any file on the system, effectively leaking process information and other sensitive information stored on the file system;
- CWE Implementation: Information Exposure (“CWE-200”) is the accidental or malicious exposure of information to a party who is not explicitly authorized to access this information. A significant concern regarding automotive safety is privacy - for example, leaking driver 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 part of "BlueBorne", an attack vector found in Bluetooth connections. Exploitation of this vulnerability could put any Linux infotainment system at risk;
- CWE Implementation: Integer Overflow or Wraparound (“CWE-190”) - an incorrect calculation can produce an entire overflow or wraparound, where the resulting value is greater than the default space. Integer Overflow occurs in CVE-2016-6250, in libarchive (multi-format archive and compression library) prior to 3.2.1. This CVE allows remote attackers to perform a Denial of Service (application crash) or code execution remotely;
- Design CWE: Improper Authentication (“CWE-287”): When a hacker claims to have a certain identity, the software will not sufficiently prove that the claim is correct. An example of this CWE is CVE-2018-13908, which leads to a lack of access control for secure data storage. Exploitation of this vulnerability is common in automotive penetration testing. The potential harm can include data theft, customer privacy risk, damage to OEM reputation, financial loss, loss of life, and various other serious consequences.
Best practices for mitigation
An effective approach to mitigating risks is to look beyond software development and towards the broader vehicle architecture. Compared to other industries, the automotive world is extremely complex and establishes numerous layers of protection, strengthening the core and connected components within the vehicle, the backend, the connectivity to the car, the production lines, the supply chain and the after-market products.
To reduce the motivation of hackers, we need to create more points of resistance. In the automotive sector, this means reducing cost-effectiveness in financial, technological and practical terms.
Safety by design
The software must be designed from the ground up to be waterproof. Examples are:
- Segmented architecture: Placement of a gateway and domain controller to separate safety-critical ECUs from connected ECUs. This limits the hackers' ability to perform lateral movements 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 vehicle design phase and build the security concept accordingly. The risk factor for each threat scenario is assessed based on the likelihood of 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 OEM networks, components and servers to improve overall security as well as strengthen all parts of production. Examples are:
- Secure coding developer training - to have an impact already in the development phases and to see IT security as a fundamental part of the implementation;
- Code reviews: identify potential security gaps in application software, device firmware, communication protocols and implement recommendations to fill the gaps;
- Firewall deployment: firewall based on Deep Packet Inspection to filter the payload field;
- Memory protection: flow integrity check for software validation during startup and runtime;
- Implementation of threat detection systems on host modules: solutions that detect anomalies on individual systems, record these anomalies so that they can be sent to OEM security analysts to investigate and determine the applicable response;
- Implementation of network intrusion detection systems with optional prevention: the intrusion detection and prevention modules can detect anomalies in the vehicle network, then alert, mitigate the risk in real time or check the alert;
- Penetration Testing: these projects help the customer to identify vulnerabilities on the target component through its interfaces and communication channels with the outside world and validate that the security requirements have been implemented effectively;
- Software encryption: Algorithms and cryptographic operations make it difficult to perform malicious actions.
Life cycle management (security post production)
The process of managing the entire life cycle of the system from the moment the vehicle leaves the factory until it is taken out of service. Examples included:
Manage the life cycle of a detected threat, with the support of a professional automotive Security Operation Center, specializing in incident management, investigation and response to cyber incidents affecting vehicles and fleets
Monitor Car and Fleet Logs - Detect threats from connected car services using detection engines
Vulnerability Management: Use of investigation and reporting tools to analyze threats and make decision making as simple as possible
Continuous manufacturer updates and policy security updates - to significantly reduce the time it takes for a hacker to find a vulnerability and exploit it by constantly updating and updating software
If you put sufficient levels of protection on 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 still be more difficult to penetrate.
