En la tarde del 10 de marzo, el servicio de soporte de Mail.ru comenzó a recibir quejas de los usuarios sobre la imposibilidad de conectarse a los servidores IMAP/SMTP de Mail.ru a través de programas de correo electrónico. Al mismo tiempo, algunas conexiones no se realizaron y algunas muestran un error de certificado. El error se debe a que el "servidor" emite un certificado TLS autofirmado.
En dos días, llegaron más de 10 quejas de usuarios en una variedad de redes y con una variedad de dispositivos, por lo que era poco probable que el problema estuviera en la red de algún proveedor. Un análisis más detallado del problema reveló que el servidor imap.mail.ru (así como otros servidores y servicios de correo) está siendo reemplazado a nivel DNS. Además, con la ayuda activa de nuestros usuarios, descubrimos que el motivo era una entrada incorrecta en el caché de su enrutador, que también es un solucionador de DNS local, y que en muchos (pero no en todos) los casos resultó ser el MikroTik. dispositivo, muy popular en pequeñas redes corporativas y de pequeños proveedores de Internet.
Cual es el problema
En septiembre de 2019, los investigadores varias vulnerabilidades en MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), que permitieron un ataque de envenenamiento de la caché de DNS, es decir. la capacidad de falsificar registros DNS en la caché DNS del enrutador, y CVE-2019-3978 permite al atacante no esperar a que alguien de la red interna solicite una entrada en su servidor DNS para envenenar la caché de resolución, sino iniciar dicha una solicitud él mismo a través del puerto 8291 (UDP y TCP). MikroTik solucionó la vulnerabilidad en las versiones de RouterOS 6.45.7 (estable) y 6.44.6 (a largo plazo) el 28 de octubre de 2019, pero según La mayoría de los usuarios no han instalado parches actualmente.
Es evidente que este problema se está explotando activamente "en vivo".
¿Por qué es peligroso?
Un atacante puede falsificar el registro DNS de cualquier host al que acceda un usuario en la red interna, interceptando así el tráfico hacia él. Si la información confidencial se transmite sin cifrado (por ejemplo, a través de http:// sin TLS) o el usuario acepta aceptar un certificado falso, el atacante puede obtener todos los datos que se envían a través de la conexión, como un nombre de usuario o una contraseña. Desafortunadamente, la práctica demuestra que si un usuario tiene la oportunidad de aceptar un certificado falso, lo aprovechará.
Por qué los servidores SMTP e IMAP y qué salvaron a los usuarios
¿Por qué los atacantes intentaron interceptar el tráfico SMTP/IMAP de las aplicaciones de correo electrónico y no el tráfico web, aunque la mayoría de los usuarios acceden a su correo a través del navegador HTTPS?
No todos los programas de correo electrónico que funcionan vía SMTP e IMAP/POP3 protegen al usuario de errores, impidiéndole enviar su nombre de usuario y contraseña a través de una conexión no segura o comprometida, aunque según el estándar , adoptado en 2018 (e implementado en Mail.ru mucho antes), deben proteger al usuario de la interceptación de contraseñas a través de cualquier conexión no segura. Además, el protocolo OAuth se utiliza muy raramente en clientes de correo electrónico (es compatible con los servidores de correo 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 Man-in-the-Middle. En todos los dominios críticos de mail.ru, además de HTTPS, la política HSTS (seguridad de transporte estricta HTTP) está habilitada. Con HSTS habilitado, un navegador moderno no le brinda al usuario una opción fácil para aceptar un certificado falso, incluso si el usuario así lo desea. Además de HSTS, los usuarios se salvaron porque desde 2017 los servidores SMTP, IMAP y POP3 de Mail.ru prohíben la transferencia de contraseñas a través de una conexión no segura, todos nuestros usuarios utilizaron TLS para acceder a través de SMTP, POP3 e IMAP, y por lo tanto, el nombre de usuario y la contraseña sólo se pueden interceptar si el propio usuario acepta el certificado falsificado.
Para los usuarios de dispositivos móviles, siempre recomendamos utilizar las aplicaciones Mail.ru para acceder al correo, porque... trabajar con correo en ellos es más seguro que en navegadores o clientes SMTP/IMAP integrados.
Que 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 complicará la explotación del problema, aunque no eliminará la posibilidad de inyección pasiva en la caché DNS. Los ISP deberían filtrar este puerto en sus redes para proteger a los usuarios corporativos.
Todos los usuarios que aceptaron un certificado sustituido deben cambiar urgentemente la contraseña del correo electrónico y otros servicios para los cuales se aceptó este certificado. Por nuestra parte, avisaremos a los usuarios que accedan al correo a través de dispositivos vulnerables.
PD: También hay una vulnerabilidad relacionada descrita en la publicación. "".
Fuente: habr.com