Colegas que usam as versões 4.87...4.91 do Exim em seus servidores de e-mail - atualizem urgentemente para a versão 4.92, tendo previamente interrompido o próprio Exim para evitar hackers por meio do CVE-2019-10149.
Vários milhões de servidores em todo o mundo são potencialmente vulneráveis, a vulnerabilidade é classificada como crítica (pontuação básica do CVSS 3.0 = 9.8/10). Os invasores podem executar comandos arbitrários em seu servidor, em muitos casos a partir do root.
Por favor, certifique-se de estar usando uma versão fixa (4.92) ou uma que já tenha sido corrigida.
Ou corrija o existente, veja o tópico .
Atualização para centavos 6: sim. — para centos 7 também funciona, caso ainda não tenha chegado direto da epel.
UPD: Ubuntu é afetado 18.04 e 18.10, uma atualização foi lançada para eles. As versões 16.04 e 19.04 não são afetadas, a menos que opções personalizadas sejam instaladas nelas. Mais detalhes .
Agora que o problema descrito está sendo explorado ativamente (presumivelmente por um bot), notei uma infecção em alguns servidores (executando em 4.91).
A leitura adicional é relevante apenas para aqueles que já “compreenderam” - você precisa transportar tudo para um VPS limpo com software novo ou procurar uma solução. Vamos tentar? Escreva se alguém consegue superar esse malware.
Se você, sendo um usuário Exim e lendo isto, ainda não atualizou (não se certificou de que a versão 4.92 ou uma versão corrigida está disponível), pare e execute para atualizar.
Para quem já chegou lá, vamos continuar...
UPD: e dá o conselho certo:
Pode haver uma grande variedade de malware. Ao lançar o remédio para a coisa errada e sair da fila, o usuário não ficará curado e poderá não saber o que precisa ser tratado.
A infecção é perceptível assim: [kthrotlds] carrega o processador; em um VDS fraco é 100%, em servidores é mais fraco, mas perceptível.
Após a infecção, o malware exclui entradas do cron, registrando-se apenas lá para ser executado a cada 4 minutos, ao mesmo tempo que torna o arquivo crontab imutável. Crontab-e não é possível salvar as alterações, ocorre um erro.
Imutável pode ser removido, por exemplo, assim, e depois deletado na linha de comando (1.5kb):
chattr -i /var/spool/cron/root
crontab -e
A seguir, no editor crontab (vim), exclua a linha e salve:dd
:wq
No entanto, alguns dos processos ativos estão sendo sobrescritos novamente, estou descobrindo.
Ao mesmo tempo, há um monte de wgets (ou curls) ativos pendurados nos endereços do script do instalador (veja abaixo), estou derrubando-os assim por enquanto, mas eles começam de novo:
ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Stopping..."
kill -9 `ps aux | grep wge[t] | awk '{print $2}'`
kill -9 `ps aux | grep cur[l] | awk '{print $2}'`
Encontrei o script do instalador do Trojan aqui (centos): /usr/local/bin/nptd... Não estou postando para evitá-lo, mas se alguém estiver infectado e entender scripts de shell, estude-o com mais atenção.
Acrescentarei à medida que as informações forem atualizadas.
UPD 1: Excluir arquivos (com chattr -i preliminar) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root não ajudou, nem interrompeu o serviço - eu tive que crontab completamente, por enquanto, retire-o (renomeie o arquivo bin).
UPD 2: O instalador do Trojan às vezes também estava em outros lugares, a pesquisa por tamanho ajudou:
encontrar / -tamanho 19825c
UPD 3: Atenção! Além de desabilitar o selinux, o Trojan também adiciona seu próprio Chave SSH em ${sshdir}/authorized_keys! E ativa os seguintes campos em /etc/ssh/sshd_config, caso ainda não tenham sido definidos como YES:
PermitRootLogin sim
RSAAutenticação sim
PubkeyAuthentication sim
eco UsePAM sim
PasswordAuthentication sim
UPD 4: Para resumir no momento: desative o Exim, cron (com raízes), remova urgentemente a chave do Trojan do ssh e edite a configuração do sshd, reinicie o sshd! E ainda não está claro se isso vai ajudar, mas sem isso há problema.
Mudei informações importantes dos comentários sobre patches/atualizações para o início da nota, para que os leitores comecem por elas.
UPD 5: que o malware alterou as senhas no WordPress.
UPD 6: , vamos testar! Após uma reinicialização ou desligamento, o remédio parece desaparecer, mas pelo menos por enquanto é isso.
Qualquer pessoa que fizer (ou encontrar) uma solução estável, por favor escreva, você ajudará muitos.
UPD 7: escreve:
Se você ainda não disse que o vírus ressuscitou graças a uma carta não enviada no Exim, ao tentar enviar a carta novamente, ela é restaurada, procure em /var/spool/exim4
Você pode limpar toda a fila do Exim assim:
exipick -i | xargs exim -Mrm
Verificando o número de entradas na fila:
exim-bpc
UPD 8: Novamente : FirstVDS ofereceu sua versão do script para tratamento, vamos testar!
UPD 9: Parece trabalhoobrigado para o roteiro!
O principal é não esquecer que o servidor já estava comprometido e os invasores poderiam ter conseguido plantar mais algumas coisas desagradáveis atípicas (não listadas no conta-gotas).
Portanto, é melhor migrar para um servidor totalmente instalado (vds), ou pelo menos continuar monitorando o assunto - se houver alguma novidade, escreva aqui nos comentários, pois obviamente nem todo mundo mudará para uma nova instalação...
UPD 10: Obrigado novamente : lembra que não apenas os servidores estão infectados, mas também Raspberry Pi, e todo tipo de máquinas virtuais... Então depois de salvar os servidores, não esqueça de salvar seus consoles de vídeo, robôs, etc.
Atualização 11: De Nota importante para curandeiros manuais:
(depois de usar um ou outro método de combate a este malware)
Você definitivamente precisa reiniciar - o malware fica em algum lugar nos processos abertos e, consequentemente, na memória, e grava um novo no cron a cada 30 segundos
UPD 12: Exim tem outro (?) malware em sua fila e aconselha você a primeiro estudar seu problema específico antes de iniciar o tratamento.
UPD 13: em vez disso, mude para um sistema limpo e transfira os arquivos com muito cuidado, porque O malware já está disponível publicamente e pode ser usado de outras formas, menos óbvias e mais perigosas.
UPD 14: nos assegurando de que pessoas inteligentes não fogem da raiz - mais uma coisa :
Mesmo que não funcione a partir do root, ocorre hacking... Eu tenho debian jessie UPD: esticar no meu OrangePi, Exim está rodando a partir do Debian-exim e ainda assim aconteceu hacking, perdi coroas, etc.
UPD 15: ao mudar de um servidor comprometido para um servidor limpo, não se esqueça da higiene, :
Ao transferir dados, preste atenção não apenas aos arquivos executáveis ou de configuração, mas também a qualquer coisa que possa conter comandos maliciosos (por exemplo, no MySQL pode ser CREATE TRIGGER ou CREATE EVENT). Além disso, não se esqueça de .html, .js, .php, .py e outros arquivos públicos (idealmente, esses arquivos, como outros dados, devem ser restaurados de armazenamento local ou outro armazenamento confiável).
UPD 16: и : o sistema tinha uma versão do Exim instalada nos ports, mas na realidade outra versão estava rodando.
Então todos após a atualização você deve ter certeza que você está usando a nova versão!
exim --versionResolvemos sua situação específica juntos.
O servidor utilizou DirectAdmin e seu antigo pacote da_exim (versão antiga, sem vulnerabilidade).
Ao mesmo tempo, com a ajuda do gerenciador de pacotes custombuild do DirectAdmin, uma versão mais recente do Exim foi instalada, que já estava vulnerável.
Nesta situação específica, a atualização via custombuild também ajudou.
Não se esqueça de fazer backups antes de tais experimentos, e também certifique-se de que antes/depois da atualização todos os processos do Exim sejam da versão antiga e não “preso” na memória.
Fonte: habr.com