[Snort-devel] REPOST: decode plugin question

Chris Green cmg at ...81...
Thu Oct 11 06:32:16 EDT 2001


Steve Halligan <agent33 at ...269...> writes:

> I wrote this novel to the list awhile back and got no response.  Am I off
> base here?

No, you probably slipped through the cracks.  I'm replying over coffee
while trying to get ready for work so I'm sure I'm missing some of the
obvious.

We need to document this behaviour but first we'll have to get an
authoritative analysis
>
>>  I don't really care how I get there, but I'd like to get to the
>> point where all my alerts go to the same place.  Can I apply my
>> custom actions to the preprocessor?  

No.  The way to deal with this is to setup your defaults to do the
right thing.  I assume you are using custom ruletypes for lots of things.

>> Should I just remove the http_decode lines and just accept the fact
>> that I'll miss Unicode-obfuscated attacks?  

Perhaps unidecode should not have the CheckNull() and CheckDirTrans()
function calls and rely on later processing in the signature engine.

>> Is there another option that I've missed?
>
> This brings up another question I have.  Does the data that the various
> decode and defrag preprocessors decode or defrag get put through the
> signature matching engine after decoding or defragging.  

I believe it used to be both but it depends on the preprocessor.
Unicode seems to replace the current packet in the packet processing
chain.

Once an alert happens on a packet though, it's flagged as "dirty" and
because snort is a first match currently, it drops out of the
processing chain.

http_decode doesn't seem to to general purpose decoding for unicode
unless I'm missing something.  unidecode though...

> If so, way does the http and unicode spp's have there own alerts
> that relate to stuff that could be caught by a signature after
> decoding.  For example:
>
> I send a http get like this:
>
> GET /../../../winnt/cmd.exe
>
> It would trip one of a number of signatures.   Directory Traversal, cmd.exe
> access whatever.
>
> I send a http get like this:
>
> Get /..%5c..%5cwinnt/cmd.exe
>
> It would decode it to:
>
> GET /../../winnt/cmd.exe
>
> Which would trip the same signatures as above.
>
> But that is not what happens.  It trips an alert in spp_unicode and that is
> it.  This spp_unicode alert cannot be altered, sent to a different alert
> mech, or turned off without disabling the entire spp_unicode spp.  Why
> doesn't it just decode it, and put it through the signature engine?  

Good question.  Probably "it wasn't thought of that way at first".

> I believe this is the way spp_defrag works.  It only sends up a
> special alert of its own when something specifically relating to
> fragments happens.  The reassembled packet is pushed through the
> signature engine like any other packet for content checking.
>
> One more thing.  One could use unicode to obfuscate alot more than just
> directory traversal attacks.  

Right.  It would be nice to have unicode decoding the command channel
of FTP as well because I'm guessing it's useful there too and in plain
urls.

> We should catch these obfuscations with the signature engine rather
> than having to re-write the unicode plugin each time a new variant
> turns up.

Well, I think the obfuscations will show up as long as they aren't
also a directory transversal. It's just once an alert goes off, its
supposed to be important enough to look at. Given the amount of sensor
flooding one has to deal with the likes of IIS worms, perhaps not
doign any alerting ( except for the invalid ) in unicode would be
useful.




More information about the Snort-devel mailing list