mod-security-users

[mod-security-users] Boink filter

[<li...@32...>]

Hello,

I just had an attempt made on my server to exploit it. The user was able to
upload a folder call .sgurz into the tmp folder, this folder had 2 files,
boink and .boink2.

I do not think it did anything except use up all the apache processes.

What would the filer need to be in order to block this type of attack in the
future?

TIA

-Mike

Re: [mod-security-users] Boink filter

[Ivan R. <iv...@we...>]

li...@32... wrote:
> Hello,
> 
> I just had an attempt made on my server to exploit it. The user was able to
> upload a folder call .sgurz into the tmp folder, this folder had 2 files,
> boink and .boink2.
> 
> I do not think it did anything except use up all the apache processes.
> 
> What would the filer need to be in order to block this type of attack in the
> future?

  I don't think it's possible to do that. You could have a filter
  in place to watch for strings "boink" and such but that would be
  too easy to defeat simply by changing the names of the files.

  Were the files in the /tmp folder executable? Preventing execution
  in /tmp is always a good idea (either by mounting it non-executable
  or by using mandatory access controls via grsecurity or SELinux).

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com

Re: [mod-security-users] Boink filter

[Tom A. <tan...@oa...>]

li...@32... wrote:
> I just had an attempt made on my server to exploit it. The user was able to
> upload a folder call .sgurz into the tmp folder, this folder had 2 files,
> boink and .boink2.
> 
> I do not think it did anything except use up all the apache processes.
> 
> What would the filer need to be in order to block this type of attack in the
> future?

You need to search through the apache logs and find the query which 
resulted in the compromise.  That will tell you which software is 
allowing the upload to /tmp, and it will give you some insight into how 
to block that query.  For instance, I know that AWStats does not do 
proper sanitizing of some input because it once lead to a worm 
compromising my machine.  I then created a rule that prevents queries 
which involve "awstats" and several of its optional variables which I 
don't personally use:

SecFilterSelective THE_REQUEST "awstats" chain
SecFilterSelective ARGS 
"(pluginmode|loadplugin|debug|configdir|perl|cgi|chmod
|exec|print)"

The exploit ran perl code through one of these variables, which I found 
in my apache access log.  Grep'ing for "perl" might make your search 
easier.  However, your case might have involved a different tack.  In 
fact, it's possible a low-priviledge account was brute-force hacked 
through ssh, not through apache.  I've had that happen too.  Are the 
files in /tmp owned by the apache user?

Either way, run "ps ax" and search for running processes (perhaps 
masquerading as "init" or some other system program) which don't look 
like they belong, either because of the user that started it, the time 
it started, or the resources it's using.  That's probably your zombie. 
Note the name and owner, and kill that process.  Grep your ssh log for 
the username that launched it (or that own the files in /tmp), if not 
apache, to see if a brute-force attack was launched against it.

Hope that helps.

Tom

Re: [mod-security-users] Boink filter

[Jason H. <Jas...@tr...>]

Tom Anderson wrote:
> You need to search through the apache logs and find the query which
> resulted in the compromise.  That will tell you which software is
> allowing the upload to /tmp, and it will give you some insight into
> how to block that query.  For instance, I know that AWStats does not
> do proper sanitizing of some input because it once lead to a worm
> compromising my machine. 

And this is why everyone who can should use the chroot feature...

If your Website doesn't use CGI (i.e. it sticks to php), then sticking
it in a chroot jail stops all this nonsense.

I ran a (Redhat-5.0) Apache 1.X server for 4 years - unpatched - in a
jail. Several Apache and OpenSSL exploits later and it NEVER got
compromised (and there were a lot of attempts).

I'm not saying it's a "silver bullet", but it ruins a lot of these sorts
of automated attacks

IMHO: Anyone running a Reverse proxy in a security role should be doing
jails.

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

Re: [mod-security-users] Boink filter

[Augie S. <aug...@gm...>]

On 2/3/06, li...@32... <li...@32...> wrote:
> I just had an attempt made on my server to exploit it. The user was able =
to
> upload a folder call .sgurz into the tmp folder, this folder had 2 files,
> boink and .boink2.
> I do not think it did anything except use up all the apache processes.
> What would the filer need to be in order to block this type of attack in =
the
> future?

Turn mod_security on and watch the logs to see what gets through; you
may find that something like this helps:

# command execution attack wget
SecFilterSignatureAction "log,deny,status:403,msg:'wget command
execution attack'"
SecFilterSelective ARGS_VALUES ";[[:space:]]*wget[[:space:]]*"

But take Ivan's advice and remount /tmp noexec. We ended up just
symlinking /var/tmp /usr/tmp and /tmp to /dev/shm and remounting that
noexec, as those are all the popular spots for script kiddies to put
their junk.

Augie.


--
Registered Linux user #229905
GPG Public Key: http://www.schwer.us/schwer.asc
Key fingerprint =3D 9815 AE19 AFD1 1FE7 5DEE 2AC3 CB99 2784 27B0 C072