Hacked - FreeBSD 7.1-Release

[Ganbold]

Squirrel wrote:
> 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.
>   

Don't forget to check vulnerable php codes for SQL injection, LFI/RFI,
problematic file uploads etc.


Ganbold

> 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
>>
>>
>>
>>     
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>
>
>
>   


-- 
I'm glad that I'm an American, I'm glad that I am free, But I wish I
were a little doggy, And McGovern were a tree.