Re: msg update for these, please?

[Alex Kirk <akirk () sourcefire com>]

On Tue, Sep 28, 2010 at 3:55 PM, waldo kitty <wkitty42 () windstream net>wrote:

> On 9/28/2010 15:19, Alex Kirk wrote:
> > > >      16425 looks at a packet coming "up" from the client -
> > >
> > >     yes, so the client is uploading a file... possibly a game or
> self-extracting
> > >     binary to a file distribution channel like on the original BBS'
> where users
> > >     uploaded and downloaded lottsa files all day long ;)
> >
> > No, it's not. It's sending a GET request to the server that has a URI
> which
> > contains .exe. It's asking for a .exe file.
>
> ahhh... my bad... i didn't/don't see a content:"GET "; depth:4; in there...
> i
> assume a GET is determined because it is http_uri?

Actually, any method that has a ".exe" in the URI will fire on this. 99.99%
of the time that means GET.


> (yes, i realize that the content i just used up there is "old style" but it
> is
> extremely clear in its intent ;) )
>
> how would that rule appear if it were an actual executable upload to the
> "server"? i assume that would be a POST...

The URI would likely have nothing to do with a client uploading an
executable to a web server - it'd be in the POST data of a page that could
have an arbitrary URL (for example, you can POST an .exe up to a webmail
system, whose URI might look like "
https://mail.google.com/mail/?hl=en&shva=1#inbox";).

> > > >       which will then trigger data coming back "down" from the server
> that you may
> > > >       not want.
> > >
> > >     hunh? where do you see that in 1:16425? it would be the job of
> /other/ rules
> > >     to detect that, wouldn't it? ;)
> >
> > You don't see that in 16425. It's implied, though, from the fact that the
> client
> > has requested a .exe file that it's probably going to get such a file
> returned
> > to it. While 15306 will generally alert on the file being returned, we
> have SID
> > 16425 because some people want to drop outbound requests that have .exe
> in the URI.
>
> i can understand that... i missed, somehow, that this was a GET request...
> i
> hope your answers to the above can clarify that for me...
>
> that also means that my original post should have read like this...
>
> OLD:
>  15306   WEB-CLIENT Portable Executable binary file transfer
>  16425   WEB-CLIENT Portable Executable binary file transfer
>
> NEW:
>  15306   WEB-CLIENT Portable Executable binary file transfer
>   16425   WEB-CLIENT Executable binary file request
>
> OR:
>   15306   WEB-CLIENT Portable Executable binary file transfer to client
>   16425   WEB-CLIENT Executable binary file request to server

See my reply to Shawn.


> this because .exe does not denote a PE .exe binary by default ;)

As a file extension it sure does.

> i wonder what a GET /foo/my.exe.sourcecode.pas would do with that rule? :P

Honestly, it'd generate a FP. There's a feature request in to allow us to
pin a content to the end of a buffer (including, I believe, the end of a URI
before the parameters start) that should fix that.


> maybe i need more c0ffee?
>
> >     in any case, i really do think it best that the one to the client
> denotes
> >     that and the one to the server denotes that as well... no matter what
> else
> >     may happen after it gets where it is going :)  i do try to adhere to
> the
> >     KISS principle and go with the most simple choice when i can instead
> of
> >     over-engineering things ;) :P
> >
> >
> >          > Duplicate messages are generally no fun, though, so how about
> making the
> >             second
> >          > one "WEB-CLIENT Portable Executable binary file transfer -
> .exe in URI"?
> >             that might work but see above... ;)
> >
> >          > On Tue, Sep 28, 2010 at 1:48 PM, waldo kitty <
> wkitty42 () windstream net
> >         <mailto:wkitty42 () windstream net>
> >         <mailto:wkitty42 () windstream net <mailto:wkitty42 () windstream net
> > >
> >          > <mailto:wkitty42 () windstream net <mailto:
> wkitty42 () windstream net>
> >         <mailto:wkitty42 () windstream net <mailto:wkitty42 () windstream net>>>>
> wrote:
> >          >
> >          >
> >          >     can we get a MSG update for these, please??
> >          >
> >          >     OLD:
> >          >     15306   WEB-CLIENT Portable Executable binary file
> transfer
> >          >     16425   WEB-CLIENT Portable Executable binary file
> transfer
> >          >
> >          >     NEW:
> >          >     15306   WEB-CLIENT Portable Executable binary file
> transfer to client
> >          >     16425   WEB-CLIENT Portable Executable binary file
> transfer to server
> >          >
> >          >     or some such?
> >          >
> >          >     thanks!
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Snort-users mailing list
> Snort-users () 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://www.geocrawler.com/redir-sf.php3?list=snort-users



-- 
Alex Kirk
AEGIS Program Lead
Sourcefire Vulnerability Research Team
+1-410-423-1937
alex.kirk () sourcefire com

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

_______________________________________________
Snort-users mailing list
Snort-users () 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://www.geocrawler.com/redir-sf.php3?list=snort-users