Hi,
i have another problem with the rules in this file.
The Rules are working as expected if i change the IP or the UA but if i
change the sessionid to another value it's not working as expected.
I Think the following Rule is not working if the session id is changed to an
unknown value, because the ! operator does not work with non existent
variables(don't know if its a bug or not).
SecRule
REQUEST_COOKIES:'/(j?sessionid|(php)?sessid|(asp|jserv|jw)?session[-_]?(id)?|cf(id|token)|sid)/'
".*" "chain,phase:1,id:'981054',t:none,block,log,msg:'Invalid SessionID
Submitted.',setsid:%{matched_var},setvar:tx.sessionid=%{matched_var},skipAfter:END_SESSION_STARTUP"
SecRule SESSION:VALID "!@eq 1"
"t:none,setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{
rule.id}-WEB_ATTACK/INVALID_SESSIONID-%{matched_var_name}=%{tx.0}"
SESSION:VALID does not match if the SESSION.VALID Variable doesn't exist.
I have verfied this with the following test.
SecAction "phase:1,id:'2000',t:none,nolog,pass,setvar:tx.test=1"
SecRule TX:TEST "@eq 1" "phase:1,t:none,id:'2001'"
SecRule TX:TEST "!@eq 0" "phase:1,t:none,id:'2002'"
SecRule TX:TEST "!@eq 1" "phase:1,t:none,id:'2003'"
TEST1 doesn't exist.
SecRule TX:TEST1 "@eq 1" "phase:1,t:none,id:'2004'"
SecRule TX:TEST1 "!@eq 1" "phase:1,t:none,id:'2005'" Thats the Problem,
it should match because TEST1 is not equal to 1 but it does not match.
Debug Log for the test.
Rule 801648: SecAction
"phase:1,auditlog,id:2000,t:none,nolog,pass,setvar:tx.test=1"
Setting variable: tx.test=1
Set variable "tx.test" to "1".
Rule returned 1.
Match -> mode NEXT_RULE.
Rule 809ed0: SecRule "TX:TEST" "@eq 1"
"phase:1,pass,nolog,auditlog,t:none,id:2001"
Executing operator "eq" with param "1" against TX:test.
Target value: "1"
Rule returned 1.
Rule 80a588: SecRule "TX:TEST" "!@eq 0"
"phase:1,pass,nolog,auditlog,t:none,id:2002"
Executing operator "!eq" with param "0" against TX:test.
Target value: "1"
Rule returned 1.
Rule 80ac50: SecRule "TX:TEST" "!@eq 1"
"phase:1,pass,nolog,auditlog,t:none,id:2003"
Executing operator "!eq" with param "1" against TX:test.
Target value: "1"
Rule returned 0.
Rule 80b318: SecRule "TX:TEST1" "@eq 1"
"phase:1,pass,nolog,auditlog,t:none,id:2004"
Rule returned 0.
Rule 80dbd0: SecRule "TX:TEST1" "!@eq 1"
"phase:1,pass,nolog,auditlog,t:none,id:2005"
Rule returned 0.
If i change the Rule to only check if the Variable exists
&SESSION:VALID "!@eq 1" it's working.
Michael
2011/7/16 Ryan Barnett <[email protected]>
> Agreed - these need to be fixed. We can simplify the IP capturing ones by
> not using the hashed. We were using hashs initially for the User-Agent field
> as their length could get pretty long. We would not need that for IP
> addresses.
>
> I will fix these and push to the CRS SVN repo on Monday.
>
> Thanks.
> Ryan
>
> On Jul 16, 2011, at 2:24 PM, "Michael Haas" <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi,
>
> i think the Rule should be changed to something like that
>
> SecRule TX:IP "^(\d{1,3}\.\d{1,3}\.\d{1,3}\.)"
> "chain,phase:3,id:'981063',t:none,nolog,pass"
> SecRule MATCHED_VARS "(.*)"
> "capture,t:none,t:sha1,t:hexEncode,nolog,setvar:session.ip=%{tx.1}"
>
> then it works too.
>
> Michael
>
> 2011/7/15 Michael Haas <<mailto:[email protected]>
> [email protected]<mailto:[email protected]>>
> Hi,
>
> Yes i'm using <
> http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/optional_rules/modsecurity_crs_16_session_hijacking.conf>
>
> http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/optional_rules/modsecurity_crs_16_session_hijacking.conf
> .
> if i look at a debug log i see that the session.ip is not saved, i think it
> doesn't capture because it doesn't match.
>
> Rule 822ce0: SecRule "TX:IP" "@rx ^(\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.)"
> "phase:3,auditlog,id:981063,capture,t:none,t:sha1,t:hexEncode,nolog,pass,setvar:session.ip=%{tx.1}"
> T (0) sha1: "\xb5O`\x10\x1bj\xed\xdf\x81J\x8f\xfb\x11\x98^K\xfc{t4"
> T (0) hexEncode: "b54f60101b6aeddf814a8ffb11985e4bfc7b7434"
> Transformation completed in 24 usec.
> Executing operator "rx" with param "^(\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.)"
> against TX:ip.
> Target value: "b54f60101b6aeddf814a8ffb11985e4bfc7b7434"
> Operator completed in 2 usec.
> Rule returned 0.
> No match, not chained -> mode NEXT_RULE.
>
> If i use this Rule it captures because it matches.
>
> Rule 822cc8: SecRule "TX:IP" "@rx (.*)"
> "phase:3,auditlog,id:981063,capture,t:none,t:sha1,t:hexEncode,nolog,pass,setvar:session.ip=%{tx.1}"
> T (0) sha1: "\xb5O`\x10\x1bj\xed\xdf\x81J\x8f\xfb\x11\x98^K\xfc{t4"
> T (0) hexEncode: "b54f60101b6aeddf814a8ffb11985e4bfc7b7434"
> Transformation completed in 24 usec.
> Executing operator "rx" with param "(.*)" against TX:ip.
> Target value: "b54f60101b6aeddf814a8ffb11985e4bfc7b7434"
> Added regex subexpression to TX.0: b54f60101b6aeddf814a8ffb11985e4bfc7b7434
> Added regex subexpression to TX.1: b54f60101b6aeddf814a8ffb11985e4bfc7b7434
> Operator completed in 25 usec.
> Setting variable: session.ip=%{tx.1}
> Resolved macro %{tx.1} to: b54f60101b6aeddf814a8ffb11985e4bfc7b7434
> Set variable "session.ip" to "b54f60101b6aeddf814a8ffb11985e4bfc7b7434".
> Warning. Pattern match "(.*)" at TX:ip. [file
> "/xxx/modsecurity_crs_16_session_hijacking.conf"] [line "46"] [id "981063"]
> Rule returned 1.
> Match -> mode NEXT_RULE.
>
> The Problem is that the Target Value is already transformed with
> "t:sha1,t:hexEncode"
>
> Michael
>
>
> 2011/7/15 Ryan Barnett <<mailto:[email protected]>
> [email protected]<mailto:[email protected]>>
>
> From: Michael Haas <<mailto:[email protected]>
> [email protected]<mailto:[email protected]><mailto:<mailto:
> [email protected]>[email protected]<mailto:
> [email protected]>>>
> Date: Fri, 15 Jul 2011 08:54:49 -0500
> To: "<mailto:[email protected]>
> [email protected]<mailto:
> [email protected]><mailto:<mailto:
> [email protected]>
> [email protected]<mailto:
> [email protected]>>" <<mailto:
> [email protected]>
> [email protected]<mailto:
> [email protected]><mailto:<mailto:
> [email protected]>
> [email protected]<mailto:
> [email protected]>>>
> Subject: [Owasp-modsecurity-core-rule-set] Problem with
> modsecurity_crs_16_session_hijacking.conf
>
> Hi,
>
> i'm trying to use the session hijacking protection but have some problems
> with it.
>
> Are you using this file?
> <
> http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/optional_rules/modsecurity_crs_16_session_hijacking.conf
> >
> http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/optional_rules/modsecurity_crs_16_session_hijacking.conf
>
>
>
> The Rules 981057 and 981063 are never matching because they check a normal
> IP with a encoded IP (t:sha1,t:hexEncode) so the ip is never saved in the
> collection.
>
> You are misunderstanding the logic of these rules. Let's start at the end
> of the file.
>
>
> #
> # This rule will identify the outbound Set-Cookie SessionID data and
> capture it in a setsid
> #
> SecRule RESPONSE_HEADERS:/Set-Cookie2?/
> "(?i:(j?sessionid|(php)?sessid|(asp|jserv|jw)?session[-_]?(id)?|cf(id|token)|sid)=([^\s]+)\;\s?)"
> "chain,phase:3,id:'981062',t:none,pass,nolog,capture,setsid:%{TX.6},setvar:session.sessionid=%{TX.6},setvar:tx.ip=%{remote_addr},setvar:<
> http://tx.ua>tx.ua<http://tx.ua
> >=%{request_headers.user-agent},setvar:session.valid=1"
> SecRule SESSION:SESSIONID "(.*)"
> "t:none,t:sha1,t:hexEncode,capture,setvar:session.csrf_token=%{TX.1}"
>
> SecRule TX:IP "^(\d{1,3}\.\d{1,3}\.\d{1,3}\.)"
>
> "phase:3,id:'981063',capture,t:none,t:sha1,t:hexEncode,nolog,pass,setvar:session.ip=%{tx.1}"
> SecRule TX:UA "(.*)"
> "phase:3,id:'981064',capture,t:none,t:sha1,t:hexEncode,nolog,pass,setvar:<
> http://session.ua>session.ua<http://session.ua>=%{tx.0}"
>
> These rules will identify if/when common SessionIDs are being sent out by
> the app in Set-Cookie response headers. If these are found, then a few
> things happen -
>
> 1. Setsid is used to initialize the Session collection
> 2. The SessionID is marked as "valid" so that we can detect then bogus
> SessionIDs are sent (perhaps by brute force tools)
> 3. We then capture a hash of the network block of the client IP (first 3
> octets). We don't use full IP address as there a too many false positives
> where an IP will change, however the network block should not.
> 4. We then also capture a hash of the User-Agent string.
>
> Now that we have saved this data when the app sent out the Set-Cookie, we
> can now perform validation on subsequent requests. If a client sends a
> SessionID cookie value, we can check the data we have saved. Now onto the
> rules at the top of the rules file -
>
>
> #
> # This rule set will identify subsequent SessionIDs being submitted by
> clients in
> # Request Headers. First we check that the SessionID submitted is a valid
> one
> #
> SecMarker BEGIN_SESSION_STARTUP
>
> SecRule
> REQUEST_COOKIES:'/(j?sessionid|(php)?sessid|(asp|jserv|jw)?session[-_]?(id)?|cf(id|token)|sid)/'
> ".*" "chain,phase:1,id:'981054',t:none,block,log,msg:'Invalid SessionID
> Submitted.',setsid:%{matched_var},setvar:tx.sessionid=%{matched_var},skipAfter:END_SESSION_STARTUP"
> SecRule SESSION:VALID "!@eq 1"
> "t:none,setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{
> rule.id<http://rule.id
> >}-WEB_ATTACK/INVALID_SESSIONID-%{matched_var_name}=%{tx.0}"
>
> SecRule
> &REQUEST_COOKIES:'/(j?sessionid|(php)?sessid|(asp|jserv|jw)?session[-_]?(id)?|cf(id|token)|sid)/'
> "@eq 0"
> "phase:1,id:'981055',t:none,nolog,pass,skipAfter:END_SESSION_STARTUP"
>
> The first rule checks to see if the client is submitting a SessionID from
> the named list. If so, then we check the saved SessionID collection in
> ModSecurity to see if the "valid" variable exists. If not, then it means
> that we did not see the application hand out this SessionID and thus we can
> flag is as bogus.
>
> The last SecRule checks to see if there are no SessionID cookies at all.
> If the client didn't send one, then we can skip the other checks. Sidenote
> – from an optimization perspective, I guess we could switch these two rules
> around.
>
> Then we get to the set of rules you mentioned -
>
> SecAction
> "phase:1,id:'981056',t:none,nolog,pass,setuid:%{session.username},setvar:session.sessionid=%{tx.sessionid},setvar:tx.ip=%{remote_addr},setvar:<
> http://tx.ua>tx.ua<http://tx.ua>=%{request_headers.user-agent}"
>
> SecRule TX:IP "^(\d{1,3}\.\d{1,3}\.\d{1,3}\.)"
> "phase:1,id:'981057',capture,t:none,t:sha1,t:hexEncode,nolog,pass,setvar:tx.ip_hash=%{tx.0}"
> SecRule TX:UA "(.*)"
> "phase:1,id:'981058',capture,t:none,t:sha1,t:hexEncode,nolog,pass,setvar:tx.ua_hash=%{tx.0}"
>
> These rules are meant to capture the hash of the same data mentioned above
> but for the CURRENT transaction. Once we have these hashes capture in TX
> variables, we can then compare them to the data we originally saved in the
> Session collection when the Set-Cookie was issued -
>
>
> SecRule TX:IP_HASH "!@streq %{SESSION.IP}"
> "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<http://rule.id
> >}-WEB_ATTACK/SESSION_HIJACK-%{matched_var_name}=%{tx.0}"
> SecRule TX:UA_HASH "!@streq %{SESSION.UA<http://SESSION.UA>}"
> "phase:1,id:'981060',t:none,block,setvar:tx.sticky_session_anomaly=+1,msg:'Warning
> - Sticky SessionID Data Changed - User-Agent
> Mismatch.',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.%{
> rule.id<http://rule.id
> >}-WEB_ATTACK/SESSION_HIJACK-%{matched_var_name}=%{tx.0}"
> SecRule TX:STICKY_SESSION_ANOMALY "@eq 2"
> "phase:1,id:'981061',t:none,block,msg:'Possible Session Hijacking - IP
> Address and User-Agent
> Mismatch.',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{
> rule.id<http://rule.id
> >}-WEB_ATTACK/SESSION_HIJACK-%{matched_var_name}=%{tx.0}"
>
> These rules are simply check the current hashes with the saved hashes and
> they then increase an anomaly score.
>
> Hopefully this description helps to explain the logic of the Session
> Hijacking rules.
>
> -Ryan
>
>
> I changed "^(\d{1,3}\.\d{1,3}\.\d{1,3}\.)" to "(.*)" after that the Rules
> are working.
> Is this the right approach to fix this or should this be fixed in another
> way?
>
> Thanks in Advance
> Michael
>
>
> ________________________________
> This transmission may contain information that is privileged, confidential,
> and/or exempt from disclosure under applicable law. If you are not the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution, or use of the information contained herein (including any
> reliance thereon) is STRICTLY PROHIBITED. If you received this transmission
> in error, please immediately contact the sender and destroy the material in
> its entirety, whether in electronic or hard copy format.
>
>
>
> _______________________________________________
> Owasp-modsecurity-core-rule-set mailing list
> [email protected]<mailto:
> [email protected]>
> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
>
> ________________________________
> This transmission may contain information that is privileged, confidential,
> and/or exempt from disclosure under applicable law. If you are not the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution, or use of the information contained herein (including any
> reliance thereon) is STRICTLY PROHIBITED. If you received this transmission
> in error, please immediately contact the sender and destroy the material in
> its entirety, whether in electronic or hard copy format.
>
_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
[email protected]
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
