[Snort-users] Protected content

Jeremy Hoel jthoel at ...11827...
Mon Dec 15 16:17:22 EST 2014

Very nice write-up!  Thanks for the details explanation and example.

On Mon, Dec 15, 2014 at 8:40 AM, Alex Tatistcheff <alext at ...492...> wrote:

> 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.
> - 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 at 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20141215/b18af553/attachment.html>

More information about the Snort-users mailing list