Hacked - FreeBSD 7.1-Release

[Squirrel]

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 at infracaninophile.co.uk
Date: Thu, 10 Dec 2009 02:24:34 -0600
To: squirrel at isot.com
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 at 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 at 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
> 
> 
>