Good catch Michael. I updated the Session Hijacking rules in SVN trunk - http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/optional_rules/modsecurity_crs_16_session_hijacking.conf?revision=1820
-Ryan From: Michael Haas <[email protected]<mailto:[email protected]>> Date: Thu, 21 Jul 2011 03:18:42 -0500 To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Owasp-modsecurity-core-rule-set] Problem with modsecurity_crs_16_session_hijacking.conf Hello, in crs 2.2.1 there is a oversight in Rule 981063. It should save session.ip but it saves tx.ip_hash. And if the hash value should be saved then the "capture" is missing in the chained rule. Now only the 3 octets are saved so the naming of the variables is a little bit misunderstanding (tx.ip_hash). So the Rules should look like this. SecRule TX:IP "^(\d{1,3}\.\d{1,3}\.\d{1,3}\.)" "chain,phase:1,id:'981057',capture,t:none,nolog,pass" SecRule TX:1 ".*" "capture,t:sha1,t:hexEncode,setvar:tx.ip_hash=%{tx.0}" SecRule TX:IP "^(\d{1,3}\.\d{1,3}\.\d{1,3}\.)" "chain,phase:3,id:'981063',capture,t:none,nolog,pass" SecRule TX:1 ".*" "capture,t:sha1,t:hexEncode,setvar:session.ip=%{tx.0}" Michael 2011/7/17 Michael Haas <[email protected]<mailto:[email protected]>> 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<http://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]<mailto:[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]><mailto:[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]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[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]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> From: Michael Haas <<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>> Date: Fri, 15 Jul 2011 08:54:49 -0500 To: "<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>" <<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[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><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><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><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><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><http://rule.id>}-WEB_ATTACK/SESSION_HIJACK-%{matched_var_name}=%{tx.0}" SecRule TX:UA_HASH "!@streq %{SESSION.UA<http://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><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><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]><mailto:[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. ________________________________ 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
