Hi,
some days ago I changed for some hours the behavior of a proxy server in
front of an Apache httpd server so that an optional existing
"X-Forwarded-For" header are no longer removed from the incoming requests.
And expeditiously I found in that period some few alarming log entries in
the Apache access_log (written principally in "combined" log format) like
}__test|O:21:\"JDatabaseDriverMysqli\":3:{s:4:\"\\0\\0\\0a\";O:17:\"JSimplepieFactory\":0:{}s:21:\"\\0\\0\\0disconnectHandlers\";a:1:{i:0;a:2:{i:0;O:9:\"SimplePie\":5:{s:8:\"sanitize\";O:20:\"JDatabaseDriverMysql\":0:{}s:5:\"cache\";b:1;s:19:\"cache_name_function\";s:6:\"assert\";s:10:\"javascript\";i:9999;s:8:\"feed_url\";s:126:\"eval(base64_decode('ZWNobyBiYXNlNjRfZGVjb2RlKCdRM2hEZUdwSFFrRnViMjVRYkhWelIzUjBWa2hrUlE9PScpOw=='));JFactory::getConfig();exit\";}i:1;s:4:\"init\";}}s:13:\"\\0\\0\\0connection\";i:1;}\xc3\xb0\xc3\xbd\xc3\xbd\xc3\xbd,
151.8.xxx.yyy - - [18/Aug/2016:18:18:32 +0200] "GET /index.php/ HTTP/1.1" 500 - "-" "}__test|O:21:\"JDatabaseDriverMysqli\":3:{s:4:\"\\0\\0\\0a\";O:17:\"JSimplepieFactory\":0:{}s:21:\"\\0\\0\\0disconnectHandlers\";a:1:{i:0;a:2:{i:0;O:9:\"SimplePie\":5:{s:8:\"sanitize\";O:20:\"JDatabaseDriverMysql\":0:{}s:5:\"cache\";b:1;s:19:\"cache_name_function\";s:6:\"assert\";s:10:\"javascript\";i:9999;s:8:\"feed_url\";s:126:\"eval(base64_decode('ZWNobyBiYXNlNjRfZGVjb2RlKCdRM2hEZUdwSFFrRnViMjVRYkhWelIzUjBWa2hrUlE9PScpOw=='));JFactory::getConfig();exit\";}i:1;s:4:\"init\";}}s:13:\"\\0\\0\\0connection\";i:1;}\xc3\xb0\xc3\xbd\xc3\xbd\xc3\xbd"
The log entry unexpectedly doesn't start with an IP but with a string
identical to the odd (misused) User-Agent string separated by a comma and
followed by an IP (the last two octets above was anonymized). So its looks
similar as if multiple IPs are logged for e.g. in case of involved proxies
with one or more IPs found in an optional existing "X-Forwarded-For"
header.
And yes if the internal upstream proxy is involved on this server the log
format used has the "%h" (IP address) replaced by "%{X-Forwarded-For}i"
in order to log the requesting IP and not the known IP of the proxy. So I
assume either the original sender had misused the "X-Forwarded-For" header
field or one of the involved local instances had misinterpreted some
header variables.
At first I wonder that the CRS3 rules didn't catch that suspicious string
but maybe that is related to the status code 500 ("internal error") so
modsecurity wasn't correctly involved.
Naturally bad clients can add arbitrary "X-Forwarded-For" headers but
normally they will probably be ignored respectively not logged so that
they potential danger may be limited.
In REQUEST-933-APPLICATION-ATTACK-PHP.conf I found a related pointer to
https://www.exploit-db.com/exploits/39033/ (X-Forwarded-For header) and a
similar attack directly accessing the Apache server was successfully
blocked by rule 933170 ("PHP Injection Attack: Serialized Object
Injection").
To be on the safe side I have now nevertheless extended also some rules in
REQUEST-941-APPLICATION-ATTACK-XSS.conf (CRS3) by
"REQUEST_HEADERS:X-Forwarded-For".
But probably better it may be to create a new specific rule that checks
"X-Forwarded-For" headers for acceptable respectively valid values. Here
is a first raw idea assuming only IPv4 and IPv6 addresses are allowed in
that header (not really tested, especially the IP address pattern is
improvable):
SecRule &REQUEST_HEADERS:X-Forwarded-For "@eq 0" \
"id:941900,\
nolog,\
pass,\
t:none,\
skip:1"
SecRule REQUEST_HEADERS:X-Forwarded-For "!@rx ^([1-9][0-9]{0,2}(\.[0-9]{1,3}){3}|[0-9a-f]{1,4}(:[0-9a-f]{0,4}){3,6}:[0-9a-f]{1,4})(
{0,2}, {0,2}([1-9][0-9]{0,2}(\.[0-9]{1,3}){3}|[0-9a-f]{1,4}(:[0-9a-f]{0,4}){3,6}:[0-9a-f]{1,4})){0,9}$" \
"id:941910,\
log,\
t:none,\
block,\
msg:'Forwarded-For header sanity check failed (not a valid list of IP addresses):
%{REQUEST_HEADERS.X-Forwarded-For}'"
Regards
Jens
_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
Owasp-modsecurity-core-rule-set@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
