Module-2 | Introduction -Pentesting & Bypassing AWS/Azure/GCP Cloud WAF Fun & Profit

Published in

InfoSec Write-ups

7 min readMay 25, 2022

Q. What is Core Rule Set & why it is utilized by all the cloud WAFs?
A. We will try to understand more about the core rule set along with its working and will try to implement the mod security on the apache server and learn why it is utilized by major WAFs.

Introduction

Before starting with the setup of WAF over the cloud we need to understand the Core Rule Set which we will be enabled in the cloud WAFs. Since CRS is open source I reported to security@coreruleset.org and a few things from the report were rejected and the rest accepted which are mentioned below in the blog.

Later I will be showing the security flaws which were not accepted and why I consider them as valid reasons and also I will set up the cloud WAF and bypass the CRS rules.

Objective

Definition of ModSecurity & OWASP ModSecurity Core Rule Set.
Working of Core Rule Set.
Why use OWASP CRS.
Implementation of CRS on Apache.
CRS configuration and paranoid levels?
CRS & Cloud WAF
Summary

Description

ModSecurity: It is an open-source, cross-platform web application firewall (WAF) engine for Apache, IIS and Nginx. Every engine requires a set of rules and regulations to perform actions.
OWASP CRS: OWASP Core Rule Set is a set of generic attack detection rules for use with ModSecurity or compatible Web Application Firewall (WAF). Any compatible WAF can use CRS rules hence all the cloud providers use these generic rule set to provide WAF on the cloud.
The CRS protects web applications from a wide range of security risks with a minimum of false positives when it is fine-tuned properly.

Why use OWASP CRS?

These rules are generic in nature and any compatible WAF engine can use CRS hence all the major cloud providers like Amazon AWS, Microsoft Azure, Google Cloud, Akamai, etc. all have a CRS offering of some sort.

Hence we need to understand the working of CRS before enabling it for production applications.

1. Implementation of CRS

1.1: Install ModSecurity with Apache on Debian/Ubuntu

The ModSecurity module for Apache is included in the default Debian/Ubuntu repository. To install it, run

sudo apt install libapache2-mod-security2

Then enable this module.

sudo a2enmod security2

Restart the Apache.

sudo systemctl restart apache2

1.2: Configure ModSecurity

