Re: Protected content

[Alex Tatistcheff <alext () pobox com>]

Ok Russ and I have looked into this issue and here is what we found.

First, I tried a simple content match with two pieces of content.

content:"Snort"; content:"pig"; distance:1; within:3;

This will find "Snort?pig" with ? meaning any byte. It will match packets
with content like "Snort pig".  It will also match packets containing text
like "Snort dog Snort pig"  This means Snort is searching for and finding
the first piece of content more than once.  This is not what I would have
predicted based on the stop processing behavior but I am glad it does.
This will avoid the simple evasion of inserting a bogus string ahead of the
match.

However, I've seen something different with the protected_content option.
In my write-up I mentioned that my search for a protected string would be
subject to the "evasion" mentioned above because it would not continue to
look after the first failure.  This has been borne out in my testing.  Here
is how I tested:

The rule:
alert tcp any any -> any any (sid:1000009; \
content:"man"; protected_content:"efaa25379dced0fea71b03fe37da6d08";
hash:md5; length:9; distance:-9; \
msg:"Spiderman  ";)

The protected content hash is for the string "Spiderman"

In testing, a packet with "Spiderman" triggered the rule.  However a packet
with "Superman-Spiderman" did not trigger the rule.  I believe this is
because the first string with "man" is being hashed by protected_content
and it's coming up with a no-match.  After that, it does not appear to
continue through the packet searching for the next instance of "man" and
then doing the hash again.  So in this case, I was able to "evade" the
detection by putting a "man" ahead of the protected content string.

Russ has confirmed this and filed bug for Snort, it should continue through
and find the protected_content in the "Superman-Spiderman" example as it
does in the simple content match.



Alex Tatistcheff
alext () pobox com
Not sent from my iPad - just thought you should know

