Anatomy of an Automotive Security Assessment

An Expanding Problem

$1,000,000,000

One billion dollars. According to a 2015 Detroit Free Press article, that was the amount Fiat Chrysler Automotive might have to pay in buybacks and fines due to an automotive cybersecurity vulnerability. That year, Charlie Miller and Chris Valasek had published security research demonstrating the ability to remotely take over and disable any in-the-wild Jeep Cherokee.

The company recalled 1.4 million vehicles as a response to the published findings, and issued a software update to all recalled and affected vehicles. Chrysler was in the midst of a public relations nightmare as the target of the first well-publicized, at-scale cybersecurity attack on a vehicle (see figure 1).

In the seven years since the infamous “Jeep Hack,” the threat landscape surrounding automobiles has changed significantly. Automakers now seriously consider cybersecurity concerns when designing and producing their vehicles, and an entire industry of researchers, educators, engineers, and hackers has spawned from the seeds planted in 2015.

Automobile manufacturers introduce new defenses every single model year: secure gateways, CAN bus network segmentation, automotive ethernet, encryption at rest, and more. Unfortunately, as in the wider cybersecurity industry, researchers and developers find new issues every day, hackers find new techniques to bypass defenses, and new bugs accompany any newly written code.

The Solution

This is where automotive security assessments come in. During one of these, a team of skilled cybersecurity engineers puts a given module, vehicle, or cloud infrastructure through a full-scale, authorized hacking attempt to help the manufacturer remain a step ahead of attackers.  

A Praetorian automotive security assessment uses the same targeted attacks and analysis that attackers will subject the automotive component to after its release, including 

• hardware analysis, 
• reverse engineering, 
• software exploitation, 
• brute forcing, and 
• disassembling the car a bit in the event of a full vehicle assessment. 

Of course, every security engagement is unique, and we tailor each one to account for the specific device’s characteristics and stage of development. Each client also has areas on which they want us to be sure to focus, but regardless of how we customize each assessment, our ultimate goal is to make recommendations on the overall architecture of the device and the root cause of specific findings. Keeping this goal in mind enables us to help our clients go beyond just identifying issues to actually solving their most challenging problems.

Let’s Break It Down

Security as a process is organic, and will twist and change with time and discoveries. That said, at Praetorian we loosely organize each automotive security assessment into the following phases:

• The Recon Phase
• The Scanning Phase
• The Attack Phase
• The Recording Phase

The Recon Phase

This is where it all begins. As with any research step, the recon phase involves reviewing all the documentation that we have on the component in question. The client either provides those resources at the start of the engagement, and/or we use open source online research methods to find what we need. The engagement team can begin the recon phase before they have the product in their hands, allowing them to get a jump-start on the assessment while the component is still in transit. Once an engineer has a device in their hands, they continue the recon phase by taking the device apart, pressing every button, and exploring every possible option, menu, and configuration (if available).

At the conclusion of the recon phase, the team has a clear idea of the architecture of the product, what ‘crown jewels’ or high-criticality assets may exist within the product, and the overall attack path they may take to reach those assets. The team constructs a threat model based on this discovered information, prioritizing high-value pieces of the component, analyzing it from an attacker’s point of view and goals, and documenting these findings in a clear and concise manner to relay to the client. We pause here to converge with the client on the threat model and our prioritization and goals for the assessment. Then we incorporate any tweaks, feedback, or changes they request before moving on to the next phase. Figure 2 shows a sample threat model.

Figure 2: A sample Praetorian threat model for an automotive security assessment.

(For more information on the way Praetorian constructs a threat model, you can check out our helpful blog post: Always Be Modeling: How to Threat Model Effectively)

The Scanning Phase

During the scanning phase, the engagement engineers begin to plot various attacks they could carry out against the product. Recording the product’s normal operating condition is one of the essential steps of this phase. During future attacks, our engineers must understand what parts of the product were affected. If we don’t have logs of a device’s normal messaging via Controller Area Network (CAN), its WiFi connectivity, or its other interfaces, our attacks may cause unknown impacts that we fail to report at the end of the assessment, as in Scenario 1.

