Na noite do 10 de marzo, o servizo de asistencia de Mail.ru comezou a recibir queixas dos usuarios sobre a imposibilidade de conectarse aos servidores IMAP/SMTP de Mail.ru mediante programas de correo electrónico. Ao mesmo tempo, algunhas conexións non pasaron e algunhas mostran un erro de certificado. O erro é causado polo "servidor" que emite un certificado TLS autoasinado.
En dous días, chegaron máis de 10 queixas de usuarios en varias redes e con diversos dispositivos, polo que é improbable que o problema estivese na rede dun único provedor. Unha análise máis detallada do problema revelou que o servidor imap.mail.ru (así como outros servidores e servizos de correo electrónico) está sendo substituído a nivel DNS. Ademais, coa axuda activa dos nosos usuarios, descubrimos que o motivo era unha entrada incorrecta na caché do seu enrutador, que tamén é un resolvedor de DNS local, e que en moitos (pero non todos) casos resultou ser o MikroTik. dispositivo, moi popular en pequenas redes corporativas e de pequenos provedores de Internet.
Cal é o problema
En setembro de 2019, investigadores varias vulnerabilidades en MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), que permitiron un ataque de envelenamento da caché de DNS, i.e. a capacidade de falsificar os rexistros DNS na caché DNS do enrutador, e CVE-2019-3978 permite ao atacante non esperar a que alguén da rede interna solicite unha entrada no seu servidor DNS para envelenar a caché do resolutor, senón que inicie dito. unha solicitude a través do porto 8291 (UDP e TCP). A vulnerabilidade foi corrixida por MikroTik nas versións de RouterOS 6.45.7 (estable) e 6.44.6 (a longo prazo) o 28 de outubro de 2019, pero segundo A maioría dos usuarios non teñen instalado parches actualmente.
É obvio que este problema agora está a ser explotado activamente "en vivo".
Por que é perigoso?
Un atacante pode falsificar o rexistro DNS de calquera host ao que acceda un usuario na rede interna, interceptando así o tráfico. Se se transmite información confidencial sen cifrado (por exemplo, a través de http:// sen TLS) ou o usuario acepta aceptar un certificado falso, o atacante pode obter todos os datos que se envían a través da conexión, como un inicio de sesión ou un contrasinal. Desafortunadamente, a práctica demostra que se un usuario ten a oportunidade de aceptar un certificado falso, aproveitará.
Por que os servidores SMTP e IMAP e que salvou aos usuarios
Por que os atacantes tentaron interceptar o tráfico SMTP/IMAP das aplicacións de correo electrónico, e non o tráfico web, aínda que a maioría dos usuarios acceden ao seu correo a través do navegador HTTPS?
Non todos os programas de correo electrónico que funcionan a través de SMTP e IMAP/POP3 protexen ao usuario de erros, impedíndolle o envío de login e contrasinal a través dunha conexión non segura ou comprometida, aínda que segundo o estándar. , adoptado en 2018 (e implementado en Mail.ru moito antes), deben protexer ao usuario da interceptación do contrasinal a través de calquera conexión non segura. Ademais, o protocolo OAuth úsase moi raramente nos clientes de correo electrónico (é compatible cos servidores de correo de Mail.ru) e sen el, o inicio de sesión e o contrasinal transmítense en cada sesión.
Os navegadores poden estar un pouco mellor protexidos contra os ataques de Man-in-the-Middle. En todos os dominios críticos de mail.ru, ademais de HTTPS, está activada a política HSTS (seguridade de transporte estrita HTTP). Co HSTS activado, un navegador moderno non ofrece ao usuario unha opción sinxela para aceptar un certificado falso, aínda que o queira. Ademais de HSTS, os usuarios foron salvados polo feito de que desde 2017, os servidores SMTP, IMAP e POP3 de Mail.ru prohiben a transferencia de contrasinais a través dunha conexión non segura, todos os nosos usuarios utilizaron TLS para o acceso a través de SMTP, POP3 e IMAP, e polo tanto, o inicio de sesión e o contrasinal só poden interceptar se o propio usuario acepta aceptar o certificado falsificado.
Para os usuarios móbiles, sempre recomendamos usar as aplicacións Mail.ru para acceder ao correo, porque... traballar con correo neles é máis seguro que en navegadores ou clientes SMTP/IMAP integrados.
Que facer
É necesario actualizar o firmware de MikroTik RouterOS a unha versión segura. Se por algún motivo non é posible, é necesario filtrar o tráfico no porto 8291 (tcp e udp), isto complicará a explotación do problema, aínda que non eliminará a posibilidade de inxección pasiva na caché DNS. Os ISP deberían filtrar este porto nas súas redes para protexer aos usuarios corporativos.
Todos os usuarios que aceptaron un certificado substituído deben cambiar urxentemente o contrasinal do correo electrónico e doutros servizos para os que se aceptou este certificado. Pola nosa banda, avisaremos aos usuarios que accedan ao correo a través de dispositivos vulnerables.
PS Tamén hai unha vulnerabilidade relacionada descrita na publicación "".
Fonte: www.habr.com