From: Michael Haas <[email protected]<mailto:[email protected]>> Date: Fri, 15 Jul 2011 08:54:49 -0500 To: "[email protected]<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 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: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: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}-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: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}-WEB_ATTACK/SESSION_HIJACK-%{matched_var_name}=%{tx.0}" SecRule TX:UA_HASH "!@streq %{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}-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}-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] https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