Additionally, the scanning phase may provide insight that allows an engineer to further tailor attacks before carrying them out. For example, the recon phase may show that the CAN buses on the vehicle are protected from each other via a centralized Secure Gateway, which acts as a firewall. Developers use this common security method to ensure that even if one piece of the vehicle is compromised, the attacker cannot gain access to the other buses of the vehicle. This usually stops common attack paths, like hacking the infotainment system and attempting to use it to control the vehicle’s brakes! However, sometimes the implementation does not reflect the developer’s intention, as in Scenario 2.

The Attack Phase

This is where the research, threat model, and scanning results all come together to form the perfect attack plan, and the real fun begins! During the attack phase, our engineers use offensive security tools against the component in an attempt to exploit it. This phase can take on a near-unlimited combination of forms, depending on the product being tested:

• Hardware-based attacks: soldering connectors onto debug pinouts, such as JTAG, UART, or SWD
• CAN-based attacks: forging requests, denial of service attacks, or extracting sensitive device information
  • This could be via CAN, CAN-FD, Unified Diagnostic Service (UDS), etc
• Reprogramming-type attacks: installing malicious or vulnerable firmware onto the product
  • This could either be via various data buses, cellular connectivity, WiFi, or even USB
• Wireless attacks: attacks on the product’s access point, or attacks on the product via WiFi connectivity (such as bruteforcing Secure Shell (SSH) access to a product)
• Software-based reverse engineering: efforts to discover overflows, improper data handling, vulnerable libraries, or debug functionality within the firmware of a device
• Attacks on proprietary technology: if a company implemented their own wireless protocol, encryption format, operating system, etc. it most likely hasn’t been vetted for vulnerabilities!

This phase is where the bespoke nature of our approach really shines. Every product is unique in terms of which attacks are useful and successful. Therefore, engineers continuously attack, collect data, fine-tune their approaches, and dive back in. We make a point of communicating daily with the client during this phase.

The Reporting Phase

This one is so much more than the sum of its parts–literally! During the reporting phase, engineers summarize the results gathered during all previous phases of the engagement to give the client a clear picture of their product’s current security posture. Our team provides in-depth write-ups concerning each finding along with a summary of the effective defenses noted during the engagement in one detailed technical report. We take our reporting a step further, however, and provide our analysis of root causes, overarching issues, and business impacts in an executive summary and outbrief. Our intention is to provide as much value added in our written deliverables as possible, to support the client’s efforts to close their security gaps and improve their security posture writ large. 

Conclusion

At the end of an automotive security assessment, the client possesses the path forward to a more secure vehicle, and the assurance that a team of engineers have done their best to hack their component from the perspective of an attacker. While no security is fully air-tight (and if yours is, I’d love to take a crack at it), Praetorian aims to give clients the reassurance they need to launch a product without fear of exploitation and with the confidence that comes when our team of engineers verifies security architecture and design.

Praetorian has taken steps to ensure we also are available to partner with our clients throughout their automotive security lifecycle. We offer re-tests on components as requested, assist the client in understanding and remediating any issues discovered, and provide any post-engagement support necessary. All of the engineers at Praetorian are not only skilled at what they do, but above all else, passionate about it! Hopping on a quick call to walk a client through the process of how a given vulnerability was discovered or exploited, or what it might mean for their bigger picture, is no issue.

If you’ve read this far, automotive security is pretty important to you! I love researching and writing about it, as it’s one of my largest interests. If you have any questions about the blog post or would like to provide any feedback, I would be more than happy to chat! Contact me at tim.tepatti@praetorian.com.

If you are interested in learning more about our Automotive Security Assessment offerings, or the other services that Praetorian can provide, please reach out via our Contact Us page.