Risk Assessment for UN R155: A Closer Look at Vehicle Fuzzing

Have you ever wondered how vehicle manufacturers secure vehicles from cyber threats? The cybersecurity implementation process starts way before the vehicle hits the road and encounters any threats. During the manufacturing process, security experts hack the vehicle’s system to uncover any bugs and vulnerabilities that may be present in the embedded code. There are many different ways of doing that. One of them is called fuzzing. Fuzzing is a software risk assessment method that involves overflowing the system with random inputs to uncover bugs and vulnerabilities that are difficult to find through other testing methods. Fuzzing is done to test the vehicle’s software during the development process to make sure that the software is reliable and can be released to consumers.

Why do we need vehicle fuzzing?

In the automotive industry, original equipment manufacturers (OEMs) face regulatory obligations to address vehicle security risks. Compliance with UNECE WP.29 Regulation No. 155 (UN R155) requires vehicle manufacturers to implement an automotive cybersecurity management system (CSMS) to verify appropriate security measures in vehicle architecture. Here, the security measures signify comprehensive risk assessment, risk management, and mitigation procedures.

During the type approval process, manufacturers must verify the sufficiency of cybersecurity measures by demonstrating their risk identification and testing practices. Here is where fuzzing comes in.

Fuzzing is a technique for detecting software vulnerabilities by inputting intentionally invalid and unexpected data into the selected program with the intention to crash it. Doing this helps detect bugs and vulnerabilities in the software that may have not been found otherwise. Vehicle fuzzing can be viewed as an essential and comprehensive way to test if the system functions correctly, thereby verifying the sufficiency of security measures.

Functional testing and penetration testing, among others, can also be used to verify the sufficiency of cybersecurity measures for UN R155 approval. According to the regulation, OEMs not only have to disclose the results of these tests but also keep testing procedures up to date.

Who is responsible for fuzzing?

Even though vehicle manufacturers are responsible for the regulatory type approval, cybersecurity regulations are aimed at the entire automotive industry. So, fuzzing does not have to be done exclusively by the vehicle manufacturer. Tier 1 suppliers and software providers are often asked to provide fuzzing results for their software as well. Moreover, third-party white hat hackers conduct fuzzing along with penetration testing on vehicles and report any newly found vulnerabilities to the manufacturers to receive a bounty. This type of third-party fuzzing is becoming a common practice in the industry, allowing for a wider pool of cybersecurity experts to participate in strengthening vehicle cybersecurity.

Types of vehicle fuzzing

In fact, members of the AUTOCRYPT Red Team have won a major OEM’s bounty for discovering several vehicle vulnerabilities after independently conducting fuzz tests. This type of independent fuzz testing is called a black box test. In other words, a black box fuzz test defines a test where testers have no knowledge of the internal structure of the software, and perform tests by using only publicly available information. Led by award-winning ethical hacker Dr. Jonghyuk Song, AUTOCRYPT Red Team is known for its innovative approaches in black box fuzzing on CAN and IP protocols.

Other types of fuzz tests include gray box and white box fuzzing. During the gray box fuzz test hackers have no knowledge of the internal structure of the software, but some non-publicly available information is shared with them in advance. Gray box testing is one of the most commonly practiced fuzz tests in the industry. White box fuzzing is the most open type, where ethical hackers have access to the complete internal structure of the software.

The difference in the amount of information in each of the fuzzing types affects how the fuzzing test will be performed.

Performing vehicle fuzzing

The first step in the vehicle fuzzing process would be to choose the testing target device. Fuzzing is aimed at testing the software operations of a specific device in a vehicle and modern-day software-defined vehicles have no shortage of devices that need to be tested for potential bugs and vulnerabilities.

The next step is test case generation, which is when the intentional software overflow happens. The fuzzer generates random invalid inputs in the target device code to detect abnormalities. The intentional software “attack” happens during the test case delivery stage.

If the test is successful and the fuzzer detects an abnormality, the tool ceases operation. This happens because software overflow induces a system crash. Detected bugs are then reported and fuzzing has to be restarted to continue testing. The crash and restart process can make vehicle fuzzing a rather time-consuming endeavor. However, more advanced fuzzing solutions can automate operations to significantly reduce testing time.

For instance, AutoCrypt Security Fuzzer records the behaviors from the fuzzing target after a successful round of testing and automatically moves back to the second stage of test case generation. The results of the preceding tests are used to generate semi-random inputs using machine learning-based algorithms, greatly reducing fuzzing time while increasing the likelihood of bug detection. On top of that, if the Security Fuzzer causes a crash, it reproduces the same series of inputs based on the delivery history. Reproducing the test case allows for the replication of the test scenario, helping developers pinpoint the problems in the software. This algorithm-based smart fuzzing process allows for more precise and time-efficient testing.

Fuzzing is unique to its counterparts in that it can help uncover vulnerabilities that were previously unknown and help protect vehicle systems from zero-day attacks. Its special ability to detect unprecedented software issues makes it essential for vulnerability testing and risk assessment for UN R155. While complex and time-consuming, a fuzz test can be viewed as a health check-up that gives you an insight into how the systems are performing when there are no apparent symptoms present. When paired with other cybersecurity measures like penetration testing, a fuzz test can generate a holistic picture of in-vehicle systems operations and cybersecurity measure robustness.

To learn more about AUTOCRYPT’s vehicle cybersecurity testing measures and cybersecurity regulation compliance consulting services, contact global@autocrypt.io.