On Tue, Dec 16, 2014 at 4:57 AM, Russ Combs (rucombs) <rucombs () cisco com>
wrote:
>  Alex, #3 below is incorrect.  Snort will look for another match on the
> prior content.  That is important because otherwise evasion could be done
> simply by placing a "decoy" content ahead of the attack pattern.
>
>  Consider this simple example.  attack_now.pcap has this packet data:
>
>      "attack not attack   now attack now"
>
>  And attack_nop.pcap has this packet data:
>
>      "attack not attack   now attack nop"
>
>  We write 2 rules, sid 1 looks for "attack?now", and sid 2 looks for
> "attack?nop" where the ? represents any single byte.  The first rule
> ensures that "now" follows "attack" with one byte in between.  The second
> rule just reinforces that we are indeed matching at the correct point.
>
>  $ cat snort.conf
> alert tcp any any -> any 8 ( sid:1; msg:"now"; content:"attack";
> content:"now"; distance:1; within:3; )
> alert tcp any any -> any 8 ( sid:2; msg:"nop"; content:"attack";
> content:"nop"; distance:1; within:3; )
>
>  $ snort -c snort.conf -A cmg -q -r attack_now.pcap
> 12/16-07:04:56.817012  [**] [1:1:0] now [**] [Priority: 0] {TCP}
> 10.1.2.3:48620 -> 10.9.8.7:8
> 12/16-07:04:56.817012 02:01:02:03:04:05 -> 02:09:08:07:06:05 type:0x800
> len:0x58
> 10.1.2.3:48620 -> 10.9.8.7:8 TCP TTL:64 TOS:0x0 ID:1 IpLen:20 DgmLen:74
> ******** Seq: 0x0  Ack: 0x0  Win: 0x2000  TcpLen: 20
> 61 74 74 61 63 6B 20 6E 6F 74 20 61 74 74 61 63  attack not attac
> 6B 20 20 20 6E 6F 77 20 61 74 74 61 63 6B 20 6E  k   now attack n
> 6F 77                                            ow
>
>
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>
>
>  $ snort -c snort.conf -A cmg -q -r attack_nop.pcap
> 12/16-07:07:54.371312  [**] [1:2:0] nop [**] [Priority: 0] {TCP}
> 10.1.2.3:48620 -> 10.9.8.7:8
> 12/16-07:07:54.371312 02:01:02:03:04:05 -> 02:09:08:07:06:05 type:0x800
> len:0x58
> 10.1.2.3:48620 -> 10.9.8.7:8 TCP TTL:64 TOS:0x0 ID:1 IpLen:20 DgmLen:74
> ******** Seq: 0x0  Ack: 0x0  Win: 0x2000  TcpLen: 20
> 61 74 74 61 63 6B 20 6E 6F 74 20 61 74 74 61 63  attack not attac
> 6B 20 20 20 6E 6F 77 20 61 74 74 61 63 6B 20 6E  k   now attack n
> 6F 70                                            op
>
>
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>
>  This is a simple example but the concept generalizes to backtracking
> multiple times with more complex rules until the available data is
> exhausted or we find a match.  protected_content works similarly but note
> that the within modifier is not supported.
>
>  ------------------------------
> *From:* alex.tatistcheff () gmail com [alex.tatistcheff () gmail com] on behalf
> of Alex Tatistcheff [alext () pobox com]
> *Sent:* Tuesday, December 16, 2014 1:13 AM
> *To:* Russ Combs (rucombs)
> *Cc:* Snort Users List
> *Subject:* Re: [Snort-users] Protected content
>
>   Ok I tested the situation where my "content" keyword matches the FIRST
> instance of the content in the packet however when the protected_content
> keyword checks the entire string this does not match the hash.  The
> question is will Snort look further in the packet for the NEXT content
> match of the same word - "over" - in my example above?
>
>  Key behaviors to remember about Snort:
> 1. Process each of the detection keywords in order
> 2. All rule keywords are joined by logical AND (all keywords must be true
> for the rule to trigger)
> 3.  Stop process on first "no match"
>
>  I discovered that the rule will fail to trigger if the
> content/protected_content is found after the first instance in the packet.
> I believe this has to do with the fact that for a rule to trigger every
> keyword in the rule must evaluate to true.  For the first "over" in the
> packet, the protected_content check of the entire string length returns
> false.  As soon as Snort encounters a keyword that does not evaluate to
> true it stops processing the packet.  This is pretty much how the content
> keyword works too, it will find the first instance of the string (assuming
> no offset or depth modifiers) and proceed from there.  Snort will not
> process keywords in the rule repeatedly for a single packet.
>
>  So my "disadvantages" above still stand.  We could miss the
> protected_content string if it came after we located the "content" at an
> earlier location in the packet.
>
>  Thanks for bringing that up Russ!
>
>  Alex Tatistcheff
> alext () pobox com
> Not sent from my iPad - just thought you should know
>
> On Mon, Dec 15, 2014 at 11:48 AM, Russ Combs (rucombs) <rucombs () cisco com>
> wrote:
> >  Alex, that's a pretty good write up.  See below for a comment.
> >
> >  ------------------------------
> > *From:* Alex Tatistcheff [alext () pobox com]
> > *Sent:* Monday, December 15, 2014 10:40 AM
> > *To:* Snort Users List
> > *Subject:* [Snort-users] Protected content
> >
> >    I’ve been fiddling with some new options in Snort 2.9.7 rules.
> > Specifically the new protected_content rule option. I discovered some
> > things that are not clear in the Snort Manual so I thought I would share.
> >
> > The protected_content option is designed to allow searching for content
> > in a packet without having to spell out the content in the rule. That way
> > if your rule is looking for something sensitive, you can hide this from
> > anyone with access to the rule. It’s helpful if you’re looking for things
> > like passwords you have used. In my case I have some content rules looking
> > for my wife’s common passwords leaving the network. (I, of course would
> > never re-use a password) ;-)
> >
> > My old rules had the password clearly shown in the content match. So I
> > thought this would be a perfect match for the new keyword. However, there
> > are some differences between the two. The content keyword looks through the
> > entire packet (or whatever is entered in offset,depth,distance and within)
> > for the string. Protected_content is different, it only looks in a specific
> > spot. When using protected_content you search for a hash of the string
> > instead of the string itself. So Snort has to hash whatever bytes you want
> > to check. Because of this, we can’t really check an entire packet because
> > it would mean calculating hundreds of hashes - way too slow.
> >
> > The protected_content keyword comes with several parameters:
> >
> > The hash itself
> >
> > The hash type (md5, sha256, sha512)
> >
> > The length of the original string
> >
> > Optional - offset or distance
> >
> > Consider:
> >
> > *protected_content:"131848a7d09b05b96ea105fe238619e3"; hash:md5;
> > length:8;*
> >
> > This would look in the packet at byte offset zero for an 8 byte string
> > matching the md5 shown. It would ONLY look in the first 8 bytes. In this
> > case the length parameter works much like distance or within in a normal
> > content match.
> >
> > So, you need to look in a specific location. But how then do I find my
> > wife’s password? I have no idea how far into the packet it might be.
> >
> > There’s another consideration, the protected_content keyword is
> > “computationally expensive” according to the Snort Manual. So we should
> > precede it with a content match to take advantage of the fast pattern
> > matcher. Turns out I can kill two birds here, I can search the entire
> > packet and make the rule more efficient by using a content keyword prior.
> > The answer is to search for a small subset of my protected content to
> > determine what part of the packet to hash. Yes this does somewhat
> > compromise my secret string but it’s a tradeoff to get detection.
> >
> > Here is the rule:
> >
> > *alert tcp $HOME_NET any -> any any (sid:**1000000 <1000000>**;
> > content:"over"; protected_content:"ef87dbd48fed4bcaf02cfc9e8c534344";
> > hash:md5; length:11; distance:-6; metadata:service http, service smtp,
> > service imap, service pop3, impact_flag red; msg:"Sensitive data 1
> > ...over..."; classtype:sdf; rev:6; )*
> >
> > I start out looking for a portion of the secret word. Hopefully this is
> > as specific as possible without giving away too much. This is followed by
> > the protected content option which backs up far enough to get to the start
> > of my secret word and hash the required bytes.
> >
> > Disadvantages of this technique are:
> >
> > - If the word “over” occurs more than once I will only check for my
> > wife’s password the first time it’s seen in a packet. So it’s possible the
> > password could still be hiding later in a packet with “over" somewhere
> > earlier.
> >
> >
> >   * This should not be the case.  Specifically, Snort should move on to
> > the next matching "over", if any, after the prior fails on the protected
> > content.  Have you tried that?
> >
> >
> > - It’s not as fast as pure “content” but we knew that going in
> > - It requires that I put part of my secret word into a regular content
> > match
> > - Possibly other factors I haven’t discovered yet
> >
> > Well I hope that makes you think a bit. Reply if you have any thoughts on
> > additional ways to improve rules using this new keyword.
> >
> > Alex
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!