Segurança > Vulnerabilidade crítica do Exim CVE-2019-10149

943 Views

Tempo de leitura: 2 Minutos 

Recentemente uma grave vulnerabilidade no Exim expôs milhares de servidores à sérios riscos de segurança. A falha está documentada no CVE-2019-10149.

A criticidade se dá ao fato do invasor ganhar acesso root no servidor.

Correção

Para corrigir o problema, basta atualizar o pacote do Exim. E para saber se está seguro, pode-se rodar o seguinte comando:

Redhat e Redhat-like

rpm -q --changelog exim | grep CVE-2019-10149

Debian e Debian-like

apt-get changelog exim | grep CVE-2019-10149

O Malware

O malware disseminado no sistema dá um certo trabalho pra ser removido, pois ele se espalha e se regenera caso simplesmente removamos seus arquivos. A medida que removemos seus arquivos, outros arquivos do malware os recriam em poucos segundos. Ou seja, o malware se regenera, digamos assim.

Além disso, há cronjobs que puxam um script que deploya o malware. Tudo muito organizado para não deixar rastros, seja ele em disco, histórico ou processos.

Falando em processos, alguns são criados diretamente no /proc, atuando como orquestrador. Como disse, bem organizado.

Para eliminá-lo, deve-se remover todos arquivos do malware e imediatamente rebootar o sistema.

Criei o seguinte FIX que me atendeu super bem, e compartilho aqui com o amigo leitor para possa ajudá-lo.

Passo 1

Primeiro, certifique-se de ter acesso root ao sistema. Se não tiver, sugiro que reinicie seu servidor e troque a senha via single-user. Nos links a seguir há dois how-to para fazê-lo em RHEL7 e em sistema Linux diversos, respectivamente:

Troubleshooting – Quebrando senha de root no RHEL 7 (Redhat Enterprise Linux)

Artigos > Redefinindo a senha de root do Linux

Passo 2

Todos arquivos do malware devem ser removidos simultâneamente e, imediatamente, rebootar o sistema.

Mas antes, verifique se seu acesso ao sistema se dá via SSH. Se sim, o primeiro passo será alocar sua chave SSH em um local seguro e com um nome diferente de `authorized_keys` ou `authorized_keys2`. Feito isso, deixe pronto o comando `mv $CAMINHO_DA_CHAVE /root/.ssh/authorized_keys2`, mas não o execute ainda, pois o malware removerá o arquivo.

Tudo pronto, podemos seguir.

Como disse antes, todos arquivos devem ser removidos. Por isso, deve-se rodar o comando abaixo. Observe que o servidor será reiniciado.

Antes de fazê-lo, sugiro que leia o comando, o entenda e veja se é aplicável para você. Somente então o execute.

Para quem acessa com chave SSH

rm -f /usr/bin/\[kthrotlds\] ; chattr -i /usr/local/bin/nptd; rm -f /usr/local/bin/nptd ; chattr -i /var/spool/cron/root ; rm -f /var/spool/cron/root ; chattr -i /etc/crontab ; rm -f /etc/crontab ; chattr -i /etc/cron.d/root ; rm -f /etc/cron.d/root ; chattr -i /root/.ssh/authorized_keys ; rm -f /root/.ssh/authorized_keys ; mv $CAMINHO_DA_CHAVE /root/.ssh/authorized_keys2 ; reboot

Para quem acessa sem chave SSH

rm -f /usr/bin/\[kthrotlds\] ; chattr -i /usr/local/bin/nptd; rm -f /usr/local/bin/nptd ; chattr -i /var/spool/cron/root ; rm -f /var/spool/cron/root ; chattr -i /etc/crontab ; rm -f /etc/crontab ; chattr -i /etc/cron.d/root ; rm -f /etc/cron.d/root ; chattr -i /root/.ssh/authorized_keys ; rm -f /root/.ssh/authorized_keys ; reboot

Observe que você deve atualizar o pacote do Exim para evitar que o problema volte a ocorrer. Do contrário, terá que fazer essa ação mais de uma vez.

Conclusão

Essa falha de segurança é realmente crítica, pois dá acesso root à terceiros. Manter seus sistemas atualizados é sempre uma ótima saída para esse tipo de situação.