We were recently compromised when someone managed to upload the c99Shell to our server.
Now this shell is capable of traversing up the directory and I can even read files in /root with it.
My question is, worst case scenario, someone STILL manages to upload a script like this.
What methods do I use to prevent them from ever leaving that servers directory structure or executing shell commands?
Would I set open_basedir?
This is urgent so all help is much appreciated!
Well, the first thing to do would be to figure out what application allowed someone from the Internet to both upload and execute a PHP script – that’s problem #1
Assuming someone else managed to upload and execute c99Shell, what might you do to prevent that? I think open_basedir is only going to do so much for you there, it doesn’t trap every possible function PHP might run.
There’s some Apache modules out there with a goal of making it more secure; mod_security may help there. I’ve also seen some people who like mod_block_worms, though I haven’t tried it.
But there’s a variety of rules you can use with mod_security – some folks even seem to suggest disabling the use of certain PHP functions.
I haven’t done that, but I might recommend Googling on “mod_security c99Shell” for some ideas.
Yes we figured out where our hole was and patched it up immediately.
And yes, mod_security is what I am off to install right this minute.
Thanks for the input I still would like to hear from anyone else with ideas!
In trying to install some needed packages, I am running into several failures as such:
root@myserver:~/modsecurity-apache_2.5.7/apache2# apt-get install g++
Reading package lists… Done
Building dependency tree… Done
The following extra packages will be installed:
gcc-4.0-doc lib64stdc++6 libstdc++6-4.0-doc stl-manual
The following NEW packages will be installed:
g++ g+±4.0 libstdc++6-4.0-dev
0 upgraded, 3 newly installed, 0 to remove and 34 not upgraded.
2 not fully installed or removed.
Need to get 3743kB of archives.
After unpacking 14.2MB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 http://ca.archive.ubuntu.com dapper/main libstdc++6-4.0-dev 4.0.3-1ubuntu5 [1471kB]
Get:2 http://ca.archive.ubuntu.com dapper/main g+±4.0 4.0.3-1ubuntu5 [2271kB]
54% [2 g+±4.0 562597/2271kB 24%] Get:3 http://ca.archive.ubuntu.com dapper/main g++ 4:4.0.3-1 [1386B]
Fetched 3743kB in 3m3s (20.4kB/s)
Selecting previously deselected package libstdc++6-4.0-dev.
(Reading database … 64984 files and directories currently installed.)
Unpacking libstdc++6-4.0-dev (from …/libstdc++6-4.0-dev_4.0.3-1ubuntu5_i386.deb) …
Selecting previously deselected package g+±4.0.
Unpacking g+±4.0 (from …/g+±4.0_4.0.3-1ubuntu5_i386.deb) …
Selecting previously deselected package g++.
Unpacking g++ (from …/g++_4%3a4.0.3-1_i386.deb) …
Setting up sasl2-bin (2.1.19.dfsg1-0.1ubuntu3) …
Starting SASL Authentication Daemon: (failed).
invoke-rc.d: initscript saslauthd, action "start" failed.
dpkg: error processing sasl2-bin (–configure):
subprocess post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of virtualmin-base:
virtualmin-base depends on sasl2-bin; however:
Package sasl2-bin is not configured yet.
dpkg: error processing virtualmin-base (–configure):
dependency problems - leaving unconfigured
Setting up g+±4.0 (4.0.3-1ubuntu5) …
Setting up libstdc++6-4.0-dev (4.0.3-1ubuntu5) …
Setting up g++ (4.0.3-1) …
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)
Is this to do with the virtualmin install somehow?
i once uploaded that script myself for testing and forgot to remove it
it got indexed and some black hat kids played around with it. However they couldn’t do much
you need to set open_baserdir to stop most kids, + you can do something minimal like:
disable_functions = show_source, system, exec, shell_exec, passthru, popen, proc_open, ini_restore, symlink
and enable_dl off and fopen set to off
there are more settings in the php.ini you can use to make the server a bit safer
Im running in mod_fcgid with suexec and only give trusted users the possibility to change the php.ini
We decided to try out the suhosin php hardner, and I’ve apparently recompiled php properly as php -v says:
PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Nov 20 2008 16:39:28)
Copyright © 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright © 1998-2008 Zend Technologies
But phpinfo() doesn’t show this plugin, I’ve restarted apache but still nothing…Not sure what I need to be doing to get it to use the new version that I compiled…make, make test, make install…
This has been fixed by me.