First Steps to Defense

Motivation: Why hack cars?

Vehicle-related systems have always been a target of hacks. Still, these have recently become a big enough concern for automakers and the rest of the supply chain to scramble for solutions. Understanding the main motivations of vehicle hackers may help explain some of this lack of concern and help prioritize fixes.

In this section, we will discuss some of the reasons why people resort to hacking computer systems on cars and which types of hacks we should prioritize defending against.

Motivation: The Good

Historically, hacks are often done or requested by owners of the vehicle themselves, wanting more features out of the car. Sometimes this is to avoid paying expensive service fees at the dealership, and sometimes it is because the official channel does not even provide the desired services.

These types of hackers include:

1. The performance tuning hobbyist and racers who wanted to tune their cars to get more power and torque and better handling. This often requires modifying engine and transmission software calibrations.
2. Aftermarket modification or new component developers whose product requires adding/deleting/modifying certain existing functions for them to work. For example, a premium aftermarket speaker system would require a replacement of the original head unit, but the new part would still need to work with the rest of the car’s controls.
3. The people who salvage or purchase used components, such as heated seats, and want to install these components into their cars. Even though the vehicle already has the necessary hardware, often, the software will need to be configured (turning on a feature) to support the function.
4. Independent shops and home mechanics. As cars become more complicated, diagnosing issues becomes very difficult. Standardized (free) diagnostic tools are limited and provide little to no information on non-emissions issues. For example, if your ABS suddenly doesn’t work and shows a warning light, most diagnostic scanners cannot provide much helpful information because ABS is not emissions-related. However, the dealership can scan for exactly which sensor is broken and needs to be replaced using OEM diagnostic tools. This tooling and information would be handy and save a lot of time, effort, and cost for anyone who repairs cars. Some have reverse-engineered OEM tools and built third-party tools using the extracted information.

Since these tinkering activities are not a profitable business case for manufacturers to officially support, in fact, they may affect their service revenue and reduce new car sales. Various enthusiasts started making a business out of “hacking” vehicles. These activities may not be seen as hacks, but the vehicle’s computer systems are indeed being compromised and modified to achieve the outcome the vehicle owner wants. While the activities themselves may not be harmful or even encouraged, the vehicle’s design needs to account for the possibility of these attack channels being exploited maliciously.

However, manufacturers may view this activity as unauthorized if the vehicle owner unlocks software features they did not pay for or if the company believes there is risk associated with the behavior.

Motivation: The Bad

Nefarious car-hacking-related activities are usually for financial gain, and vehicle theft is the most prevalent example in the automotive domain. Unfortunately, these crimes are also committed with no real motive other than for attention. Because some vulnerabilities are exploitable with such low effort or knowledge of vehicle systems, the attitude behind the theft is often “Because I can.”

The “Kia Boys” is an example of a group exploiting a weakness in the vehicle’s ignition system. As you can see in the video, they don’t need a sophisticated understanding of vehicle systems to pull off the attack. The lower the barrier to entry, the more likely the vehicle will be attacked, regardless of potential gain.

Although most car thefts have historically been hardware-based, modern anti-theft features such as immobilizers would prevent car thieves without the correct digital key from switching on the ignition. Car thefts have evolved to target key fobs or keyless systems by relaying signals from keys that unlock the vehicle based on proximity, decoding the wireless transmissions to extract the digital key, and stealing keys from manufacturer databases.

Another type of (potential) attacker looks to gain remote control over entire vehicle systems and infrastructure. These attacks infiltrate vehicle networks through long-range remote attack surfaces such as the vehicle’s internet connectivity and other wireless signals. The attacker then injects and overrides network traffic to be processed by the car as if it were a legitimate signal. The most likely threat actor that could execute this type of attack on a wide scale would be a nation-state-level actor, as it is a long and challenging process, and there is no apparent personal gain from these types of attacks.

This, in theory, poses the most significant risk to personal safety and the economy as it could potentially shut down fleets of vehicles at a time. However, there have not been any known cases of such attacks outside of well-funded research.

Future Considerations:

Vehicles are becoming increasingly involved in our daily lives for features other than driving. Integration with smartphones and paying for movies or car upgrades involves storing the user’s personal and financial information on the vehicle computer. This creates a new motivation for bad actors to steal user information for credit cards or identity theft.

Admitting the Problem

There is a common misconception that one can build an “unhackable” system. People who boast about such will quickly regret their decisions, as their own website or product is usually swiftly hacked, and the exploit is posted for everyone to see. Many proud and capable people will see such claims as a challenge.

Examples:

• A third-party car alarm vendor advertising products as ‘unhackable’ on their website takes down claims after security researchers show that the car becomes even less secure after installing their alarms. Source: https://www.pentestpartners.com/security-blog/gone-in-six-seconds-exploiting-car-alarms/
• McAfee’s BitFi crypto wallet got so FAMOUS for its being repeatedly hacked that if you google “McAfee BitFi,” the top results are all about this PR disaster of insisting that the product was “unhackable” and even refusing to pay researchers who successfully demonstrated defeating the protection. Great negative publicity there. Source: Google search.

Lesson #1: Do NOT claim something is “unhackable” unless you want it hacked ASAP and the method leaked publicly. Instead, encourage responsible disclosure by creating incentives (even a little is often enough) and being respectful to the research community that helps discover vulnerabilities in your system in a non-harmful way. Admitting the problem is the first step toward resolution. It is equally important to assume it will be attacked and hacked when you design security. To prepare for this reality, you can design and implement specific product capabilities that allow you to deploy patches quickly to your products, such as Software Over the Air update capabilities. In addition, you should design a defense-in-depth security strategy that creates an overall robust security posture. This approach will help improve the automaker’s ability to respond to the attacks and deploy ongoing fixes for vulnerabilities that impact their products currently and into the unknown future.

