Get best of the week

Actualice RouterOS en su MikroTik


En la tarde del 10 de marzo, el servicio de soporte Mail.ru comenzó a recibir quejas de los usuarios sobre la imposibilidad de conectarse a los servidores Mail.ru IMAP / SMTP a través de programas de correo electrónico. Al mismo tiempo, algunas de las conexiones no pasaron y algunas muestran un error de certificado. El error es causado por el hecho de que el "servidor" emite un certificado TLS autofirmado.
 

En dos días, más de 10 quejas llegaron de usuarios de una variedad de redes y con una variedad de dispositivos, lo que hizo improbable que un solo proveedor tuviera un problema en la red. Un análisis más detallado del problema reveló que hay una sustitución del servidor imap.mail.ru (así como de otros servidores y servicios de correo) a nivel DNS. Además, con la asistencia activa de nuestros usuarios, descubrimos que el motivo era una entrada incorrecta en la memoria caché de su enrutador, que en combinación es un solucionador de DNS local, y que en muchos casos (pero no en todos) resultó ser el dispositivo MikroTik, que es muy popular en redes corporativas pequeñas y en pequeños proveedores de internet.

Cuál es el problema


En septiembre de 2019, los investigadores encontraron varias vulnerabilidades en MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979) que permitieron el ataque de envenenamiento de caché DNS, es decir. la capacidad de falsificar registros DNS en la memoria caché DNS del enrutador, y CVE-2019-3978 permite que un atacante no espere a que alguien de la red interna solicite un registro en su servidor DNS para envenenar la memoria caché del resolutor, sino que inicie dicha solicitud 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 los estudios, la mayoría de los usuarios no han instalado parches en este momento.

Es obvio que ahora este problema está siendo explotado activamente "en vivo".

Porque es peligroso


Un atacante puede reemplazar 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 recibir todos los datos que se envían a través de la conexión, por ejemplo, inicio de sesión o contraseña. Desafortunadamente, la práctica muestra que si un usuario tiene la oportunidad de aceptar un certificado falso, lo usará.

Por qué servidores SMTP e IMAP, y qué salvaron a los usuarios


¿Por qué los atacantes intentaron interceptar con precisión el tráfico SMTP / IMAP de las aplicaciones de correo, y no el tráfico web, aunque la mayoría de los usuarios van al correo a través del navegador HTTPS?

No todos los programas de correo SMTP e IMAP / POP3 protegen al usuario de errores al no permitirle enviar un nombre de usuario y contraseña a través de una conexión insegura o comprometida, aunque de acuerdo con el estándar RFC 8314 adoptado en 2018 (e implementado en Mail.ru mucho antes), deben proteger al usuario de interceptar una contraseña a través de cualquier conexión insegura. Además, aunque el protocolo OAuth se usa muy raramente en clientes de correo (es compatible con los servidores de correo Mail.ru), sin él, el nombre de usuario y la contraseña se transmiten en cada sesión.

Los navegadores pueden estar ligeramente mejor protegidos de los ataques Man-in-the-Middle. En todos los dominios críticos de mail.ru, además de HTTPS, se incluye la política HSTS (seguridad estricta de transporte HTTP). Cuando HSTS está habilitado, un navegador moderno no le brinda al usuario una oportunidad simple de aceptar un certificado falso, incluso si el usuario lo desea. Además de HSTS, los usuarios se salvaron por el hecho de que desde 2017, los servidores Mail.ru SMTP, IMAP y POP3 prohíben la transmisión de contraseñas a través de una conexión insegura, todos nuestros usuarios usaron TLS para acceder a través de SMTP, POP3 e IMAP, y por lo tanto, pueden iniciar sesión y contraseña interceptar solo si el propio usuario acepta aceptar el certificado falsificado.

Para los usuarios móviles, siempre recomendamos usar las aplicaciones Mail.ru para acceder al correo, como trabajar con el correo en ellos es más seguro que en los navegadores o en los clientes SMTP / IMAP integrados.

Lo que debe hacerse


Debe 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 operación del problema, aunque no eliminará la posibilidad de inyección pasiva en la caché DNS. Los proveedores de servicios de Internet deben filtrar este puerto en sus redes para proteger a los usuarios corporativos. 

Todos los usuarios que aceptaron un certificado falsificado deben cambiar urgentemente la contraseña del correo electrónico y otros servicios para los que se aceptó este certificado. Por nuestra parte, notificaremos a los usuarios que ingresan el correo a través de dispositivos vulnerables.

PD: todavía hay una vulnerabilidad relacionada descrita en la publicaciónLukaSafonov" La vulnerabilidad de backport en RouterOS amenaza a cientos de miles de dispositivos ".

More articles:


All Articles