Would this be an appropriate use for byte_test or byte_jump?
J
On Mar 18, 2009, at 6:16 PM, Paul Schmehl wrote:
--On Wednesday, March 18, 2009 21:21:47 +0100 Damiano Bolzoni <[email protected]
> wrote:
Ok, I will reply to both using this message.
On Mar 18, 2009, at 2:31 PM, Paul Schmehl wrote:
I don't know if any IDS could do this. You'd have to capture the
value
of Content-Length, insert that value into a variable, then compare
that variable against the number of bytes of a single value, all
while
examining the same packet.
Ok...so, it's not easy to catch any attack variation right? :)
Not in http traffic, no, but in application traffic, yes. The
problem with http traffic is that it's essentially freeform.
Btw, Snort did detect one attack instance, because a signature for
IIS has
something like 100 times the same byte value in it.
Yes, but the problem you posed was one signature to detect all
instances. That's easy to do in application traffic but much harder
to do in web traffic.
The problem is not only in catching the content length and storing it
somewhere, for later comparison...it would be already difficult to
detect
that the same byte value is repeated over and over (and everytime is
different). Why? Because Snort (and in general any other signature-
based IDS)
use regular expressions...in a regular expression you can only
state that an
expression must not occur at all, could occur, can occur once or
more, or it
can occur a number of times (but you cannot say how many times
exactly)
Well, conceptually, a regex could have the construct of /<the byte
value detected>{<the Content-Length}/. The problem is detecting
those values to get them in to the regex.
If, for example, you knew ahead of time you wanted to detect 100 A's
in a packet, pcre:/A{100}/; would do that for you. Not knowing
ahead of time, both values would have to be captured and used as
variables in the expression so; pcre:/byte-val{c-l-val}/;
--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
*******************************************
Check the headers before clicking on Reply.
--
Joel Esler T: 302-223-5974 (-) Gtalk: [email protected]
[m]
