[Snort-users] Protected content

Alex Tatistcheff alext at ...492...
Mon Dec 15 10:40:48 EST 2014

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


*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
- 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20141215/f0e2eef7/attachment.html>

More information about the Snort-users mailing list