Colegas, quem usa servidores de e-mail com Exim nas versões 4.87…4.91 — atualizem urgentemente para a versão 4.92, após interromper o próprio Exim para evitar a exploração através da CVE-2019-10149.
Potencialmente, vários milhões de servidores em todo o mundo estão vulneráveis, sendo que a vulnerabilidade é considerada crítica (pontuação base CVSS 3.0 = 9.8/10). Os invasores podem executar comandos arbitrários em seu servidor, muitas vezes com privilégios de root.
Por favor, assegure-se de que você está usando a versão corrigida (4.92) ou já tenha aplicado o patch.
Ou aplique um patch ao existente, veja o tópico .
Atualização para centos 6: veja. — para centos 7 também funciona, se ainda não chegou diretamente do epel.
UPD: Ubuntu afetados 18.04 e 18.10, a atualização foi lançada para eles. As versões 16.04 e 19.04 não foram afetadas, a menos que variantes personalizadas tenham sido instaladas. Mais detalhes .
Atualmente, o problema descrito lá está sendo explorado ativamente (provavelmente por um bot), notei infecções em alguns servidores meus (rodando no 4.91).
A seguir, as informações são relevantes apenas para aqueles que já foram infectados — é necessário ou transferir tudo para uma VPS limpa com software recém-instalado, ou buscar uma solução. Vamos tentar? Escreva se alguém puder lidar com essa malware.
Se você, sendo usuário do Exim e lendo isso, ainda não atualizou (não se certificou da presença da versão 4.92 ou de uma versão corrigida), por favor pare e rapidamente faça a atualização.
Para já infectados — continuaremos…
UPD: e dá um conselho correto:
Pode haver uma grande variedade de malwares. Executar um remédio errado e limpar a fila não vai curar o usuário e possivelmente ele não vai saber o que precisa realmente tratar.
A infecção é notável assim: [kthrotlds] sobrecarrega o processador; em um VDS fraco a 100%, em servidores mais fracos, mas notável.
Após a infecção, o malware remove registros no cron, inserindo apenas a si mesmo para execução a cada 4 minutos, ao mesmo tempo fazendo o arquivo crontab imutável. Crontab -e não consegue salvar as alterações, gera um erro.
Imutável pode ser removido, por exemplo assim, após o que você pode excluir a linha de comando (1.5kb):
chattr -i /var/spool/cron/root
crontab -e Em seguida, no editor crontab (vim), deletar a linha e salvar:dd
:wq
No entanto, algum dos processos ativos está regravando novamente, eu estou verificando.
Enquanto isso, há vários wget ou curl ativos em endereços do script do instalador (veja abaixo), estou os interrompendo assim, mas eles reiniciam:
ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Parando..."
kill -9 `ps aux | grep wge[t] | awk '{print $2}'`
kill -9 `ps aux | grep cur[l] | awk '{print $2}'`
O script do instalador do trojan foi encontrado aqui (centos): \/usr\/local\/bin\/nptd… não o publico por precaução, mas se alguém estiver infectado e entender de scripts shell, por favor, estude com mais atenção.
Vou complementar à medida que houver mais informações.
UPD 1: Remoção de arquivos (com chattr -i prévio) \/etc\/cron.d\/root, \/etc\/crontab, rm -Rf \/var\/spool\/cron\/root não ajudou, assim como a interrupção do serviço — precisei remover o crontab totalmente (renomear o arquivo bin).
UPD 2: O instalador do trojan às vezes estava em outros lugares, a busca por tamanho ajudou:
find \/ -size 19825c
UPD 3: Atenção! Além de desativar o selinux, o trojan também adiciona seu chave SSH em ${sshdir}\/authorized_keys! E ativa os seguintes campos em \/etc\/ssh\/sshd_config, se ainda não estiverem configurados como YES:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes
UPD 4: Resumindo até agora: desativar exim, cron (com privilégios de root), remover urgentemente a chave do trojan do ssh e corrigir a configuração do sshd, reiniciar o sshd! E ainda não é certo que isso ajude, mas sem isso está uma calamidade.
Informações importantes dos comentários sobre patches/atualizações foram transferidas para o início da nota, para que quem lê comece por elas.
UPD 5: que o malware mudou as senhas no WordPress.
UPD 6: , estamos testando! Após a reinicialização ou desativação do remédio, parece que o problema volta, mas por enquanto, é assim.
Quem conseguir fazer (ou encontrar) uma solução estável, por favor, escreva, ajudará muitos.
UPD 7: escreve:
Se ainda não disseram, o vírus ressuscita devido a um e-mail não enviado no exim, na nova tentativa de envio, ele se restaura, verifique em \/var\/spool\/exim4
Para limpar toda a fila do exim, pode-se fazer assim:
exipick -i | xargs exim -Mrm
Verificação do número de registros na fila:
exim -bpc
UPD 8: Novamente : FirstVDS apresentou sua versão do script para cura, vamos testar!
UPD 9: Parece que trabalha, obrigado é por causa do script!
O principal é não esquecer que o servidor já foi comprometido e os invasores podem ter inserido outros tipos de malware (não listados no dropper).
Portanto, é melhor mudar para um servidor recém-instalado (vds), ou pelo menos continuar acompanhando o assunto — se algo novo surgir, escreva nos comentários aqui, pois claramente nem todos irão migrar para uma instalação nova...
UPD 10: Mais uma vez, obrigado : ele lembra que não são apenas os servidores que são infectados, mas, por exemplo, também Raspberry Pi, e várias máquinas virtuais... Então, após salvar os servidores, não se esqueça de salvar suas caixas de vídeo, robôs, etc.
UPD 11: De uma observação importante para "os que tratam manualmente":
(após aplicar algum dos métodos de combate a esse malware)
é necessário reiniciar — o malware está em algum lugar nos processos abertos e, consequentemente, na memória, e registra-se novamente no cron a cada 30 segundos
UPD 12: na sua fila exim outro(?) malware e aconselha a estudar sua própria situação antes de começar o tratamento.
UPD 13: migrar para um sistema limpo, e transferir arquivos com extrema cautela, pois o malware já está disponível publicamente e pode ser utilizado por outros de maneiras menos óbvias e mais perigosas.
UPD 14: se acalmando com o fato de que pessoas inteligentes não iniciam como root — mais uma :
Mesmo se funcionar fora do root, ainda ocorre a invasão... Eu tenho o debian jessie no OrangePi UPD: stretch, exim é executado como Debian-exim e mesmo assim houve a invasão, apagou o cron e outras coisas.
UPD 15: ao mudar para um servidor limpo a partir de um comprometido, 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 tudo que pode conter comandos maliciosos (por exemplo, no MySQL isso pode ser CREATE TRIGGER ou CREATE EVENT). Além disso, não se esqueça de arquivos .html, .js, .php, .py e outros arquivos públicos (idealmente, esses arquivos, assim como outros dados, devem ser restaurados de um armazenamento local ou de outra fonte confiável).
UPD 16: e : no sistema, nas portas estava uma versão de exim, mas na verdade estava sendo executada outra.
Então todos depois da atualização, devem se certificar de que estão usando exatamente a nova versão!
exim --versionEspecificamente com a situação deles, nós resolvemos juntos.
O servidor estava usando DirectAdmin e tinha seu antigo pacote da_exim (uma versão antiga, sem vulnerabilidade).
Com isso, foi instalada uma versão mais nova do Exim, já vulnerável, utilizando o gerenciador de pacotes custombuild do DirectAdmin.
Especificamente nesta situação, a atualização através do custombuild também ajudou.
Não se esqueçam de fazer backups antes de tais experimentos e também verifiquem se todos os processos do Exim da versão antiga foram parados antes/depois da atualização. e não ficaram "presos" na memória.
Fonte: habr.com
