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
