Na noite de 10 de março, o suporte da Mail.ru começou a receber reclamações de usuários sobre a impossibilidade de se conectar aos servidores IMAP/SMTP da Mail.ru através de programas de email. Enquanto algumas conexões não eram bem-sucedidas, outras mostravam erro de certificado. O erro foi causado pelo fato de que o "servidor" estava entregando um certificado TLS autoassinado.
Em dois dias, mais de 10 reclamações de usuários de diversas redes e com diferentes dispositivos foram recebidas, o que tornava improvável que o problema estivesse na rede de um único provedor. Uma análise mais detalhada do problema revelou que havia uma substituição do servidor imap.mail.ru (assim como de outros servidores e serviços de email) em nível de DNS. Após a ajuda ativa de nossos usuários, descobrimos que a causa estava em uma entrada errada no cache do roteador deles, que também funciona como um resolvedor de DNS local, e que em muitos (mas não todos) os casos era um dispositivo MikroTik, muito popular em pequenas redes corporativas e entre 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 permitiam a realização de um ataque de envenenamento de cache DNS, ou seja, a possibilidade de substituir registros DNS no cache do roteador. O CVE-2019-3978 permite que o atacante não precise esperar que alguém da rede interna faça uma solicitação ao seu servidor DNS para envenenar o cache do resolvedor, podendo iniciar tal solicitação diretamente pela porta 8291 (UDP e TCP). A vulnerabilidade foi corrigida pela MikroTik nas versões RouterOS 6.45.7 (estável) e 6.44.6 (long-term) em 28 de outubro de 2019, entretanto, conforme a grande maioria dos usuários atualmente não instalou os patches.
É evidente que esta problema está sendo explorado ativamente "ao vivo".
Quão perigoso isso é
O atacante pode substituir o registro DNS de qualquer host acessado pelo usuário da rede interna, interceptando assim o tráfego destinado a ele. Se informações sensíveis forem transmitidas sem criptografia (por exemplo, por http:// sem TLS) ou se o usuário concordar em aceitar um certificado falso, o atacante pode obter todos os dados enviados através da conexão, como login ou senha. Infelizmente, a prática mostra que, se o usuário tem a chance de aceitar um certificado falso, ele provavelmente o fará.
Por que os servidores SMTP e IMAP são importantes e o que protege os usuários
Por que os atacantes tentaram interceptar especificamente o tráfego SMTP/IMAP de aplicativos de email, e não o tráfego web, mesmo que a maior parte dos usuários acesse o email por meio de navegadores via HTTPS?
Nem todos os programas de email que funcionam com SMTP e IMAP/POP3 protegem o usuário de erros, permitindo que ele envie login e senha através de uma conexão insegura ou comprometida, apesar de, de acordo com o padrão , adotado em 2018 (e implementado no Mail.ru muito antes), eles devem proteger o usuário contra a captura da senha através de qualquer conexão desprotegida. Além disso, enquanto o protocolo OAuth ainda é raramente utilizado em clientes de email (ele é suportado pelos servidores de email do Mail.ru), sem ele, o login e a senha são transmitidos em cada sessão.
Navegadores podem ser 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) foi ativada. Com o HSTS ativado, navegadores modernos não dão ao usuário a oportunidade de aceitar um certificado falso, mesmo que o usuário deseje. Além do HSTS, os usuários foram protegidos pelo fato de que, desde 2017, os servidores SMTP, IMAP e POP3 do Mail.ru proíbem a transmissão de senhas através de conexões não protegidas; todos os nossos usuários usaram TLS para acesso via SMTP, POP3 e IMAP, portanto, o login e a senha só podem ser capturados se o usuário mesmo aceitar um certificado modificado.
Para usuários móveis, sempre recomendamos o uso do aplicativo Mail.ru para acessar o email, pois trabalhar com email nele é mais seguro do que em navegadores ou em clientes SMTP/IMAP integrados.
O que precisa ser feito
É necessário atualizar o firmware do MikroTik RouterOS para uma versão segura. Se, por algum motivo, isso não for possível, é preciso filtrar o tráfego pela porta 8291 (tcp e udp), o que dificultará a exploração do problema, embora não elimine a possibilidade de injeção passiva no cache DNS. Os provedores de internet devem filtrar esta porta em suas redes para proteger os usuários corporativos.
Todos os usuários que aceitaram o certificado comprometido devem urgentemente trocar a senha de e-mail e de outros serviços para os quais esse certificado foi aceito. Da nossa parte, iremos avisar os usuários que acessam o e-mail através de dispositivos vulneráveis.
P.S. Há uma vulnerabilidade relacionada, conforme descrito no post "".
Fonte: habr.com
