Lately, fuzzing is increasingly a topic of conversation in the automotive industry. With this attention, some questions arise: What is it? What can it do? And why is it important?
What is Fuzzing?
Fuzzing is the automated process of sending randomly generated inputs to a target and monitoring its reaction. The idea is to trigger bugs in an implementation by providing input data that the implementation does not anticipate or understand. Unlike a penetration test in which a pen-tester crafts malicious inputs by hand, fuzzing is an automated, less targeted process.
Figure 1- The fine line between valid and invalid input
What can it do?
Fuzzing is a powerful testing technique that can be used to check software robustness. Google’s OSS-fuzz project identified over 9,000 flaws in open source software over the course of two years [1]. Another project, AFL, also lists numerous flaws within open source software [2].
Our own fuzzing projects with several different customers have revealed many different bugs from hard crashes of safety critical ECUs over confused TCP stacks that were spontaneously changing MAC addresses.
Fuzzing, if done properly, will reduce the number of vulnerabilities in your device as well as increase the reliability. By testing the target’s reaction to randomly generated invalid or unexpected inputs, hidden bugs inside the implementation could be triggered and lead to the reveal of insecure behavior (e.g. leaking of secrets), undefined behavior (which might in the worst case interfere with safety), and crashes.
The Two Components of a Fuzzer
Every fuzzer has two main components: the generator and the monitor. The quality of these components is what distinguishes a $10k+ commercial fuzzer from a hacked-together 50 line fuzzing script.
Message Generator: The generator creates an input for the target to consume. A good generator is protocol aware, i.e., it speaks to the protocol it is fuzzing and only modifies single aspects of the protocol (e.g. single data fields or specific aspects of the message flow). That way, it is trading the fine line between invalid and valid input (See Figure 1). This is also called ‘smart fuzzing’. On the other side of the quality spectrum is a generator that simply pipes randomness to the target and hopes for the best. This approach is called ‘dumb fuzzing’.
Target Monitor: Producing and sending an input is only half the work. The monitoring component is responsible for detecting the misbehavior of the target. We will often monitor the target in various ways. For example, we commonly use camera imaging to check for any illegitimate behavior if the target has a screen, monitoring amperage draw of the target for any resets is another great way to monitor, using a common known good “ping” message that the target should always respond to, or even hooking up a debugger and monitoring the targets behavior. These misbehaviors can range from hard failures (crashes) to subtle bugs such as timing issues or memory leaks.
The overall setup can be seen in Figure 2.
Figure 2 – General Fuzzing Setup
Black and Whitebox Fuzzing
When people talk about ‘fuzzing’ they might be referring to a couple different situations:
Blackbox Fuzzing: In a pure blackbox fuzzing setting, we have no introspection into the target device. We only can send randomized input to it and monitor externally visible reactions (responses, crashes, power fluctuations, etc.).
Whitebox Fuzzing: In a whitebox fuzzing scenario, the monitoring aspect is much more powerful but also more complex. It allows for the inspection of binaries running on the target device, the installation of monitoring services, and even the recompilation of the targeted software to detect subtle flaws. In contrast to blackbox fuzzing which is usually set up in the lab, whitebox fuzzing requires integration into the development processes of the customer.
Why is Fuzzing important?
Fuzz Testing can find many different bugs and vulnerabilities, making it an extremely effective tool to get ahead of malicious hackers. One of the most notorious bugs found using fuzzing was called the Heartbleed bug. This bug was a serious vulnerability in the popular OpenSSL cryptographic software library. This bug allowed anyone with internet access to read the memory of the systems protected by the unpatched versions of the OpenSSL software [3]. The attacks also leave no trace, so it is uncertain how long this bug would have remained active if the Fuzz testers didn’t find and report it.
An example of an automotive “bug” found with fuzzing is from our testing team. They were targeting an embedded ECU’s CAN protocol, when some messages that were sent caused a complete crash of the ECU. Our team informed the developer and bug was patched.
What ESCRYPT is doing
We are currently focused on protocol aware blackbox fuzzing of different embedded protocols. To achieve this goal, we are using a mix of commercial, free, and an in-house developed fuzzer. The set of protocols we can cover this way includes CAN, ISO-TP, UDS, USB, Bluetooth, WiFi, and many Ethernet-based protocols (IP, TCP, UDP, FTP, TLS, …). If you can name it, chances are good that we can fuzz it.
Besides blackbox fuzzing, we are currently also piloting whitebox fuzzing projects to evaluate the integration of fuzz testing into different development environments. In addition, we also have developed our own fuzz tool that targets USB and CAN protocols.
If you are interested in fuzzing or security testing in general, feel free to contact us or comment below.
All the best,
Lena Jokanovich Douglas Gordon John McShane
ESCRYPT Fuzzing Experts
References
[1] https://www.zdnet.com/article/googles-automated-fuzz-bot-has-found-over-9000-bugs-in-the-past-two-years/
[2] http://lcamtuf.coredump.cx/afl/
[3] http://heartbleed.com/