Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

one of our CentOS boxes that runs PHP/Apache was recently hacked. Luckily we were going to retire this server soon and have backups etc. However, I need some help in finding how the hackers were able to get in.

From what I have gathered, it appears that some scripts were written to our servers using apache (perhaps a PUT?) in apache error_logs I see:

    [Fri Sep 10 12:46:43 2010] [error] [client xx.xx.xx.xx] File does not exist: xyz.php   
    --2010-09-10 12:46:45--  http://208.75.xx.xx/newmax/max.txt
    Connecting to 208.75.xx.xx:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 28975 (28K) [text/plain]
    Saving to: `max.txt'

         0K .......... .......... ........                        100%  184K=0.2s

    2010-09-10 12:46:45 (184 KB/s) - `max.txt' saved [28975/28975]

      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
    ^M  3 28975    3  1140    0     0   8597      0  0:00:03 --:--:--  0:00:03  8597^M100 28975  100 28975    0     0  88203      0 --:--:-- --:--:-- --:--:--  139k
    sh: lynx: command not found
     [Fri Sep 10 12:46:43 2010] [error] [client xx.xx.xx.xx] File does not exist: xyz.php

(first and last line are just dummy error lines to indicate the log format and weirdness of how the entries are in between).

Any ideas how apache error log would have this format and how it might have been triggered?

I will add more to this question as I come across more findings.

share|improve this question
PHP is the most likely culprit - try auditing your PHP config (I wrote a script for auditing and fixing insecure configs - you can get a copy @ if you like) – danlefree Sep 29 '10 at 4:25

I would guess that register_globals is turned on and you're running OSCommerce without the four patches in their forums. Why they refuse to update the .zip/.gz files with the patches, I don't know.

I suppose that max.txt is probably c99 shell and is downloaded into your /store/images path as something.php. Once they are able to run that file in a browser, they have a remote shell.

If you're not running OSCommerce, look for hits on your include files. I.e. you may have a function.php file that shouldn't be called directly that has:

exec($path . 'convert blahblah');

a request is sent with:


which allows them to write a file to the disk that can be remotely executed. It is also possible that they used an XSS exploit in your code to do something like:

require($webpath . '/functions.lib.php');

and a request was sent through with ?webpath=hxxp:// which gave them a remote shell. Once they got the remote shell, they tried to run wget/lynx (or uploaded a shell script to run a number of methods to make sure their payload was installed)

In this case, allow_url_include=off could help.

share|improve this answer

A typical way to hack a server goes like this:

1) Server has PHP running with default settings; this means no safe_mode, all the POSIX functions are allowed (such as system()) and couple of versatile yet dangerous PHP modules, such as curl, are activated

2) Server has /tmp (or whatever the temp directory for http uploads is) mounted with default settings; this means it allows files to be executed.

3) Server has /var/www (or whatever the mount point for webroot is) mounted with default settings; this means it allows files to be executed.

4) There's a homebrew PHP script with weak input validation / a known vulnerability in some CMS or other software installed.

In an environment like this an attacker can upload an evil file via http or instruct the server to fetch one from a remote server, and then just run that script by passing some URL parameters which lacks input validation.

If a PHP script does not validate the input, the URL parameters (or POST request) could contain stuff like <?php system("/tmp/pwn4g3"); ?>. karmawhore already explained this.

So, to stop this kind of evilness:

  • mount webroot and PHP temp directory with noexec flag.
  • disable dangerous functions in PHP if possible
  • use PHP's safe_mode if possible (even though it's far from fool-proof and maybe completely removed over time).
  • don't allow Apache user to use gcc, or even better, don't install gcc to your webserver at all.
  • use mod_security.
  • use suhosin.
  • use php-fpm, suphp or other techniques to run scripts as their owner accounts instead of general Apache account.
  • keep your software up to date.
share|improve this answer
For completeness, it looks like safe_mode is already deprecated: – Joril Sep 29 '10 at 11:47
Yes, safe_mode has been deprecated for a long time already, but I'm not holding my breath for seeing it really going away... – Janne Pikkarainen Sep 29 '10 at 11:49
How can php-fpm be used to execute scripts from the file owners account? – The Pixel Developer Sep 30 '10 at 19:39

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.