How Fuzzing Complements Penetration Testing for Optimal Vehicle Cybersecurity

Penetration (pen) testing is a well-known method for exposing cybersecurity vulnerabilities and other potential security gaps depending on the customer objectives, and validating that the security requirements were implemented correctly.

Whereas the traditional pen testing is a manual process, fuzzing is an automated process. In a fuzzing test, a script inputs massive amounts of different engineered data with the goal of disrupting the target.

A fuzzer can analyze different components of the target (code, binary libraries, interfaces) and create tailor made inputs to achieve the best coverage. A good fuzzing tool can discover vulnerabilities that a researcher may not find during a singular research by overloading a system with a flood of inputs that a penetration tester cannot replicate. Fuzzing has limitations. Whereas a fuzzing test seeks to overload a system (such as an ECU) and see how it reacts, a pen tester attempts to penetrate an attack surface using known and/or zero day vulnerabilities and not an input overload.

The development pipeline in the automotive industry is usually defined as shown in Figure 1 below, from requirements gathering to implementation to release. As shown, in the diagram the testing stage includes two fuzzing tests in addition to manual penetration testing:

• Fuzzing for Code
• Fuzzing for Interfaces

Figure 1 – Automotive development pipeline

This article explains why vehicle manufacturers are introducing fuzzing as a complement to pen testing in order to comply with regulations and achieve optimal vehicle cyber security standards.

Fuzzing for Code

Fuzzing for Code is a technique whereby a specific function is run with many different inputs. Using sanitizers, the fuzzer will catch buffer overflows, memory leaks, and other potential issues. Code fuzzers place instrumentations (for performance measuring) in every code block in the software to understand the coverage the fuzzing gained and to mutate the input so different software flows will be covered.

There are well known open-source fuzzers (AFL, libfuzzer, SymCC, Qsym). Integrating your project with a source-code fuzzer is very similar to unit tests implementation in that the developer has to maintain fuzzing wrappers when developing or modifying a module. Maintaining fuzzing from the beginning of the project will make any future maintenance easier and smoother.

Fuzzing for Interfaces

As the name suggests, Fuzzing for Interfaces tests a specific interface of the system. The tool is protocol-aware (on different levels in different protocols) and can test each of the component interfaces with relevant and tailored inputs. When fuzzing for interfaces is integrated with a compilable environment of the ECU, the coverage gained by the fuzzing can be tracked.

Interface Fuzzing of Stateful Protocols

A stateful protocol is a protocol that retains session information, such as TCP, HTTP, and IP are stateless protocols. Each request message can be understood in isolation. Stateful protocols have implications on the efficiency of the fuzzer. Imagine a standard protocol that starts with a handshake (such as TCP) — a fuzzer that can’t successfully pass the first handshake will miss a lot of code flow possibilities.

An interface fuzzer is a blackbox tool, but it must be configured and directed by a developer or researcher to achieve the best efficiency and coverage.

PlaxidityX Fuzzing for Interfaces can analyze different network schemes (ARXML, DBC) and simulate different attacks based on the scheme. Also, our tool supports many different interfaces and protocols:

• Ethernet standard protocols, SOME/IP, DoIP, HSFZ, AVB
• CAN ISO-TP, CAN-FD, UDS (supported also over LIN and FlexRay)

Fuzzing for code and Fuzzing for Interfaces can be integrated into the CI environment, unlike the next testing stage—penetration testing.

Penetration Testing

Automated testing and fuzzing are innovative and efficient for bugs and vulnerabilities scanning, but automated tests will never replace manual penetration testing to ensure a system is not exploitable. There are still no automated means of mapping ECU attack surfaces, reverse engineering the flow of all surface code, finding primitives and binding them together in order to manage an entire cyber attack research operation.

Integrity validation of the security measures a system has (Secure boot, software hardening, …) requires the talented hands of experienced researchers. That’s why near the end of the development cycle, the ECU should be manually pen tested by security researchers. We recommend both fuzzing and pen testing to achieve UNR 155 (WP.29) compliance and to ensure optimal vehicle cybersecurity.

Ohad Peled
PlaxidityX Embedded Security Research Team Leader

Blog Editor’s Note: If your OEM, Tier 1 or Tier 2 company would like more information regarding fuzzing or penetration testing, fill out the below form and we will get in touch.