Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Problem in rule LFI/RFI 931130 with multiple args

See original GitHub issue

_Issue originally created by user fzipi on date 2017-09-13 19:10:42. Link to original issue: https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/882._

In rule 931130 (950120 in 2.2.x) we detected a strange behavior.

It only fires when the argument containing the %{request_headers.host} is the last one. this was somewhat unexpected, and I don’t think its the rule purpose.

We expected that no matter which argument contains the RFI, it will be blocked.

TEST CASE 1 - arg1=localhost, arg2=localhost - Expected: 200 OK 

Testing 950120

TEST CASE 2 - arg1=localhost, arg2=remote.com - Expected: 403 Forbidden
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /index.html
on this server.</p>
</body></html>

TEST CASE 3 - arg1=remote.com, arg2=localhost - Expected: 403 Forbidden

Testing 950120

This is a simple script for testing:

#!/bin/bash

HOST1=localhost
HOST2=remote.com

echo -e "TEST CASE 1 - arg1=$HOST1, arg2=$HOST1 - Expected: 200 OK \n"
curl -4 "https://$HOST1/index.html?arg1=http://$HOST1/index.php&arg2=http://$HOST1/index.php"

echo "TEST CASE 2 - arg1=$HOST1, arg2=$HOST2 - Expected: 403 Forbidden"
curl -4 "https://$HOST1/index.html?arg1=http://$HOST1/index.php&arg2=http://$HOST2/index.php"

echo "TEST CASE 3 - arg1=$HOST2, arg2=$HOST1 - Expected: 403 Forbidden"
curl -4 "https://$HOST1/index.html?arg1=http://$HOST2/index.php&arg2=http://$HOST1/index.php"

So it is very easy to circumvent this rule: just add to your attack another variable with the corresponding host and it will pass…

Btw, there are many similar rules which are very similar to this one.

Issue Analytics

State:
Created 3 years ago
Comments:8

Top GitHub Comments

1reaction

CRS-migration-botcommented, May 13, 2020

User spartantri commented on date 2017-09-15 08:21:37:

What about leaving this rule as it is for low PL and starting on PL3 or maybe even PL4 use the variable approach, to keep it simple, the same could be accomplished with lua to overcome the modsecurity shortcomings and iterate through al items in collections such as VARS but that will be much more complicated to manage. This rule may also change to use RX that matches with macro expansion to have a single evaluation not a two step evaluation and put it at PL2 as the reference manual say there may be “impact in efficiency” whatever that may mean. Performance penalties are fine up to certain level to balance security, if you don’t then stay at quick and blind compliance level (PL1), as you go up the ladder there are more checks and more juice is required to run all those extra checks, not only handling paranoid checks as doing blocks just because a \W{4} match but really making sure every item is inspected, how may you be paranoid if you only check the last matching item in ARGS collection leaving all others untouched? (worst case scenario, that may be equivalent to sampling 10% if there are 10 arguments). The definition of the PL is another thing to add to the CONTRIBUTING.md, like: PL0:

Modsec installed, but almost no rules
Compliance check box ok but no flowers PL1:
Compliance check box ok with flowers
Atomic checks in single rule
Confirmed matches only, all scores are allowed
No false positives / Low FP
False negatives are ok
Your AWS free tier VM will run this for 100’s sites
Easy log management, grep is your friend PL2:
Compliance check box ok you are getting in security side
Chains usage is OK
Confirmed matches use score critical
Matches that cause false positives are limited to use score notice or warning
Low False positive rates
False negatives are not desirable
Your AWS free tier VM will run this for 100 sites
Easy log management, grep is your friend, turn yourself into regex/greping pro PL3:
Compliance check box ok you are well into security, check before shooting
Chains usage with complex regex look arounds and macro expansions
Confirmed matches use score warning or critical
Matches that cause false positives are limited to use score notice
False positive rates increased but limited to multiple matches (not single string)
False negatives are evil
Your AWS free tier VM will run this for 10’s sites
Using LB is recommended
Not easy to hard log management, turn yourself into regex/greping ninja and get a SIEM PL4:
Compliance check box ok you bread security and you shoot whatever thing moves, shoot fist ask later
Every item is inspected
Variable creations allowed to avoid engine limitations
Confirmed matches use score notice, warning or critical
Matches that cause false positives are limited to use score notice and warning
False positive rates increased (even on single string)
False negatives are a kick in the …
Check everything against RFC and white listed values for most popular elements
Your AWS free tier VM will run this for a site
You better use a LB
Beg you are using ELK to manage your logs and have your ninja sword always sharp and have spare swords available at all times
Red pill or blue pill?

This could help getting better criteria to align what goes into which PL level.

PL5:

Damn, why you took the red one?!
go beyond modsec capabilities
go Where No Man Has Gone Before
Your WAF accepts only a single string with 1 letter in it hahahaha

1reaction

CRS-migration-botcommented, May 13, 2020

User spartantri commented on date 2017-09-13 22:28:26:

Actually, the rule and the ^(?i)(?:file|ftps?|https?)😕/(.*)$ regex have several bypasses %20http://whatever.com http://localhostwhatever.com HPP which is detected by other rule

This has a quick fix but I’m just starting with git and really suck at handling the PR and all that stuff, just change lines 136 and 137 to:

-    tag:'paranoia-level/2'"
+    tag:'paranoia-level/2'\
-    SecRule TX:1 "!**beginsWith** %{request_headers.host}" \
+    setvar:tx.rfi_parameter_%{matched_var_name}=%{tx.1}"
+    SecRule TX:/rfi_parameter_.*/ "!**beginsWith** %{request_headers.host}"

Top Results From Across the Web

Controversial candidate 950120 / 931130 (Possible RFI)

- I have multiple whitelistings for this rule on ARGS:url. If I was non-paranoid, I would assume that IF a web application accepts...

Application Gateway v2 WAF - RFI exclusions not working

Hi everyone, We are experiencing some problems in adding exclusions to rule 931130 RFI Attack: Off-Domain Reference

Remote file inclusion (RFI) - Imperva

RFI is a common attack that remotely uploads malicious scripts to an application's server and can result in information theft, site takeover and...

Core Rule Set Inventory – Welcome to netnea

Rule ID Paranoia Level Severity 901001 PL1 none 901450 PL1 none 905100 PL1 none

Supported Protection Rules - Oracle Help Center

Rule ID/Key Name Description 90002 United States Social Security Number Leakage Detects leakage of US SSN in... 90008 Credit card leakage in request: Visa Detects...