Our simple recommendation: Set up a bug bounty program to leverage the research community in helping to catch security issues through official, mutually beneficial ways.

Set up the Right People

QUESTION: How do we improve our security posture once we recognize the problem?

Security Posture: The security posture of a company is the security status of an enterprise’s networks, information, and systems based on information security resources (e.g., people, hardware, software, policies) and capabilities in place to manage the defense of the enterprise and to react as the situation changes. (NIST SP 800-128)

For the automotive industry, the security status of its products (vehicles) is part of evaluating its security posture, as a lousy security posture on vehicles will affect the OEM’s reputation and may have legal consequences.

Blue Team: Companies will generally employ or contract cybersecurity specialists to design asset protection and develop infrastructure that allows them to react quickly and minimize damage from hacks. The team responsible for maintaining a good security posture and defending against attacks is called the Blue Team.

The cybersecurity manager and engineer roles are often part of the Blue Team, as they are responsible for the security posture at vehicle, system, or component levels. Blue Team activities, such as analyzing risks and vulnerabilities, implementing protective measures, and continuous monitoring activities, are covered in detail in the Plunge Advanced track.

Red Team: To validate the effectiveness of the Blue Team’s work, companies employ or contract cybersecurity experts who perform various types of attacks against their infrastructure and products. The Red Team is responsible for finding any vulnerabilities in the current system that the Blue Team may have missed and reporting this to the company. They are effectively hired hackers.

Penetration testing is a part of the Red Team’s activities, in addition to other methods of testing. Red Team activities such as penetration testing and fuzzing are covered in detail in the Plunge Advanced track.

When organizations are not large enough to have both teams, the Blue Team must remain up-to-date with Red Team knowledge and understand the types of potential attacks that could be mounted against protected assets. Many well-known hacks occur because the individuals that designed the defense system may not completely understand how everything works from the attacker’s point of view.

Fun Fact: When the encryption algorithm for DVD was introduced, it was already well known that the key length used was laughably short in the face of increasing computer processing power and was defeated entirely within a few years of its launch. If the engineering team who designed and implemented the DRM systems were more knowledgeable of the attack methods their opponents could use, they would have undoubtedly been able to avoid the rampant DVD piracy for much longer.

Finding Vulnerabilities

The definition of vulnerability for cybersecurity systems is a “Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.” per NIST SP 800.

Hacks happen due to people finding vulnerabilities in target systems and then using them to exploit the system. So logically, a system with no vulnerabilities is genuinely unhackable. However, as we discovered earlier, this is not a simple feat.

Development teams will not be able to keep a product permanently vulnerability-free, so they instead analyze and prioritize vulnerability fixes for incremental releases (this is why you see known security issues in software version release notes all the time).

Even if a system has no known vulnerabilities at the time of release, vulnerabilities could be discovered and exploited to cause issues. Therefore, a company must keep track of known and new vulnerabilities that may affect its systems and products and analyze, rate, and plan fixes for ones with a high risk of being exploited and causing damage.

Continuous vulnerability monitoring and management is an essential part of Blue Team activities for compliance with ISO/SAE 21434 and, more generally, to stay ahead of attackers. We will discuss the tools and methods used in the Advanced track.

To summarize it in a sentence: Stay up-to-date on vulnerabilities that may affect your system and products and have a plan on how to handle them.

Evaluating the Risk

When designing a system, it is essential to start thinking about goals early in the process. For cybersecurity, this means identifying where the attacks could come from and where an exploit could cause the most concern early in the design stage. The general network architecture and hardware requirements are still flexible to change. Therefore, it could greatly simplify the design of defensive measures and reduce development costs.

There is a formal process called out by the ISO/SAE 21434:2021 standard for identifying high-value assets and likely attack sources, then evaluating the amount of risk for each scenario so that it can be used to form a priority list of cybersecurity goals. This activity is known as a Threat Analysis and Risk Assessment, or TARA for short. We will cover TARA methods in detail in the Advanced TARA course.

For each vulnerability identified by TARA or from a known database, the associated risk can be addressed in one of four ways: avoid, reduce, share, or retain the risk. Avoiding is changing the product and modifying its functionality to delete the vulnerable feature. Risk reduction is similar to avoidance but can be done by implementing security measures to limit the level of risk. Sharing the risk is distributing the responsibility, such as through insurance. Risk retention is the decision to do nothing and accept that the risk is acceptable. Decisions must be made when considering the amount of risk, the effort required for each option, time and resource constraints, and regulatory requirements. At best, nothing bad happens if a vulnerability is never exploited for various reasons (luck included). In the worst case, companies may face millions of dollars in recalls, damage to brand image, or legal trouble if critical systems go into production without appropriate cybersecurity risk treatment.

Priorities are different for each manufacturer. Performance-centered brands may have many customers that enjoy tuning and customizing their cars. In this case, the manufacturer may transfer some risk to this type of customer by signing an agreement to void some safety claims and warranty. Others may focus on the newest user experience features, connected services, and advanced ADAS features, which require a lot of effort and cost to reduce cybersecurity risks.

A simple way to understand the risk of a scenario is to consider the likelihood of it happening and the impact that it would have. It is up to each automaker to decide what acceptable risk looks like for their product.