[Mod-security-developers] [ModSecurity 2.6.3] Session collection broken

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I'm currently encountering some trouble with the optional
modsecurity_crs_16_session_hijacking.conf ruleset (v.2.2.4) in
ModSecurity 2.6.3. An initial uncookied request sent to the server is
accepted, but every subsequent request is blocked by rule 981059
because of an IP hash mismatch:

SecRule TX:IP_HASH "!@streq %{SESSION.IP_HASH}"
"phase:1,id:'981059',t:none,block,setvar:tx.sticky_session_anomaly=+1,msg:'Warning
- Sticky SessionID Data Changed - IP Address
Mismatch.',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/SESSION_HIJACK-%{matched_var_name}=%{tx.0}"

(I'm running in traditional mode, so the "block" action equals "deny").

I understand the logic of these rules, and I've poured over the debug
logs to see what's going on. The logic itself seems fine; all the
values being passed around are correct, but the problem seems to be
that subsequent requests fail to load the session collection data that
was saved in the initial request that created it. I've confirmed this
by inserting an adding the following rule inbetween rules 981055 and
981056 to print the loaded session collection data:

SecAction "phase:1,t:none,pass,log,logdata:'_DEBUG_ Initialized
session using key %{tx.sessionid};
session.sessionid=%{session.sessionid};
session.valid=%{session.valid}; session.ip_hash=%{session.ip_hash};
session.ua_hash=%{session.ua_hash};'"

The tx.sessionid value is correct (ie. the same as was used to the
setsid call in the initial request), but the session collection seem
to be completely empty. This naturally causes tx.ip_hash to not match
session.ip_hash, resulting in the block. Note that this debug rule is
not reached unless the client sent a session cookie and the session
collection was hence initialized by setsid:%{matched_var} in rule
981054, whose value I've also confirmed to be correct.

To isolate and demonstrate the problem, I've created a very minimal
testcase and ran them on both ModSecurity 2.5.11 and 2.6.3. No other
rulesets were loaded, not even crs_10_config. The machine running
2.5.11 is a somewhat older box running Apache 2.0.63 on RHEL4, the
machine running 2.6.3 is running Apache 2.2.21 on RHEL5.

SecRuleEngine On
SecDebugLogLevel 9
SecDataDir config/modsecurity/data
SecRequestBodyAccess On
SecAction "phase:1,pass,log,setsid:'abcd1234',logdata:'Reading session
variable session.foo=%{session.foo}'"
SecAction "phase:1,pass,log,setsid:'abcd1234',logdata:'Incrementing
session variable session.foo=%{session.foo}',setvar:session.foo=+1"

After cleaning out the ModSec data dirs and rebooting the Apache
servers, here's the apache error log output for three subsequent
requests to the same page from ModSecurity 2.5.11:

[Tue Mar 06 11:07:49 2012] [notice] caught SIGTERM, shutting down
[Tue Mar 06 11:07:50 2012] [notice] ModSecurity for Apache/2.5.11
(http://www.modsecurity.org/) configured.
[Tue Mar 06 11:07:51 2012] [notice] Apache/2.0.63 (Unix)
mod_ssl/2.0.63 OpenSSL/0.9.7m configured -- resuming normal operations
[Tue Mar 06 11:08:03 2012] [error] [client 10.245.26.55] ModSecurity:
Warning. Unconditional match in SecAction. [file
"/code/lk7/modsec/active/config/httpd_front_poc_apache_web.conf"]
[line "31"] [data "Reading session variable session.foo="] [hostname
"10.151.49.29"] [uri "/"] [unique_id "N-YWGX8AAAEAACcGTWUAAAAA"]
[Tue Mar 06 11:08:03 2012] [error] [client 10.245.26.55] ModSecurity:
Warning. Unconditional match in SecAction. [file
"/code/lk7/modsec/active/config/httpd_front_poc_apache_web.conf"]
[line "32"] [data "Incrementing session variable session.foo=1"]
[hostname "10.151.49.29"] [uri "/"] [unique_id
"N-YWGX8AAAEAACcGTWUAAAAA"]
[Tue Mar 06 11:08:08 2012] [error] [client 10.245.26.55] ModSecurity:
Warning. Unconditional match in SecAction. [file
"/code/lk7/modsec/active/config/httpd_front_poc_apache_web.conf"]
[line "31"] [data "Reading session variable session.foo=1"] [hostname
"10.151.49.29"] [uri "/"] [unique_id "OEU9jX8AAAEAACcGTWYAAAAA"]
[Tue Mar 06 11:08:08 2012] [error] [client 10.245.26.55] ModSecurity:
Warning. Unconditional match in SecAction. [file
"/code/lk7/modsec/active/config/httpd_front_poc_apache_web.conf"]
[line "32"] [data "Incrementing session variable session.foo=2"]
[hostname "10.151.49.29"] [uri "/"] [unique_id
"OEU9jX8AAAEAACcGTWYAAAAA"]
[Tue Mar 06 11:08:11 2012] [error] [client 10.245.26.55] ModSecurity:
Warning. Unconditional match in SecAction. [file
"/code/lk7/modsec/active/config/httpd_front_poc_apache_web.conf"]
[line "31"] [data "Reading session variable session.foo=2"] [hostname
"10.151.49.29"] [uri "/"] [unique_id "OHLo4X8AAAEAACcGTWcAAAAA"]
[Tue Mar 06 11:08:11 2012] [error] [client 10.245.26.55] ModSecurity:
Warning. Unconditional match in SecAction. [file
"/code/lk7/modsec/active/config/httpd_front_poc_apache_web.conf"]
[line "32"] [data "Incrementing session variable session.foo=3"]
[hostname "10.151.49.29"] [uri "/"] [unique_id
"OHLo4X8AAAEAACcGTWcAAAAA"]

And the same for ModSecurity 2.6.3:

[Tue Mar 06 11:04:25 2012] [notice] caught SIGTERM, shutting down
[Tue Mar 06 11:04:27 2012] [notice] ModSecurity for Apache/2.6.3
(http://www.modsecurity.org/) configured.
[Tue Mar 06 11:04:27 2012] [notice] ModSecurity: APR compiled
version="1.4.5"; loaded version="1.4.5"
[Tue Mar 06 11:04:27 2012] [notice] ModSecurity: PCRE compiled
version="5.0"; loaded version="5.0 13-Sep-2004"
[Tue Mar 06 11:04:27 2012] [notice] ModSecurity: LUA compiled version="Lua 5.1"
[Tue Mar 06 11:04:27 2012] [notice] ModSecurity: LIBXML compiled
version="2.6.26"
[Tue Mar 06 11:04:28 2012] [notice] Apache/2.2.21 (Unix) configured --
resuming normal operations
[Tue Mar 06 11:04:38 2012] [error] [client 10.245.26.55] ModSecurity:
Warning. Unconditional match in SecAction. [file
"/code/dev/modsec/2.3/config/modsecurity/modsecurity_common.conf"]
[line "24"] [data "Reading session variable session.foo="] [hostname
"10.151.49.35"] [uri "/"] [unique_id "T1XhNn8AAAEAABcJAu0AAAAA"]
[Tue Mar 06 11:04:38 2012] [error] [client 10.245.26.55] ModSecurity:
Warning. Unconditional match in SecAction. [file
"/code/dev/modsec/2.3/config/modsecurity/modsecurity_common.conf"]
[line "25"] [data "Incrementing session variable session.foo=1"]
[hostname "10.151.49.35"] [uri "/"] [unique_id
"T1XhNn8AAAEAABcJAu0AAAAA"]
[Tue Mar 06 11:04:38 2012] [error] [client 10.245.26.55] ModSecurity:
Warning. Unconditional match in SecAction. [file
"/code/dev/modsec/2.3/config/modsecurity/modsecurity_common.conf"]
[line "24"] [data "Reading session variable session.foo="] [hostname
"10.151.49.35"] [uri "/"] [unique_id "T1XhNn8AAAEAABcJAu4AAAAA"]
[Tue Mar 06 11:04:38 2012] [error] [client 10.245.26.55] ModSecurity:
Warning. Unconditional match in SecAction. [file
"/code/dev/modsec/2.3/config/modsecurity/modsecurity_common.conf"]
[line "25"] [data "Incrementing session variable session.foo=1"]
[hostname "10.151.49.35"] [uri "/"] [unique_id
"T1XhNn8AAAEAABcJAu4AAAAA"]
[Tue Mar 06 11:04:39 2012] [error] [client 10.245.26.55] ModSecurity:
Warning. Unconditional match in SecAction. [file
"/code/dev/modsec/2.3/config/modsecurity/modsecurity_common.conf"]
[line "24"] [data "Reading session variable session.foo="] [hostname
"10.151.49.35"] [uri "/"] [unique_id "T1XhN38AAAEAABcJAu8AAAAA"]
[Tue Mar 06 11:04:39 2012] [error] [client 10.245.26.55] ModSecurity:
Warning. Unconditional match in SecAction. [file
"/code/dev/modsec/2.3/config/modsecurity/modsecurity_common.conf"]
[line "25"] [data "Incrementing session variable session.foo=1"]
[hostname "10.151.49.35"] [uri "/"] [unique_id
"T1XhN38AAAEAABcJAu8AAAAA"]

I've made sure the modsecurity data dir has full 0777 access to see if
perhaps that's the problem, but no dice. I can see it create the
default_SESSION.(dir|pag) files, and I can spot some of the saved
values in there, but they just don't seem to get reloaded on the next
request. I've actually tried this both on a 2.6.3 instance with PCRE
linked statically against Apache's bundled distro, as well as on an
instance linked against a system libpcre, but it occurs on both.

Can anyone confirm and/or advise? I'll be happy to provide debug logs,
but in the interest of not cluttering up this report I'll leave them
for another reply (if needed).