Skip to main content

Debugging

  • Finally, the fun part. One eye is on terminal
tail -f /var/log/apache2/modsec_audit.log | grep -iE ".*notice.*|*.warning.*|.*error.*|.*critical.*"
  • The second one is testing the appĀ 
Problem 1
Message: Rule 7faba9cd8db8 [id "951250"][file "/etc/crs4/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf"][line "365"] - Execution error - PCRE limits exceeded (-47): (null).
  • Cant suggest anything better than trial and error. I'd suggest the following numbers
nano -w /etc/modsecurity/modsecurity.conf
# PCRE Tuning
# We want to avoid a potential RegEx DoS condition
#
SecPcreMatchLimit 500000
SecPcreMatchLimitRecursion 250000
Problem 2
Message: Warning. Match of "within %{tx.allowed_request_content_type}" against "TX:content_type" required. [file "/etc/crs4/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "1012"] [id "920420"] [msg "Request content type is not allowed by policy"] [data "|multipart/form-data|"] [severity "CRITICAL"] [ver "OWASP_CRS/4.10.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/255/153"] [tag "PCI/12.1"]
  • Looks like we are missing Content Type = multipart/form-data. Fixing
nano -w /etc/crs4/crs-setup.conf
SecAction \
    "id:900220,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:'tx.allowed_request_content_type=|application/x-www-form-urlencoded| |multipart/form-data| |text/html|'"
Problem 3 - Fundamental
Message: Warning. Found 24 byte(s) in ARGS:name outside range: 32-36,38-126. [file "/etc/crs4/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "1611"] [id "920272"] [msg "Invalid character in request (outside of printable chars below ascii 127)"]

e.g.
ARGS:name: \xd0\x9e\xd1\x82\xd0\xbb\xd0\xb0\xd0\xb4\xd0\xba\xd0\xb0
  • This website (as well as the article) was originally written in Cyrillic encoding and OWASP CRS cannot understand any of it. This results in content being picked up by a variety of rules at the moment the content gets published.
  • So what do we do ? - For now, a simple bypass (I'll explain a better solution a little later on) Think of this example as of a bypass example :)
cd /etc/crs4/rules/

mv REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
mv RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf

nano -w REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
SecRule ARGS:name "@rx (.*)" \
        "id:001001001,\
        phase:1,\
        pass,\
        nolog,\
        msg:'Charset Check Bypass - Cyrilic encoding is not supported',\
        ctl:ruleRemoveById=920272"
Problem 4
Message: Warning. Matched phrase "var/log" at ARGS:html. [file "/etc/crs4/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"] [line "116"] [id "930120"] [msg "OS File Access Attempt"] [data "Matched Data: var/log found within ARGS:html: ***** tail -f /var/log/apache2/modsec_audit.log
  • Here it doesn't like the page content (same story) What do we do ? Change the signature, write a bypass or avoid using the words it doesnt like (like bash, exec etc etc). The first one will work until the first update, the third is not really an option. So writing a bypass
SecRule ARGS:html "@rx (.*)" \
        "id:001001002,\
        phase:1,\
        pass,\
        nolog,\
        msg:'Matched pattern bypass',\
        ctl:ruleRemoveById=930120"
Problem 5 - Resulting from the above 2
  • Here we are facing lots of false positives for two reasons - specific content involving shell commands and an unsupported encoding. So what do we do ? At a first glance, either lower a PL or keep writing bypasses BUT there is a better option !
  • 99% of those false positives are getting picked up during the content publishing which allows to use HTTP REQUEST_METHOD and write up a global bypass for a trusted IP or Zone. Lets begin
  • (a few lines on how to parse out the logs)
echo > /var/log/apache2/modsec_audit.log

cat /var/log/apache2/modsec_audit.log | grep -iE ".*notice.*|*.warning.*|.*error.*|.*critical.*" | perl -ne 'm/.*(ARGS:\w+)/ && print "$1\n"' | sort | uniq >> /var/tmp/args.txt

cat /var/log/apache2/modsec_audit.log | grep -iE ".*notice.*|*.warning.*|.*error.*|.*critical.*" | perl -ne 'm/ARGS:html.*(id "\d+")/ && print "$1\n"' | sort | uniq >> /var/tmp/args_html.txt

cat /var/tmp/args_html.txt | sed 's/id \"/ctl:ruleRemoveById=/g' | sed 's/\"/\,\\/g' >> /var/tmp/html_rules.txt
  • Rule for the admin panel (All POST and PUT requests)
SecRule REQUEST_METHOD "@rx (POST|PUT)" \
        "id:001001001,\
        phase:1,\
        pass,\
        nolog,\
        msg:'Admin Panel WAF bypass',\
        ctl:ruleEngine=Off"
  • An example of the above for the trusted IPs (recommended)
SecRule REMOTE_ADDR "@ipMatchFromFile admin_panel_whitelist.txt" \
        "id:001001001,\
        phase:1,\
        pass,\
        log,\
        msg:'Admin Panel WAF bypass - POST|PUT only',\
        ctl:ruleEngine=Off,\
        chain"

SecRule REQUEST_METHOD "@rx (POST|PUT)"
  • Once again checking the logs for false positives and lowering blocking threshold
nano -w /etc/crs4/crs-setup.conf
SecAction \
    "id:900110,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:tx.inbound_anomaly_score_threshold=5,\
    setvar:tx.outbound_anomaly_score_threshold=4"
  • Checking the logs
Action: Intercepted (phase 2)
Apache-Handler: application/x-httpd-php
Stopwatch: 1737805433007092 8481 (- - -)
Stopwatch2: 1737805433007092 8481; combined=5102, p1=911, p2=2835, p3=0, p4=0, p5=1355, sr=75, sw=1, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.9.7 (http://www.modsecurity.org/); OWASP_CRS/4.10.0.
Server: Apache
Engine-Mode: "ENABLED"
  • If you haveĀ Fail2Ban, can check there as well
fail2ban-client status apache-modsecurity
Status for the jail: apache-modsecurity
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     14
|  `- File list:        /var/log/apache2/error.log
`- Actions
   |- Currently banned: 1
   |- Total banned:     6
   `- Banned IP list:   193.41.206.98