Hack The Box: (Sekhmet) ModSecurity Demonstration

In this post, I would like to share a weakness of ModSecurity that has been used within the Sekhmet Machine. The full writeup on the Sekhmet machine can be found here

What is ModSecurity?

For those who are not familiar with ModSecurity(ModSec), it’s an open-source Web Application Firewall (WAF) that has been implemented on the server to protect the sites and applications.

The main function of the ModSecc is to work against the most common attacks such as Cross-Site Scripting (XSS), code injection, Brute-Force attack, SQL Injection, etc.

Normally, ModSecurity supports the modules included in Apache Web Server, Nginx, and IIS

The function of ModSec

The purpose of ModSecurity will protect the web application by employing some methods such as below:

1. Real-time monitoring of the web application: It will mostly focus on threat mitigation on external by implementing whitelisting and blacklisting including the blocking
2. Traffic Logging on HTTP: The ModSec will be saved detailed logs on all traffic either incoming or outgoing for investigations purpose if something happens.

Demonstration on the ModSec

# -- Rule engine initialization ----------------------------------------------

# Enable ModSecurity, attaching it to every transaction. Use detection
# only to start with, because that minimises the chances of post-installation
# disruption.
SecRuleEngine On

Firstly, we should be accessing the machine as root@webster and reading the configuration that is stored in /etc/ngnix/modsec/modsecurity.conf

We need to trigger the alert as shown above by tampering with the cookie for the profile

root@webserver:/var/log/nginx# cat error.log
2023/04/03 00:22:18 [notice] 363#363: ModSecurity-nginx v1.0.2 (rules loaded inline/local/remote: 0/906/0)
2023/04/03 00:22:18 [notice] 376#376: ModSecurity-nginx v1.0.2 (rules loaded inline/local/remote: 0/906/0)
2023/04/03 04:49:02 [error] 378#378: *43 [client 192.168.0.2] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `5' ) [file "/etc/nginx/modsec/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "80"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver "OWASP_CRS/3.2.0"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "192.168.0.100"] [uri "/<script>alert(1)</script>"] [unique_id "1680490142"] [ref ""], client: 192.168.0.2, server: portal.windcorp.htb, request: "GET /%3Cscript%3Ealert(1)%3C/script%3E HTTP/1.1", host: "portal.windcorp.htb"

As a result, we can look into the error.log to clarify that ModSecurity has done its part of security.

SecRuleEngine DetectionOnly

The code that i show (SecRuleEngine DetectionOnly) above needs to add to the configuration file. The main purpose is the block error will not appear on the browser but it will save within the log.