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]>
> 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
