Quick WAF "paranoid" Doctor Evaluation

WAFPARAN01D3

The Web Application Firewall Paranoia Level Test Tool.
— From alt3kx.github.io

Introduction to Paranoia Levels

In essence, the Paranoia Level (PL) allows you to define how aggressive the Core Rule Set is.
Reference: https://coreruleset.org/20211028/working-with-paranoia-levels/

How it works

• The wafparan01d3.py python3 script takes malicious requests using encoded payloads placed in different parts of HTTP requests based on GET parameters, The results of the evaluation are recorded in the report debug file wafparan01d3.log created on your machine.
• Observe the behavior and response for each WAF paranoia level setting different attacks or payloads by using the default config level.
• The PoC below provide de basic installation and configuration from scratch and re-use byself the current WAF deployed by settting a basic "Mock" and simulate the backend.
• The default payloads avaiable was called mysql_gosecure.txt based on the research "A Scientific Notation Bug in MySQL left AWS WAF Clients Vulnerable to SQL Injection" from gosecure available here https://www.gosecure.net/blog/2021/10/19/a-scientific-notation-bug-in-mysql-left-aws-waf-clients-vulnerable-to-sql-injection/ evaluating our WAFs using modsecurity in their different levels of paranoia either in a default configuration or by disabling different rules / IDs in a staggered and quick way.

Approach

• Pentesters: GreyBox scope with limited access to WAF Linux box using a "shell" with privileges to start/reload and edit WAF Apache config files on DEV/STG/TEST enviroments sending diferent payloads.
  
• Secutity Officers: Take the best decision to apply the level of WAF paranoia for each solution in your organization.
  
• Blueteamers: Rule enforcement, best alerting , less false positive results in your organization.
  
• Integrators: Perform a depper troubheshooting and define the adequate level of WAF paranoia quickly customizing rules or creating virtual patches.
  

Proof of Concept: Based on Ubuntu 20.04.3 and OWASP Core Rule Set (CRS) v3.3.2

Reference: https://www.inmotionhosting.com/support/server/apache/install-modsecurity-apache-module/

Initial installation

1. Update software repos:
   

$ sudo apt update -y && sudo apt dist-upgrade -y

2. Install Essentials:
   

$ sudo apt-get install build-essential -y

3. Install apache2 for ubuntu (if it is not installed):
   

$ sudo apt-get install apache2 -y

4. Download and install the ModSecurity Apache module:
   

$ sudo apt install libapache2-mod-security2 -y

5. Install curl for ubuntu (if it is not installed):
   

$ sudo apt-get install curl vim gridsite-clients net-tools -y

6. Restart the Apache service:
   

$ sudo systemctl restart apache2

7. Ensure the installed software version is at least 2.9.x:
   

$ sudo apt-cache show libapache2-mod-security2

Configure ModSecurity

1. Copy and rename the file:
   

$ sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Next, change the ModSecurity detection mode. First, move into the cd /etc/modsecurity folder
2. Edit the ModSecurity configuration file with vi, vim, emacs, or nano.

$ sudo vim /etc/modsecurity/modsecurity.conf

3. Near the top of the file, you’ll see SecRuleEngine DetectionOnly. Change DetectionOnly to On.
   

Original value: SecRuleEngine DetectionOnly
New value: SecRuleEngine On

4. Save changes.
   
5. Restart Apache:
   

$ sudo systemctl restart apache2

Download OWASP Core Rule Set

1. Download the latest CRS from CoreRuleSet.org/installation
   

$ cd ~
$ wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.2.zip

2. Verify the checksum, be sure match of public available here: https://coreruleset.org/installation/
   

$ sha1sum v3.3.2.zip && echo ProvidedChecksum
88f336ba32a89922cade11a4b8e986f2e46a97cf  v3.3.2.zip
ProvidedChecksum 

3. Uncompress the zip file.
   

$ unzip v3.3.2.zip

4. Move the CRS setup file from the new directory into your ModSecurity directory:
   

$ sudo mv coreruleset-3.3.2/crs-setup.conf.example /etc/modsecurity/crs/crs-setup.conf

• (Optional but recommended) Move the rules directory from the new directory to your ModSecurity directory:
  

$ sudo mv coreruleset-3.3.2/rules/ /etc/modsecurity/crs/

5. Edit your Apache security2.conf file to ensure it’ll load ModSecurity rules:
   

$ sudo vim /etc/apache2/mods-enabled/security2.conf

<IfModule security2_module>
        # Default Debian dir for modsecurity's persistent data
        SecDataDir /var/cache/modsecurity

        # Include all the *.conf files in /etc/modsecurity.
        # Keeping your local configuration in that directory
        # will allow for an easy upgrade of THIS file and
        # make your life easier
        IncludeOptional /etc/modsecurity/crs-setup.conf
        IncludeOptional /etc/modsecurity/rules/*.conf

        # Include OWASP ModSecurity CRS rules if installed
        #IncludeOptional /usr/share/modsecurity-crs/*.load
</IfModule>

6. Ensure both the default ModSecurity and new CRS configuration files are listed. The first line conf file path may already be included. The second file path should be wherever you moved the /rules directory.
   
7. Edit /etc/apache2/apache2.conf
   

$ sudo vim /etc/apache2/apache2.conf

Copy & Paste the following code and save it.

# Include list of ports to listen on
Include ports.conf

Include /etc/modsecurity/modsecurity.conf
Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/rules/*.conf