In the /etc/apache2/mods-enabled/security2.conf the configuration file, there is a line mentioning IncludeOptional /etc/modsecurity/*.conf, hence we need to copy IncludeOptional /etc/modsecurity/*.conf modsecurity.conf-recommendedto modsecurity.conf as mentioned below.

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Then edit this file.

sudo vim /etc/modsecurity/modsecurity.conf

Change the following line SecRuleEngine DetectionOnly to SecRuleEngine On.
ModSecurity will detect and block web attacks as we are changing the mode from detection only.

SecRuleEngine On

Then change the SecAuditLogParts and change it to ABCEFHJKZ.

SecAuditLogParts ABCEFHJKZ

Save and close. Then we will restart Apache.

sudo systemctl restart apache2

1.3: Install the OWASP Core Rule Set (CRS)

For ModSecurity to protect the web applications, we need to define rules to detect malicious activities and block them. Either we can use the existing ruleset and configuration or we can customise as required. The OWASP Core Rule Set (CRS) is the standard rule set used with ModSecurity.
Download the latest OWASP CRS from GitHub.

#wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.2.tar.gz

Extract the file.

tar xvf v3.3.2.tar.gz

Create a directory to save the CRS files.

sudo mkdir /etc/apache2/modsecurity-crs/

Move the extracted directory to /etc/apache2/modsecurity-crs/.

sudo mv coreruleset-3.3.0/ /etc/apache2/modsecurity-crs/

Change to that directory.

cd /etc/apache2/modsecurity-crs/coreruleset-3.3.2/

Rename the crs-setup.conf.example file.

sudo mv crs-setup.conf.example crs-setup.conf

We need to edit the /etc/apache2/mods-enabled/security2.conf file.

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

Change the below-mentioned line which loads the default CRS files.

IncludeOptional /usr/share/modsecurity-crs/*.load

Change it to the following, so the latest OWASP CRS will be used.

IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.2/crs-setup.conf
IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.2/rules/*.conf

Check for the syntax and then restart Apache.

sudo apache2ctl -t
sudo systemctl restart apache2

You can see that OWASP CRS can run in two modes:

Anomaly scoring mode. This is the default mode used in CRS v3.x based on the concept of ‘Collaborative Detection’ and ‘Delayed Blocking’. ModSecurity will check an HTTP request against all rules, and add a score to each matching rule. If a threshold is reached, then the HTTP request is considered an attack and will be blocked.
Self-contained mode. This is the most basic operating mode where all of the rules are “self-contained”. ModSecurity will block the HTTP request immediately and stop evaluating the remaining rules.

The default score for inbound requests is 5 and for outbound response is 4.

When running in anomaly scoring mode, there are 4 paranoia levels.

Paranoia level 1
Paranoia level 2
Paranoia level 3
Paranoia level 4

With each paranoia level increase, the CRS enables additional rules giving you a higher level of security. However, higher paranoia levels also increase the possibility of blocking some legitimate traffic due to false alarms.

For testing Christian Folini (OWASP @CoreRuleSet project co-lead) provided the config with paranoia level 4.

These are the two basic concepts you need to understand before using the CRS. Now we can close the file. The individual CRS rules are stored in /etc/apache2/modsecurity-crs/coreruleset-3.3.2/rules/ the directory. Each matching rule will increase the anomaly score.

The anomaly score will keep on increasing based on the triggered rule and it will start blocking the malicious traffic. This can be checked in the events via cloud WAF logs.

Note: There won’t be any body of the request obviously, only GET request URLs will be present in the logs. Hence it will be very tricky to reduce the false positives once the WAF has been implemented in production.
I was able to achieve zero false positive while implementing CRS, although I had to disable some rules as in cloud it is not possible to tweak the configuration. Then I created custom rules.

Paranoid Levels are basically the strictness of the rules.

For some basic rules, refer to the cloud provider’s documentation for the list of rules.

There will be high false positives on the cloud WAF as it is not possible to modify the configuration.
Hence hybrid approach (blacklisting & whitelisting) approach should be followed.

Tuning the CRS

CRS definitely protects from large amounts of malicious traffic and blocks most security scans and all the automated/script-kiddie based HTTP attacks.
The generic approach comes with false positives as WAF providers are providing custom configurations, so one cloud provider’s WAF might be different from another. Also, custom rules would be different based on rules triggered while testing the cloud WAF.
This default cloud WAF will bring lots of false positives and each WAF needs to be tested based on the application on which it is implemented.

That means ModSecurity and CRS serve as the first line of defence that buys you time and protects against compliance as well.

This is the basic of the Core Rule Set, next I will be showing setting WAF on different cloud providers and how to test the WAF. Then we will be writing custom rules based on logs.

Summary

The paranoia level setting is an important part but the most important and tricky feature is the anomaly scoring. Anomaly scoring means, that CRS does not block a request immediately. Instead, it separates the detection from the blocking decision. When a rule triggers because it has encountered a specific pattern in a request, it raises the anomaly score of the request. A separate rule that runs will then check the total anomaly score. That separate rule performs the blocking decision based on the anomaly threshold.

This will change based on clouds and this anomaly scoring will be based on how the cloud WAF is configured.

As the cloud providers use open source CRS, hence it was advised to report to the CRS team. Hence 3 things were accepted from my report which is mentioned below.

There are 3 things taken from my report: 😁

Add UA SeoScanners to the list of restricted UAs
Add UA Censys to the list of restricted UAs
Try to add /proc system to the list of restricted local files. Ideally at PL1 for the entire /proc but we need to test this.

In terms of Christian Folini himself, Modsecurity CRS is the 1st line of defence and it means that a lot of attacks and bypasses go undetected in the default installation. That is not ideal, but a reasonable compromise since the alternative for our users is often no rule set at all.

Reach out to Christian folini as he is highly responsive and helpful in case you want to test/report any issue with the CRS.
To report the security issue in the CRS reach out to security@coreruleset.org.