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 <[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
> .
> 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 <[email protected]>
>
>>
>> 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
