Na noite de 10 de março, o serviço de suporte Mail.ru começou a receber reclamações de usuários sobre a incapacidade de se conectar aos servidores IMAP/SMTP Mail.ru por meio de programas de e-mail. Ao mesmo tempo, algumas conexões não foram realizadas e algumas mostram um erro de certificado. O erro é causado pelo “servidor” que emite um certificado TLS autoassinado.
Em dois dias, mais de 10 reclamações chegaram de usuários em diversas redes e com diversos dispositivos, tornando improvável que o problema estivesse na rede de qualquer provedor. Uma análise mais detalhada do problema revelou que o servidor imap.mail.ru (assim como outros servidores e serviços de correio) está sendo substituído no nível DNS. Além disso, com a ajuda ativa de nossos usuários, descobrimos que o motivo era uma entrada incorreta no cache de seu roteador, que também é um resolvedor DNS local, e que em muitos (mas não todos) casos acabou sendo o MikroTik dispositivo, muito popular em pequenas redes corporativas e de pequenos provedores de Internet.
Qual é o problema
Em setembro de 2019, pesquisadores várias vulnerabilidades no MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), que permitiram um ataque de envenenamento de cache DNS, ou seja, a capacidade de falsificar registros DNS no cache DNS do roteador, e CVE-2019-3978 permite que o invasor não espere que alguém da rede interna solicite uma entrada em seu servidor DNS para envenenar o cache do resolvedor, mas para iniciar tal ele mesmo uma solicitação através da porta 8291 (UDP e TCP). A vulnerabilidade foi corrigida pelo MikroTik nas versões do RouterOS 6.45.7 (estável) e 6.44.6 (longo prazo) em 28 de outubro de 2019, mas de acordo com A maioria dos usuários ainda não instalou patches.
É óbvio que este problema está agora a ser explorado activamente “ao vivo”.
Por que é perigoso
Um invasor pode falsificar o registro DNS de qualquer host acessado por um usuário na rede interna, interceptando assim o tráfego para ele. Se informações confidenciais forem transmitidas sem criptografia (por exemplo, por http:// sem TLS) ou se o usuário concordar em aceitar um certificado falso, o invasor poderá obter todos os dados que são enviados por meio da conexão, como login ou senha. Infelizmente, a prática mostra que se um usuário tiver a oportunidade de aceitar um certificado falso, ele tirará vantagem disso.
Por que servidores SMTP e IMAP e o que salvou os usuários
Por que os invasores tentaram interceptar o tráfego SMTP/IMAP de aplicativos de e-mail, e não o tráfego da Web, embora a maioria dos usuários acesse seus e-mails por meio do navegador HTTPS?
Nem todos os programas de e-mail que funcionam via SMTP e IMAP/POP3 protegem o usuário de erros, impedindo-o de enviar login e senha através de uma conexão insegura ou comprometida, embora de acordo com o padrão , adotados em 2018 (e implementados no Mail.ru muito antes), eles devem proteger o usuário contra interceptação de senha por meio de qualquer conexão não segura. Além disso, o protocolo OAuth raramente é usado em clientes de e-mail (é suportado pelos servidores de e-mail Mail.ru) e, sem ele, o login e a senha são transmitidos em cada sessão.
Os navegadores podem estar um pouco mais protegidos contra ataques Man-in-the-Middle. Em todos os domínios críticos do mail.ru, além do HTTPS, a política HSTS (HTTP strict transport security) está habilitada. Com o HSTS habilitado, um navegador moderno não oferece ao usuário uma opção fácil de aceitar um certificado falso, mesmo que o usuário queira. Além do HSTS, os usuários foram salvos pelo fato de que desde 2017 os servidores SMTP, IMAP e POP3 do Mail.ru proíbem a transferência de senhas em uma conexão não segura, todos os nossos usuários usaram TLS para acesso via SMTP, POP3 e IMAP, e Portanto, o login e a senha só podem ser interceptados se o próprio usuário concordar em aceitar o certificado falsificado.
Para usuários móveis, sempre recomendamos o uso dos aplicativos Mail.ru para acessar o correio, porque... trabalhar com e-mail neles é mais seguro do que em navegadores ou clientes SMTP/IMAP integrados.
O que fazer
É necessário atualizar o firmware do MikroTik RouterOS para uma versão segura. Se por algum motivo isso não for possível, é necessário filtrar o tráfego na porta 8291 (tcp e udp), isso complicará a exploração do problema, embora não elimine a possibilidade de injeção passiva no cache DNS. Os ISPs devem filtrar esta porta em suas redes para proteger os usuários corporativos.
Todos os usuários que aceitaram um certificado substituído deverão alterar urgentemente a senha de e-mail e demais serviços para os quais este certificado foi aceito. De nossa parte, notificaremos os usuários que acessarem e-mails através de dispositivos vulneráveis.
PS Há também uma vulnerabilidade relacionada descrita na postagem "".
Fonte: habr.com