arrows arrow-right arrow-left menu search rss youtube linkedin twitter facebook arrow-play

Interpreting Fuzz Testing Results for a Device Vulnerability Assessment

Challenge

The manufacturer of a Class 2 medical device came to us for help in assessing cybersecurity vulnerabilities. The product, known as a programmer, is used to remotely reprogram implantable devices. Sending software updates to implantable devices via a wireless connection makes the devices much more convenient for users, but also opens up potential vulnerability to hackers.

Fuzz testing is commonly used as a first step in assessing the vulnerability of a device to malicious hacking or unintended effects caused by bad data. Accepting and using data from outside sources is a significant source of risk common to all connected devices. Fuzz testing allows manufacturers to verify that the system is properly checking and sanitizing data coming from outside sources prior to using it. Testers send massive amounts of malformed data at the device to see how it responds. The same technique is often used as a first step by hackers looking for easily exploitable vulnerabilities in devices. By conducting their own fuzz testing proactively, companies can identify and resolve security vulnerabilities that may be considered “low hanging fruit” by potential hackers and also reduce the risk of crashes caused by bad data.  

While “fuzzers” can be easily purchased to throw data at a device, gathering, analyzing and interpreting the results of the fuzz test is harder. The company came to Battelle for help in designing and executing a fuzz test protocol and interpreting the results in way that made them understandable and actionable.

Solution

To find all of the ways the device may be vulnerable to mutated data, security researchers conducted fuzz testing at multiple levels (e.g. application layers, operating system, Bluetooth, Wi-Fi, Ethernet and USB interfaces). They also tested the device within the software ecosystem in which it operates to see if vulnerabilities in the parts of the code that the company did not write—such as the embedded operating system—would cause problems for the device. Overall, Battelle researchers conducted more than 600,000 test cases.

In order to accurately determine how the device responded to different data attacks, researcher built a crash detector unique to the device that would monitor its working state, keep a log of its responses during the test, and reset the device back to its optimal state after a crash so fuzz testing could continue uninterrupted. Analyzing the logs created in this way allowed researchers to conduct an interpretational analysis of the test results and determine which vulnerabilities were potentially exploitable.

Outcome

The analysis determined that the device did not have major vulnerabilities to malformed data attacks, giving the company greater confidence in the security of the device. We were able to develop a report listing potential vulnerabilities and identify the top 10 issues that may require mitigation. This concrete, actionable information allowed them to make informed decisions to improve the security of their device and identify potential issues that could impact other devices sharing the same operating system or components.