Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

ModSecurity version 3: Fuzzing as part of the QA

The stability of any given project is often tracked by its maturity, which is generally measured by how old the code is. Even though this may be true a lot of the time, here at Trustwave SpiderLabs we wanted to test and assure ModSecurity v3's stability, despite its youthfulness.

We aim to achieve this level of stability by testing the code extensively: Regression tests, Unit tests, and Fuzzer test. In this case, we are using Fuzzer as an instrument to understand how resilient ModSecurity v3 is while receiving a broad variety of inputs.

We have decided to individually test each operator and transformation. In fact, we wanted to not only create a simple test, but a solid testing foundation to be further extended by the community.

In addition to the operators and transformation tests, we are developing a third category of tests focusing on the rules parser, which we will cover in a future blog post. Before jumping in to the explanation of the tests themselves, let's first discuss the American Fuzzy Lop (AFL).

The American Fuzzy Lop

One of the most popular implementations of Fuzzer, is the American Fuzzy Lop or AFL. AFL uses genetic algorithms to increase the code coverage. It maintains a very good reputation and is noted as helping the detection of bugs in significant open source software, such as OpenSSL, Firefox, BIND, and Qt. The full list is available here: AFL's bug-o-rama trophy case.

As a first step to test ModSecurity with AFL you will need to compile the project using clang. Depending on the target software this may be an issue, due to the fact that clang is sometimes pickier than the popular option, gcc. You will also need to add the option --enable-afl-fuzz during the configuration portion of compilation. The Image 1. Illustrates the configuration summary while the option --enable-afl-fuzz was supplied.

11642_c37f169b-670a-4615-b31e-5365de319f77Image 1. Summary of ModSecurity version 3 configuration options. (a) Indicates that the afl fuzzer project will be compiled.

After compilation with clang, it is necessary to have the gateway for the AFL. This gateway is a simple implementation where we tell AFL which methods from ModSecurity to call for testing. Within ModSecurity v3 our gateway drives the test towards our operators and transformations and they are available to any user by compiling ModSecurity with a fuzzer implementation.

By having the AFL support integrated on our build system, we hope to have ModSecurity widely tested. We also hope that the ModSecurity community will contribute to improve this fuzzer implementation even more.

The fuzzer implementation of ModSecurity is available under the directory test/ and it is part of the official ModSecurity repository. In order to run the fuzzer, just execute the following from the test/fuzzer directory:

AFL_SKIP_CPUFREQ=1 afl-fuzz -m none -i testcases/ -o syncdir/ -M fuzzer2 -- ./afl_fuzzer

You should see a screen like the one in the Image 2.


Image 2. Screenshot of an afl session.

Now that we had a brief explanation on AFL and how it is integrated with ModSecurity, let's take a look at how the operators and the transformations are being tested. If you want to learn more about AFL please refer their website at:

Testing the operators

ModSecurity v3 has a pluggable architecture. The level of interdependency from the core to the operators is very minimal. This is ease the implementation of new operators without demanding deep understanding of ModSecurity code. The same philosophy goes for transformations.

Another benefit of this modular architecture is the fact that we can execute an operator without even touching the ModSecurity's core. This is exactly what we want in terms of testing the operators. Looking at an operator structure, like the one illustrated in Image 3, you can see that we have two main variables: the parameter and the input. Those are, of course, related to the way that the rules are written. In Image 4 you can see an example of a rule using the operator @streq.

11570_bfabb841-ae0b-4c61-bc42-dd43f9419789Image 3. Operator skeleton. (a) Input string coming from the request. (b) m_param is informed while loading the rules.


Image 4. Operator usage in the SecLang. (a) ModSecurity variable: variable to be replaced with the argument test from the request. (b) String to be compared with (a). (c) Lowercase transformation to be applied in (b) before the comparison with (a).

Notice that on Image 4 (a) came from the rules while (b) is something that came from the request (in the format of a ModSecurity variable). In this scenario we basically have two different parameters to fuzz: (a) and (b).

All the ModSecurity operators have the exact same methods to receive parameters. The init function is used to load the parameter while the evaluate function is the one responsible to call the operator and to inform the input.

In Image 5 we have an example of our fuzzer implementation calling the operator @streq. The very same test is performed with all the operators that we currently support.

7829_0a558f70-5f31-49ac-8e37-bfd6a5d355a2Image 5. Code snippet from our fuzzer implementation. (a) Operator instance. (b) Operator evaluation method.

Testing the transformations

Similar to the operators, the transformations can also be executed without touching ModSecurity core. The major difference between the transformations and the operators is the fact that transformations only expect a single input.

Image 6 contains the skeleton of a transformation. All the transformations use the same method signature. Currently we are testing all the supported transformations.

7939_0fa172d6-55ba-47fb-b8ba-cbd13abac6bbImage 6. The skeleton of a transformation. (a) Value to be transformed. (b) Reference to the transaction (context).

What next

As mentioned earlier, a fuzzer for the parser is currently under development. The parser is a little bit more complex as it may demand the input to be somewhat structured. Another important component to be tested is the API itself. Currently we are testing individual parts of ModSecurity: operators and transformations. Having test cases to support ModSecurity entirely will be very welcomed.

Latest SpiderLabs Blogs

Hunting For Integer Overflows In Web Servers

Allow me to set the scene and start proceedings off with a definition of an integer overflow, according to Wikipedia:

Read More

Welcome to Adventures in Cybersecurity: The Defender Series

I’m happy to say I’m done chasing Microsoft certifications (AZ104/AZ500/SC100), and as a result, I’ve had the time to put some effort into a blog series that hopefully will entertain and inform you...

Read More

Trustwave SpiderLabs: Insights and Solutions to Defend Educational Institutions Against Cyber Threats

Security teams responsible for defending educational institutions at higher education and primary school levels often find themselves facing harsh lessons from threat actors who exploit the numerous...

Read More