Op de avond van 10 maart begon de ondersteuningsdienst van Mail.ru klachten te ontvangen van gebruikers over het onvermogen om via e-mailprogramma's verbinding te maken met Mail.ru IMAP/SMTP-servers. Tegelijkertijd zijn sommige verbindingen niet gelukt en sommige vertonen een certificaatfout. De fout wordt veroorzaakt doordat de "server" een zelfondertekend TLS-certificaat uitgeeft.
In twee dagen tijd kwamen ruim tien klachten binnen van gebruikers op verschillende netwerken en met uiteenlopende apparaten, waardoor het onwaarschijnlijk is dat het probleem in het netwerk van één aanbieder zat. Uit een meer gedetailleerde analyse van het probleem bleek dat de imap.mail.ru-server (evenals andere mailservers en services) op DNS-niveau wordt vervangen. Verder ontdekten we, met de actieve hulp van onze gebruikers, dat de reden een onjuiste invoer in de cache van hun router was, die ook een lokale DNS-resolver is, en die in veel (maar niet alle) gevallen de MikroTik bleek te zijn apparaat, erg populair in kleine bedrijfsnetwerken en bij kleine internetproviders.
Wat is het probleem
In september 2019 onderzoekers verschillende kwetsbaarheden in MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), die een DNS-cachevergiftigingsaanval mogelijk maakten, d.w.z. de mogelijkheid om DNS-records in de DNS-cache van de router te spoofen, en CVE-2019-3978 stelt de aanvaller in staat niet te wachten tot iemand van het interne netwerk een invoer op zijn DNS-server aanvraagt om de cache van de oplosser te vergiftigen, maar om dergelijke zelf een aanvraag indienen via poort 8291 (UDP en TCP). De kwetsbaarheid werd op 6.45.7 oktober 6.44.6 door MikroTik opgelost in de versies van RouterOS 28 (stabiel) en 2019 (lange termijn), maar volgens De meeste gebruikers hebben momenteel geen patches geïnstalleerd.
Het is duidelijk dat dit probleem nu actief “live” wordt uitgebuit.
Waarom is het gevaarlijk
Een aanvaller kan het DNS-record vervalsen van elke host waartoe een gebruiker op het interne netwerk toegang heeft, en daarmee verkeer ernaartoe onderscheppen. Als gevoelige informatie zonder encryptie wordt verzonden (bijvoorbeeld via http:// zonder TLS) of als de gebruiker ermee instemt een nepcertificaat te accepteren, kan de aanvaller alle gegevens bemachtigen die via de verbinding worden verzonden, zoals een login of wachtwoord. Helaas leert de praktijk dat als een gebruiker de mogelijkheid heeft om een nepcertificaat te accepteren, hij daar misbruik van zal maken.
Waarom SMTP- en IMAP-servers en wat gebruikers heeft gered
Waarom probeerden de aanvallers het SMTP/IMAP-verkeer van e-mailapplicaties te onderscheppen en niet het webverkeer, hoewel de meeste gebruikers hun e-mail benaderen via een HTTPS-browser?
Niet alle e-mailprogramma's die via SMTP en IMAP/POP3 werken, beschermen de gebruiker tegen fouten, waardoor hij de login en het wachtwoord niet via een onbeveiligde of gecompromitteerde verbinding kan verzenden, hoewel dit volgens de standaard is , overgenomen in 2018 (en veel eerder geïmplementeerd in Mail.ru), moeten ze de gebruiker beschermen tegen het onderscheppen van wachtwoorden via elke onbeveiligde verbinding. Bovendien wordt het OAuth-protocol zeer zelden gebruikt in e-mailclients (het wordt ondersteund door Mail.ru-mailservers), en zonder dit protocol worden de login en het wachtwoord tijdens elke sessie verzonden.
Browsers zijn mogelijk iets beter beschermd tegen Man-in-the-Middle-aanvallen. Op alle kritieke domeinen van mail.ru is naast HTTPS het HSTS-beleid (HTTP strict transport security) ingeschakeld. Als HSTS is ingeschakeld, biedt een moderne browser de gebruiker geen gemakkelijke optie om een nepcertificaat te accepteren, zelfs als de gebruiker dat wil. Naast HSTS werden gebruikers gered door het feit dat SMTP-, IMAP- en POP2017-servers van Mail.ru sinds 3 de overdracht van wachtwoorden via een onbeveiligde verbinding verbieden, al onze gebruikers TLS gebruikten voor toegang via SMTP, POP3 en IMAP, en daarom kunnen login en wachtwoord alleen worden onderschept als de gebruiker er zelf mee instemt het vervalste certificaat te accepteren.
Voor mobiele gebruikers raden we altijd aan om Mail.ru-applicaties te gebruiken om toegang te krijgen tot e-mail, omdat... het werken met e-mail daarin is veiliger dan in browsers of ingebouwde SMTP/IMAP-clients.
Wat te doen
Het is noodzakelijk om de MikroTik RouterOS-firmware bij te werken naar een veilige versie. Als dit om de een of andere reden niet mogelijk is, is het noodzakelijk om verkeer op poort 8291 (tcp en udp) te filteren, dit zal de exploitatie van het probleem bemoeilijken, hoewel het de mogelijkheid van passieve injectie in de DNS-cache niet elimineert. ISP's moeten deze poort op hun netwerken filteren om zakelijke gebruikers te beschermen.
Alle gebruikers die een vervangend certificaat hebben geaccepteerd, moeten dringend het wachtwoord wijzigen voor e-mail en andere diensten waarvoor dit certificaat is geaccepteerd. Van onze kant zullen we gebruikers die via kwetsbare apparaten toegang hebben tot e-mail, hiervan op de hoogte stellen.
PS Er wordt ook een gerelateerde kwetsbaarheid beschreven in het bericht "".
Bron: www.habr.com