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
