We're using modsecurity to protect a very poorly written web app. Running Cenzic scans against the app, modsecurity is stamping out most of the problems we found, except one - LDAP injection.
There's only one LDAP injection rule in generic-attacks.conf.
SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/ "(?:((?:\W?(?:objectc(?:ategory|lass)|homedirectory|[gu]idnumber|cn)\b\W?=|[^\w\x80-\xFF]?[!\&\|][^\w\x80-\xFF]?()|)[^\w\x80-\xFF]?([^\w\x80-\xFF]*?[!\&\|])" \
"phase:2,rev:'2',ver:'OWASP_CRS/2.2.6',maturity:'9',accuracy:'9',capture,t:none,t:htmlEntityDecode,t:lowercase,ctl:auditLogParts=+E,block,msg:'LDAP Injection Attack',id:'950010',tag:'OWASP_CRS/WEB_ATTACK/LDAP_INJECTION',tag:'WASCTC/WASC-29',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/LDAP_INJECTION-%{matched_var_name}=%{tx.0},skipAfter:END_LDAP_INJECTION"
SecMarker END_LDAP_INJECTION
That rule is triggering during the attacks, but the attacks are still succeeding.
Here's a log entry (I've obfuscated some info to protect the guilty) for a successful block:
I assume the rule isn't triggering because objectClass is buried in the form submission rather than the uri? Is there a way to address this in the existing rule? Or does this require an entirely new rule? My knowledge of rule writing in modsecurity is rudimentary at best, so any help would be appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For those reading here, Ryan suggested I add t:urlDecodeUni to the rule, which I did. On retesting, the number of successful attacks dropped from 137 to 1!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We're using modsecurity to protect a very poorly written web app. Running Cenzic scans against the app, modsecurity is stamping out most of the problems we found, except one - LDAP injection.
There's only one LDAP injection rule in generic-attacks.conf.
SecMarker END_LDAP_INJECTION
That rule is triggering during the attacks, but the attacks are still succeeding.
Here's a log entry (I've obfuscated some info to protect the guilty) for a successful block:
--5732963d-F--
HTTP/1.1 403 Forbidden
Content-Length: 240
Connection: close
Content-Type: text/html; charset=iso-8859-1
--5732963d-E--
--5732963d-H--
Message: Access denied with code 403 (phase 2). [file "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_40_generic_attacks.conf"] [line "53"] [id "950010"] [rev "2"] [msg "LDAP Injection Attack"] [data "Matched Data: (objectclass= found within ARGS:user: testuser)(objectclass=*"] [severity "CRITICAL"] [ver "OWASP_CRS/2.2.6"] [maturity "9"] [accuracy "9"] [tag "OWASP_CRS/WEB_ATTACK/LDAP_INJECTION"] [tag "WASCTC/WASC-29"] [tag "OWASP_TOP_10/A1"] [tag "PCI/6.5.2
"]
Action: Intercepted (phase 2)
Apache-Handler: perl-script
Stopwatch: 1378831514343872 668 (- - -)
Stopwatch2: 1378831514343872 668; combined=328, p1=114, p2=198, p3=0, p4=0, p5=16, sr=28, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/); OWASP_CRS/2.2.6.
Server: Apache
Engine-Mode: "ENABLED"
--5732963d-Z--
Here's a Cenzic attack that succeeded (again, obfuscated some of it)
HTTP Request
I assume the rule isn't triggering because objectClass is buried in the form submission rather than the uri? Is there a way to address this in the existing rule? Or does this require an entirely new rule? My knowledge of rule writing in modsecurity is rudimentary at best, so any help would be appreciated.
Paul - this is related to the OWASP ModSecurity CRS. Please open a GitHub Issues ticket here -
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues
Will do.
For those reading here, Ryan suggested I add t:urlDecodeUni to the rule, which I did. On retesting, the number of successful attacks dropped from 137 to 1!