En la noche del 10 de marzo, el servicio de soporte de Mail.ru comenzó a recibir quejas de usuarios sobre la imposibilidad de conectarse a los servidores IMAP/SMTP de Mail.ru a través de programas de correo. Algunos intentos de conexión fallaron y otros mostraron un error de certificado. El error fue causado por el hecho de que el «servidor» entrega un certificado TLS autofirmado.
En dos días, llegaron más de 10 quejas de usuarios de diversas redes y con diferentes dispositivos, lo que hacía poco probable que el problema fuera de un solo proveedor. Un análisis más detallado del problema reveló que se estaba sustituyendo el servidor imap.mail.ru (así como otros servidores y servicios de correo) a nivel de DNS. Luego, con la activa ayuda de nuestros usuarios, descubrimos que la causa se debía a una mala entrada en la caché de su enrutador, que también actuaba como un resolvedor DNS local, y en muchos (aunque no todos) casos resultó ser un dispositivo MikroTik, muy popular en pequeñas redes corporativas y entre pequeños proveedores de Internet.
¿Cuál es el problema?
En septiembre de 2019, investigadores varias vulnerabilidades en MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), que permitían realizar un ataque de envenenamiento de caché DNS, es decir, la posibilidad de sustituir registros DNS en la caché del enrutador. Además, CVE-2019-3978 permite al atacante no tener que esperar a que alguien de la red interna solicite un registro a su servidor DNS, sino iniciar esa solicitud por sí mismo a través del puerto 8291 (UDP y TCP). La vulnerabilidad fue corregida por MikroTik en las versiones de RouterOS 6.45.7 (estable) y 6.44.6 (a largo plazo) el 28 de octubre de 2019, sin embargo, según la gran mayoría de los usuarios en este momento no ha instalado las actualizaciones.
Es evidente que actualmente este problema se está explotando activamente "en vivo".
¿Por qué es peligroso?
Un atacante puede sustituir el registro DNS de cualquier host al que accede un usuario de la red interna, interceptando así el tráfico hacia él. Si se está transmitiendo información sensible sin cifrado (por ejemplo, por http:// sin TLS) o el usuario acepta un certificado falso, el atacante puede obtener todos los datos que se envían a través de la conexión, como el nombre de usuario o la contraseña. Lamentablemente, la práctica demuestra que si un usuario puede aceptar un certificado falso, lo hará.
¿Por qué específicamente los servidores SMTP e IMAP, y qué protegía a los usuarios?
¿Por qué los atacantes intentaron interceptar el tráfico SMTP/IMAP de las aplicaciones de correo y no el tráfico web, a pesar de que la mayoría de los usuarios accede al correo a través del navegador por HTTPS?
No todos los programas de correo que funcionan con SMTP e IMAP/POP3 protegen al usuario de errores, permitiendo que envíe su nombre de usuario y contraseña a través de una conexión insegura o comprometida, aunque según el estándar , adoptado en 2018 (y implementado en Mail.ru mucho antes), deberían proteger al usuario de la interceptación de la contraseña a través de cualquier conexión no segura. Además, el protocolo OAuth se utiliza muy raramente en los clientes de correo (aunque es soportado por los servidores de correo de Mail.ru), y sin él, el nombre de usuario y la contraseña se transmiten en cada sesión.
Los navegadores pueden estar un poco mejor protegidos contra ataques de Man-in-the-Middle. En todos los dominios críticos de mail.ru, además de HTTPS, se ha implementado la política HSTS (HTTP Strict Transport Security). Con HSTS activado, un navegador moderno no permite al usuario aceptar un certificado falso, incluso si el usuario lo desea. Aparte de HSTS, los usuarios se beneficiaron del hecho de que desde 2017 los servidores de SMTP, IMAP y POP3 de Mail.ru prohíben la transmisión de contraseñas a través de conexiones no seguras; todos nuestros usuarios utilizan TLS para acceder a través de SMTP, POP3 e IMAP, y por lo tanto, el nombre de usuario y la contraseña solo pueden ser interceptados si el propio usuario acepta aceptar un certificado falsificado.
Para los usuarios móviles, siempre recomendamos utilizar las aplicaciones de Mail.ru para acceder al correo, ya que es más seguro hacerlo a través de ellas que a través de navegadores o clientes SMTP/IMAP integrados.
Qué hacer
Es necesario actualizar el firmware de MikroTik RouterOS a una versión segura. Si por alguna razón esto no es posible, es necesario filtrar el tráfico en el puerto 8291 (TCP y UDP), esto dificultará la explotación del problema, aunque no eliminará la posibilidad de inyección pasiva en la caché DNS. Los proveedores de Internet deberían filtrar este puerto en sus redes para proteger a los usuarios corporativos.
Todos los usuarios que aceptaron el certificado falsificado deben cambiar urgentemente la contraseña de su correo electrónico y de otros servicios para los que se aceptó este certificado. Por nuestra parte, notificaremos a los usuarios que acceden al correo a través de dispositivos vulnerables.
P.D. También hay una vulnerabilidad relacionada, descrita en la publicación. "".
Fuente: habr.com
