[CentOS] Centos 5.3 -> Apache - Under Attack ? Oh hell....

Wed Jun 3 15:21:56 UTC 2009
Michael A. Peters <mpeters at mac.com>

Neil Aggarwal wrote:
> Maco:
> 
>> i have other mandriva boxes and they all are ok. i m just so 
>> surprised that a centos box got compromised.
> 
> If you are not doing anything silly in your server
> configuration, this is not a CentOS issue.
> 
> Anything *can* be hacked.  It just so happens
> that it was your CentOS box this time.

My two cents here

I'm probably stating the obvious here for many users, but ... -

For web apps installed from CentOS / EPEL /etc - modify the 
configuration file to change apache alias directive.

Look at your web logs sometime, whether or not you use apps like 
phpmyadmin or squirrelmail, you will see requests to where CentOS (and 
other distros) make those apps available by default.

These requests are usually either brute force attacks against those apps 
or trying known (often patched if you keep yum up to date) exploits for 
them.

By changing the alias in the configuration file, when a new exploit is 
found and the script kiddies launch their scripts against the web, 
they'll likely miss your box unless they know where to send the request to.

Yes, that's security by obscurity, but security by obscurity will 
protect you from most script kitty attacks, and may prevent you from 
being owned by a close to zero day exploit.

For things like squirrelmail, don't allow it over http, require it be 
done over https to avoid any sniffing (open networks at coffee shops or 
student labs or common places for sniffing).

I recommend using suhosin for php - and use some of the suhosin 
directives that lock down the php install, such as not allowing shell 
execution from within php.

That will break some apps (IE squirrelmail requires exec to send a 
message) but you can specifically enable it for certain web apps and you 
may be able to patch some apps to no longer need shell execution (IE I 
believe that squirrelmail could be patched to use php's native mail 
interface, maybe even easily by using phpMailer, but I've not tried).

If you look in pear and pecl, you can sometimes find native ways to do 
what many apps currently want shell execution for - IE if you use shell 
execution for ImageMagick, there's a pecl binary extension you can build 
to do it in pure php w/o calling exec() thus allowing you turn off 
exec() via suhosin.

Many web applications are (historically anyway) vulnerable to sql 
injection attacks. These attacks can be used to get password hashes that 
allow the attacker to crack user accounts and elevate their privileges 
within the web app. Many of web applications out there in common use 
have not been audited.

SQL injection can pretty much be neutered by using prepared statements, 
so check your web app to see if it uses prepared statements and if it 
doesn't, port it to use prepared statements.

I personally port them to use the pear::mdb2 abstraction layer at the 
same time, giving me a little more flexibility in case I ever decide I 
don't want to use MySQL anymore.

And for user password hashes, one thing you'll find is that there are 
some passwords that are very commonly used, so if all you do to make 
your hash is some variant of md5sum($pass . $salt) and a cracker does 
get the hash - he just has to look for hashes that occur often and try 
the passwords used frequently against those accounts.

md5sum($pass . strtolower($username) . $salt) or something like that 
results in unique hashes for two accounts even if the two accounts have 
identical passwords.

Another problem many web applications have is they want the 
configuration file to be writeable by the web server - and even worse, 
executed by the web server as a script. I do not believe that is the 
case for any web apps in rhel/centos or epel, but for something you grab 
off the web (IE the sphyder search engine) that often is the case. Any 
web app that has a hole can then be used to trick apache into writing to 
that configuration file resulting in apache then executing the malicious 
code.

Make damn sure those configuration files are only readable by the web 
server, hand edit them to make changes. If you MUST use the admin 
interface of those apps to change configuration, then make a database 
table to hold the configurations and port the app to get its 
configuration from the database rather than flat file that apache can 
write to that the web app then parses as php.

Basically, audit every app out there you plan to use - the people who 
write these web applications often don't take security into 
consideration before they upload them to their server for your consumption.