Den Owend vum 10. Mäerz huet de Mail.ru Support Service ugefaang Reklamatioune vu Benotzer iwwer d'Onméiglechkeet ze kréien fir mat Mail.ru IMAP / SMTP Serveren iwwer E-Mail Programmer ze verbannen. Zur selwechter Zäit sinn e puer Verbindungen net duerchgaang, an e puer weisen en Zertifikatfehler. De Feeler gëtt verursaacht duerch de "Server" deen e selbst ënnerschriwwenen TLS Zertifikat ausgëtt.
Iwwer zwee Deeg koumen méi wéi 10 Reklamatioune vu Benotzer op enger grousser Varietéit vun Netzwierker a mat verschiddenen Apparater eran, wat et onwahrscheinlech mécht datt de Problem am Netz vun engem Provider war. Eng méi detailléiert Analyse vum Problem huet opgedeckt datt den imap.mail.ru Server (wéi och aner Mailserveren a Servicer) um DNS Niveau ersat gëtt. Weider, mat der aktiver Hëllef vun eise Benotzer, hu mir festgestallt datt de Grond eng falsch Entrée am Cache vun hirem Router war, deen och e lokalen DNS-Resolver ass, an deen a ville (awer net all) Fäll de MikroTik war. Apparat, ganz populär a klenge Firmennetzwierker a vu klenge Internet Ubidder.
Wat ass de Problem
Am September 2019, Fuerscher verschidde Schwachstelle am MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), wat en DNS Cache Vergëftungattack erlaabt huet, d.h. d'Kapazitéit fir DNS-Records am DNS-Cache vum Router ze spooféieren, an den CVE-2019-3978 erlaabt den Ugräifer net op een aus dem internen Netzwierk ze waarden fir en Entrée op sengem DNS-Server ze froen fir de Resolver-Cache ze vergëften, awer fir esou ze initiéieren eng Demande selwer duerch den Hafen 8291 (UDP an TCP). D'Vulnerabilitéit gouf vum MikroTik a Versioune vu RouterOS 6.45.7 (stabil) a 6.44.6 (laangfristeg) den 28. Oktober 2019 fixéiert, awer laut Déi meescht Benotzer hunn de Moment keng Patches installéiert.
Et ass evident datt dëse Problem elo aktiv "live" exploitéiert gëtt.
Firwat ass et geféierlech?
En Ugräifer kann den DNS-Rekord vun all Host, dee vun engem Benotzer am internen Netz zougänglech ass, späicheren, an doduerch den Traffic offangen. Wann sensibel Informatioun ouni Verschlësselung iwwerdroe gëtt (zum Beispill iwwer http:// ouni TLS) oder de Benotzer averstanen ass e gefälschte Zertifika ze akzeptéieren, kann den Ugräifer all d'Donnéeë kréien, déi duerch d'Verbindung geschéckt ginn, wéi e Login oder Passwuert. Leider weist d'Praxis datt wann e Benotzer d'Méiglechkeet huet e gefälschte Certificat ze akzeptéieren, hie profitéiert dovun.
Firwat SMTP an IMAP Serveren, a wat Benotzer gerett
Firwat hunn d'Attacker probéiert SMTP / IMAP Traffic vun E-Mail Uwendungen z'ënnerscheeden, an net de Webverkéier, obwuel déi meescht Benotzer op hir Mail iwwer HTTPS Browser zougräifen?
Net all E-Mail Programmer, déi iwwer SMTP an IMAP/POP3 schaffen, schützen de Benotzer vu Feeler, verhënnert datt hien de Login a Passwuert duerch eng onsécher oder kompromittéiert Verbindung verschéckt, obwuel no dem Standard , zréck an 2018 adoptéiert (a vill méi fréi an Mail.ru ëmgesat), mussen se de Benotzer aus Passwuert Offangen duerch all onsécher Verbindung schützen. Zousätzlech ass den OAuth Protokoll ganz selten an E-Mail Clienten benotzt (et gëtt vun Mail.ru Mail Serveren ënnerstëtzt), an ouni et ginn de Login a Passwuert an all Sessioun iwwerdroen.
Browser kënnen e bësse besser géint Man-in-the-Middle Attacke geschützt sinn. Op all mail.ru kritesch Domainen, zousätzlech zu HTTPS, ass d'HSTS (HTTP strict Transport Security) Politik aktivéiert. Mat HSTS aktivéiert gëtt e modernen Browser dem Benotzer keng einfach Optioun fir e gefälschte Zertifika ze akzeptéieren, och wann de Benotzer et wëllt. Zousätzlech zu HSTS goufen d'Benotzer gerett vun der Tatsaach datt zënter 2017 SMTP, IMAP a POP3 Server vu Mail.ru den Transfer vu Passwierder iwwer eng onsécher Verbindung verbidden, all eis Benotzer benotzt TLS fir Zougang iwwer SMTP, POP3 an IMAP, an dofir Login a Passwuert kënnen nëmmen ofgefaangen wann de Benotzer selwer averstanen der spoofed Zertifikat ze akzeptéieren.
Fir mobil Benotzer empfeelen mir ëmmer Mail.ru Uwendungen fir Zougang zu Mail ze benotzen, well ... mat Mail an hinnen ze schaffen ass méi sécher wéi a Browser oder agebaute SMTP/IMAP Clienten.
Wat maachen
Et ass néideg fir d'MikroTik RouterOS Firmware op eng sécher Versioun ze aktualiséieren. Wann aus irgendege Grënn dëst net méiglech ass, ass et néideg de Traffic op den Hafen 8291 ze filteren (tcp an udp), dëst wäert d'Ausbeutung vum Problem komplizéieren, obwuel et d'Méiglechkeet vu passiver Injektioun an den DNS Cache net eliminéiert. ISPs sollen dësen Hafen op hiren Netzwierker filteren fir Firmenbenotzer ze schützen.
All Benotzer, déi en ersat Zertifikat akzeptéiert hunn, sollten dréngend d'Passwuert fir E-Mail an aner Servicer änneren, fir déi dësen Zertifika akzeptéiert gouf. Fir eisen Deel wäerte mir d'Benotzer informéieren déi Zougang zu Mail iwwer vulnérabel Apparater kréien.
PS Et gëtt och eng verbonne Schwachstelle am Post beschriwwen "".
Source: will.com