Mais recentemente, no início do verão, houve pedidos generalizados para que o Exim fosse atualizado para a versão 4.92 devido à vulnerabilidade CVE-2019-10149 (). E recentemente descobriu-se que o malware Sustes decidiu tirar vantagem desta vulnerabilidade.
Agora todos aqueles que atualizaram com urgência podem “alegrar-se” novamente: em 21 de julho de 2019, o pesquisador Zerons descobriu uma vulnerabilidade crítica em Agente Exim Mail Transfer (MTA) ao usar TLS para versões de 4.80 para 4.92.1 inclusivo, permitindo acesso remoto executar código com direitos privilegiados ().
Vulnerabilidade
A vulnerabilidade está presente ao usar as bibliotecas GnuTLS e OpenSSL ao estabelecer uma conexão TLS segura.
Segundo o desenvolvedor Heiko Schlittermann, o arquivo de configuração do Exim não usa TLS por padrão, mas muitas distribuições criam os certificados necessários durante a instalação e permitem uma conexão segura. Também versões mais recentes do Exim instalam a opção tls_advertise_hosts=* e gerar os certificados necessários.
depende da configuração. A maioria das distros habilita-o por padrão, mas o Exim precisa de um certificado+chave para funcionar como um servidor TLS. Provavelmente as Distros criam um certificado durante a configuração. Os Exims mais recentes têm a opção tls_advertise_hosts padronizada como "*" e criam um certificado autoassinado, se nenhum for fornecido.
A vulnerabilidade em si reside no processamento incorreto de SNI (Server Name Indication, uma tecnologia introduzida em 2003 na RFC 3546 para um cliente solicitar o certificado correto para um nome de domínio, ) durante um handshake TLS. Um invasor só precisa enviar um SNI terminando com uma barra invertida ("") e um caractere nulo (" ").
Pesquisadores da Qualys descobriram um bug na função string_printing(tls_in.sni), que envolve escape incorreto de “”. Como resultado, a barra invertida é gravada sem escape no arquivo de cabeçalho do spool de impressão. Este arquivo é então lido com direitos privilegiados pela função spool_read_header(), o que leva ao heap overflow.
É importante notar que, no momento, os desenvolvedores do Exim criaram um PoC de vulnerabilidades com a execução de comandos em um servidor remoto vulnerável, mas ainda não está disponível publicamente. Pela facilidade de exploração do bug, é apenas uma questão de tempo, e bastante curto.
Um estudo mais detalhado da Qualys pode ser encontrado .
Usando SNI em TLS
Número de servidores públicos potencialmente vulneráveis
De acordo com estatísticas de um grande provedor de hospedagem E-Soft Inc. a partir de 1º de setembro, nos servidores alugados, a versão 4.92 é usada em mais de 70% dos hosts.
Versão
Número de servidores
Por cento
4.92.1
6471
1.28%
4.92
376436
74.22%
4.91
58179
11.47%
4.9
5732
1.13%
4.89
10700
2.11%
4.87
14177
2.80%
4.84
9937
1.96%
Outras versões
25568
5.04%
Estatísticas da empresa E-Soft Inc
Se você usa um mecanismo de pesquisa , então de 5,250,000 no banco de dados do servidor:
- cerca de 3,500,000 usam Exim 4.92 (cerca de 1,380,000 usam SSL/TLS);
- mais de 74,000 usando 4.92.1 (cerca de 25,000 usando SSL/TLS).
Assim, o número de servidores potencialmente vulneráveis Exim publicamente conhecidos e acessíveis é de cerca de 1.5M.
Procure servidores Exim em Shodan
Proteção
- A opção mais simples, mas não recomendada, é não usar TLS, o que resultará no encaminhamento de mensagens de e-mail de forma clara.
- Para evitar a exploração da vulnerabilidade, seria mais preferível atualizar para a versão .
- Se for impossível atualizar ou instalar uma versão corrigida, você pode definir uma ACL na configuração do Exim para a opção acl_smtp_mail com as seguintes regras:
# to be prepended to your mail acl (the ACL referenced # by the acl_smtp_mail main config option) deny condition = ${if eq{}{${substr{-1}{1}{$tls_in_sni}}}} deny condition = ${if eq{}{${substr{-1}{1}{$tls_in_peerdn}}}}
Fonte: habr.com