Re: Hacked - FreeBSD 7.1-Release

I do have most of measure you've mentioned implemented. There is one website that is required to have register_global, which I have set on his directory/.htaccess to prevent site-wide. Currently, I'm in process of upgrading all my ports.

Thanks for info.


-----Original message-----
From: Matthew Seaman m.seaman@xxxxxxxxxxxxxxxxxxxxxx
Date: Thu, 10 Dec 2009 02:24:34 -0600
To: squirrel@xxxxxxxx
Subject: Re: Hacked - FreeBSD 7.1-Release

Squirrel wrote:
I've just finished the rtld patch. Now in process of regenerating
all the keys and certs. Next will look into php. But far as rtld
vulnerability, doesn't it require at least a local user account?
Looking at all the authentication, there wasn't any authenticated
session during the time frame. So I'm leaning more towards php
5.2.9, and checking all my ports.

You don't necessarily need to have a login session (ie. recorded in wtmp)
to exploit the rtld bug -- just control over some process and the ability
to run commands through it. Although the rtld bug is "only" a local root
compromise, since it is so simple to exploit it is a lot more dangerous
than most, and in combination with just about any form of remote exploit
it means your box get rooted.

Upgrading PHP and all ports is a good move. portaudit(1) is a good idea
but it doesn't necessarily address the direct route your attackers used.
My suspicions (in the absence of any detailed forensic examination of
your machine) are that you are running some vulnerable PHP code. This
may be part of a well known application, or it may be something locally written.

In this case, I'd recommend a number of measures:

* Run a security scanner like nikto (ports: security/nikto)
against each of the websites on your server. Do this at
regular intervals, and take action to fix any problems it
discovers.

* Make sure that you only grant the minimum necessary permissions
on the filesystem to allow apache to run your applications. In
general, everything under your doc root should be *readable* by
uid www but not *writable* -- don't be seduced by the idea of
making the webroot owned by www:www --- root:wheel is a much
better idea, and files should be mode 644, directories mode 755
unless there's a good reason to have them otherwise.

* Refuse to run any PHP application that requires you to have
'register_globals = YES' or to similarly poke enormous holes
in security through php.ini. Any application developer that
has not modified their code to use the $GLOBALS array by now
is lazy and incompetent and their code is likely to have all
sorts of other holes.

* Similarly give your web application only the minimum necessary
permissions it needs to access any databases. You'll frequently
see instructions to do things like: 'GRANT ALL PRIVILEGES ON foo.*
TO www@localhost WITH GRANT OPTION;' This is way too much and should
be trimmed down. Web apps rarely have any need to make schema
changes, and creating other UIDs is right out, so
'GRANT SELECT,INSERT,UPDATE,DELETE ON foo.* TO www@localhost' is a
much more reasonable starting point.

* Where a web application has a legitimate reason to want to write
to the filesystem (eg. uploading files), preferably confine the
write access to a separate directory tree outside the web root --
/tmp or /var/tmp aren't bad choices, but it might be better to
create a specific location for a particular application.

* Where a web application has an administrative mode preferably
arrange to run this over HTTPS thus protecting any passwords
from snooping. If the administrative mode needs to have generic
read/write access to the web tree, then consider running it in a
completely separate Apache instance with different user credentials
than the generally accessible web server.

Making the last point work with some arbitrary web application is
frequently challenging, but usually at least possible by a combination
of mod_rewrite and mod_proxy functions in the Apache config.

Cheers,

Matthew

--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW



_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Hacked - FreeBSD 7.1-Release
    ... Next will look into php. ... But far as rtld ... Make sure that you only grant the minimum necessary permissions ... Where a web application has an administrative mode preferably ...
    (freebsd-stable)
  • Re: Hacked - FreeBSD 7.1-Release
    ... Don't forget to check vulnerable php codes for SQL injection, LFI/RFI, ... Make sure that you only grant the minimum necessary permissions ... Where a web application has an administrative mode preferably ...
    (freebsd-stable)
  • Re: Hacked - FreeBSD 7.1-Release
    ... Also look into what modules that are loaded by php. ... You will maybe find something in the apache access log that can make you ... Make sure that you only grant the minimum necessary permissions ... Where a web application has an administrative mode preferably ...
    (freebsd-stable)
  • Re: downgrade php5
    ... doug schmidt wrote: ... Checking through my php_error.log these ports ... Unknown extension ncurses for PHP 5. ... your ports-supfile and csup the whole tree back to that date. ...
    (freebsd-questions)
  • Re: An update for PHP on VMS [was:Re: Compiling PHP and/or any PHP Extension on VMS]
    ... Grant Croker wrote: ... I have over the last year or so tried to build thePHPsource provided ... any brave soul had managed to buildPHPon their VMS system? ... for building PHP extensions on VMS). ...
    (comp.os.vms)