[Owasp-modsecurity-core-rule-set] Paranoia Mode: Controversial candidate 970901 / 950100 (Application returning 500)

Christian Folini christian.folini at netnea.com
Tue Feb 2 08:44:57 UTC 2016


Hi!

This is a juicy one.

Rule in 2.2.9:
SecRule RESPONSE_STATUS "^5\d{2}$" "phase:4,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',t:none,capture,ctl:auditLogParts=+E,block,msg:'The application is not available',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',id:'970901',tag:'WASCTC/WASC-13',tag:'OWASP_TOP_10/A6',tag:'PCI/6.5.6',severity:'3',setvar:'tx.msg=%{rule.msg}',setvar:tx.outbound_anomaly_score=+%{tx.error_anomaly_score},setvar:tx.anomaly_score=+%{tx.error_anomaly_score},setvar:tx.%{rule.id}-AVAILABILITY/APP_NOT_AVAIL-%{matched_var_name}=%{tx.0}"

Rule in 3.0.0rc1:
SecRule RESPONSE_STATUS "^5\d{2}$" \
	"phase:response,\
	rev:'3',\
	ver:'OWASP_CRS/3.0.0',\
	maturity:'9',\
	accuracy:'9',\
	t:none,\
	capture,\
	ctl:auditLogParts=+E,\
	block,\
	msg:'The Application Returned a 500-Level Status Code',\
	logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
	id:'950100',\
	tag:'application-multi',\
	tag:'language-multi',\
	tag:'platform-multi',\
	tag:'attack-information disclosure',\
	tag:'WASCTC/WASC-13',\
	tag:'OWASP_TOP_10/A6',\
	tag:'PCI/6.5.6',\
	severity:'ERROR',\
	setvar:'tx.msg=%{rule.msg}',\
	setvar:tx.outbound_anomaly_score=+%{tx.error_anomaly_score},\
	setvar:tx.anomaly_score=+%{tx.error_anomaly_score},\
	setvar:tx.%{rule.id}-AVAILABILITY/APP_NOT_AVAIL-%{matched_var_name}=%{tx.0}"

Obviously we check the HTTP response status code and trigger an alert on 
a status 500. It is one of the rare rules with anomaly score error (=4)
as opposed to critical (=5).

Franziska thinks this is too generic and cloaks backend misbehaviour.
(If you have a problem with the error page, then replace it!), but let's
not hide the fact of the error from the client.

Now Walter thinks this rule plays a role when defending against blind
attacks where the difference between 403 (likely blocked by ModSecurity) 
and 500 (passed ModSecurity, but crashed on backend) gives an attacker
important information.

Initially, I wanted to push this rule into paranoia mode. But now I am
not so sure anymore for Walter does have a point.

However, the inexperienced administrator could have a hard time
indentifying the 403 status as a backend failure. So maybe it is still
a paranoia candidate despite it's supportive role when defending against
blind injection attacks.

More brain cycles are definitely needed here!

Christian


-- 
mailto:christian.folini at netnea.com
http://www.christian-folini.ch
twitter: @ChrFolini


More information about the Owasp-modsecurity-core-rule-set mailing list