Re: Protected content

["Russ Combs (rucombs)" <rucombs () cisco com>]

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<tel: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!