El 10 de març al vespre, el servei d'assistència de Mail.ru va començar a rebre queixes dels usuaris sobre la impossibilitat de connectar-se als servidors IMAP/SMTP de Mail.ru mitjançant programes de correu electrònic. Al mateix temps, algunes connexions no van passar, i algunes mostren un error de certificat. L'error és causat perquè el "servidor" emet un certificat TLS autofirmat.
Durant dos dies, es van rebre més de 10 queixes d'usuaris d'una gran varietat de xarxes i amb una varietat de dispositius, cosa que va fer poc probable que el problema estigués a la xarxa d'un sol proveïdor. Una anàlisi més detallada del problema va revelar que el servidor imap.mail.ru (així com altres servidors i serveis de correu) s'està substituint a nivell de DNS. A més, amb l'ajuda activa dels nostres usuaris, vam trobar que el motiu era una entrada incorrecta a la memòria cau del seu encaminador, que també és un solucionador de DNS local, i que en molts (però no tots) els casos va resultar ser el MikroTik. dispositiu, molt popular en petites xarxes corporatives i de petits proveïdors d'Internet.
Quin és el problema
Al setembre de 2019, investigadors diverses vulnerabilitats a MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), que van permetre un atac d'enverinament de la memòria cau DNS, és a dir. la capacitat de falsificar els registres DNS a la memòria cau DNS de l'encaminador, i CVE-2019-3978 permet a l'atacant no esperar que algú de la xarxa interna sol·liciti una entrada al seu servidor DNS per enverinar la memòria cau de resolució, sinó iniciar-lo. una sol·licitud a través del port 8291 (UDP i TCP). La vulnerabilitat va ser arreglada per MikroTik en versions de RouterOS 6.45.7 (estable) i 6.44.6 (a llarg termini) el 28 d'octubre de 2019, però segons La majoria dels usuaris no tenen instal·lats pedaços actualment.
És obvi que aquest problema s'està explotant activament "en directe".
Per què és perillós
Un atacant pot falsificar el registre DNS de qualsevol host al qual accedeixi un usuari a la xarxa interna, interceptant així el trànsit. Si es transmet informació sensible sense xifratge (per exemple, a http:// sense TLS) o l'usuari accepta acceptar un certificat fals, l'atacant pot obtenir totes les dades que s'enviïn a través de la connexió, com ara un inici de sessió o una contrasenya. Malauradament, la pràctica demostra que si un usuari té l'oportunitat d'acceptar un certificat fals, l'aprofitarà.
Per què els servidors SMTP i IMAP i què ha salvat els usuaris
Per què els atacants van intentar interceptar el trànsit SMTP/IMAP de les aplicacions de correu electrònic, i no el trànsit web, encara que la majoria dels usuaris accedeixen al seu correu mitjançant el navegador HTTPS?
No tots els programes de correu electrònic que funcionen mitjançant SMTP i IMAP/POP3 protegeixen l'usuari d'errors, impedint-li l'enviament d'inici de sessió i contrasenya a través d'una connexió no segura o compromesa, encara que segons l'estàndard. , adoptat el 2018 (i implementat a Mail.ru molt abans), han de protegir l'usuari de la intercepció de contrasenyes mitjançant qualsevol connexió no segura. A més, el protocol OAuth s'utilitza molt poques vegades als clients de correu electrònic (és compatible amb els servidors de correu Mail.ru) i sense ell, l'inici de sessió i la contrasenya es transmeten a cada sessió.
Els navegadors poden estar una mica més protegits contra els atacs Man-in-the-Middle. En tots els dominis crítics de mail.ru, a més d'HTTPS, la política HSTS (HTTP strict transport security) està activada. Amb HSTS habilitat, un navegador modern no ofereix a l'usuari una opció fàcil d'acceptar un certificat fals, encara que l'usuari ho vulgui. A més d'HSTS, els usuaris es van salvar pel fet que des del 2017, els servidors SMTP, IMAP i POP3 de Mail.ru prohibeixen la transferència de contrasenyes a través d'una connexió no segura, tots els nostres usuaris van utilitzar TLS per accedir a través d'SMTP, POP3 i IMAP, i per tant, l'inici de sessió i la contrasenya només poden interceptar-se si el mateix usuari accepta acceptar el certificat falsificat.
Per als usuaris mòbils, sempre recomanem utilitzar les aplicacions Mail.ru per accedir al correu, perquè... treballar amb correu en ells és més segur que en navegadors o clients SMTP/IMAP integrats.
Què fer?
Cal actualitzar el microprogramari MikroTik RouterOS a una versió segura. Si per algun motiu això no és possible, cal filtrar el trànsit al port 8291 (tcp i udp), això complicarà l'explotació del problema, encara que no eliminarà la possibilitat d'injecció passiva a la memòria cau DNS. Els ISP haurien de filtrar aquest port a les seves xarxes per protegir els usuaris corporatius.
Tots els usuaris que hagin acceptat un certificat substituït haurien de canviar urgentment la contrasenya del correu electrònic i altres serveis per als quals s'ha acceptat aquest certificat. Per la nostra banda, avisarem els usuaris que accedeixin al correu mitjançant dispositius vulnerables.
PS També hi ha una vulnerabilitat relacionada que es descriu a la publicació "".
Font: www.habr.com