How to Automate Security Testing via Fuzzing

Last week, I had the privilege of speaking at the FuzzCon conference hosted by software security company, ForAllSecure. The conference is designed to explore the challenges and opportunities of security testing automation via the technique known as "fuzzing". This technique is increasingly used by large software corporations, but is greatly underutilized by smaller software companies and independent software developers. I want to use this post to demistify fuzzing, as well as share some of my major takeaways from FuzzCon.

photo by ForAllSecure

What is Fuzzing and Why do we do it?

Our software systems are always attacked via the interfaces they expose. Those interfaces could be web GUIs (i.e. a browser form), web APIs, network interfaces, process interfaces for executables/ libraries on an operating system etc. This is really no different from the physical world - houses are often broken into via a door or a window.

But, it does mean that software builders bear a responsibility to do their best to fortify the interfaces they expose, against cyber attackers. Fuzzing is one way to do that.

Fuzzing is the process of using automation to supply unexpected, crafted, or bad inputs to a software interface, to verify and improve the robustness of the software when handling incorrect inputs.

Software corporations like Google, Microsoft, and Intel have used fuzzing for well over a decade to weed out security defects, that are often missed by other manual or specialized security testing techniques. Fuzzing has been used to discover security defects in major software platforms like the Unix/ Linux operating system, the Android operating system, the OpenSSL network traffic encryption library, and the popular SQLite databse. Personally, I recall using fuzzing to discover new flaws in a media processing component that had already been tested using other methods by a highly skilled team.

Why You Should Care

Any software interface can be fuzz tested. You only need these:

1. The software interface to be tested.

2. A set of known good inputs.

3. A tool or script to generate new and potentially unexpected inputs from the good inputs.

4. A tool or script to (a) automate the supply of the new input to the system under test and (b) analyze and report on how the software behaves under test.

Plus, the good news is that there are already many fuzzers in the market, including opensource and free ones, that can provide (3) and (4) above for your software system. If you aren't sure which fuzzers you can use, please contact us at team@resilientsoftwaresecurity.com or via the chat box below, and we would be glad to point you in the right direction.

Some Innovative Fuzzers

This is by no means intended as a hall of fame or complete list of fuzzers, but rather it's a list of fuzzers I've come across that are raising the bar for what's possible via fuzzing.

1. OSS-Fuzz: This opensource fuzzing framework by Google is essentially a continously running fuzzing service that allows any open source project to be continuously fuzzed free of charge. It uses advanced fuzzing engines like afl++, libfuzzer, and hong-fuzz. Each of those fuzzing engines are opensource and can be used independent of OSS-Fuzz

2. Cluster-Fuzz: An opensource distributed fuzzing infrastructure that allows anyone to perform fuzzing at scale using virtual machines. Cluster-Fuzz is used by OSS-Fuzz.

3. Mayhem for Code and Mayhem for API: These products from ForAllSecure bring fuzzing into the fast-paced continuous integration (CI) and continuous development (CD) software development paradigm, enabling companies to automate software testing on the go.

Related Videos

These videos give a practical description of the concepts shared in this video.

1. Automating Software Quality and Security Testing.

2. What is Negative Testing?

3. Know your attack points.

Bonus - Highlights from FuzzCon 2021

• There are about 28 million software developers in the world!

• Software is inherently complex. It has been described as a multi-variate, multi-dimensional, multi-disciplinary problem.

• The average car has millions of lines of software code. Even the firefox browser has 21 million lines of code!

  • It's practically impossible to review all of that code manually to verify that it is secure code.

• Many of the world's software developers are either independent developers, or in startups and small businesses. They cannot afford to spend $200 - $300 USD/hr to hire skilled penetration testers to validate software security.

• Fuzzing is one of the tools in the software security validation tool belt that enables any software developer to test and improve the robustness of their software when handling incorrect inputs.

• Some of the limitation of many fuzzers today include: inability to fit into the CI/CD flow, the time required for a complete run, the expertise required to analyze results, and platform or operating system incompatibility.

• Some of the opportunities for fuzzing to better meet industry needs include: fuzzing services that centralize fuzzing infrastructure for entire companies or departments; fuzzers that can fit seamlessly into the CI/CD flow and share intelligible information with developers at code commit or post-build; fuzzers that can run directly inside the IDE where developers spend most of their time.

• To get your company to buy into purchasing or deploying fuzzing tools, security leaders must be ready to demonstrate business value.