[Snort-users] http_decode vs. alerts

Steve Halligan agent33 at ...187...
Mon Oct 1 13:37:05 EDT 2001

One more thing.  One could use unicode to obfuscate alot more than just
directory traversal attacks.  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.

> > 
> > 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?  Should I just remove the http_decode lines and 
> > just accept
> > the fact that I'll miss Unicode-obfuscated attacks?  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.  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?  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.
> -Steve

More information about the Snort-users mailing list