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

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

Hi Jeroen,

Looks like we have a bug in the code. I will work to fix it in the next
2.6.4 release.

Thanks

On Tue, Mar 6, 2012 at 4:20 AM, Jeroen De Ridder <
voe...@gm...> wrote:

> 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).
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
>