PÄ kvÀllen den 10 mars började Mail.ru:s support ta emot klagomÄl frÄn anvÀndare om att de inte kunde ansluta till Mail.ru:s IMAP/SMTP-servrar via e-postprogram. Vissa anslutningar gick inte igenom, medan andra visade certifikatfel. Felet orsakades av att "servern" gav ett sjÀlvsignerat TLS-certifikat.
Â
Under tvÄ dagar kom det in över 10 klagomÄl frÄn anvÀndare frÄn olika nÀtverk och med olika enheter, vilket gjorde det osannolikt att problemet lÄg i nÄgon enskild leverantörs nÀtverk. En mer detaljerad granskning av problemet visade att det skedde en förfalskning av imap.mail.ru-servern (liksom andra e-postservrar och tjÀnster) pÄ DNS-nivÄ. Vid vidare undersökning, med aktiv hjÀlp frÄn vÄra anvÀndare, fann vi att orsaken lÄg i en felaktig post i cachen pÄ deras router, som ocksÄ fungerar som en lokal DNS-resolver, vilket i mÄnga (men inte alla) fall visade sig vara en MikroTik-enhet, mycket populÀr i smÄ företagsnÀtverk och hos smÄ internetleverantörer.
Vad Àr problemet
I september 2019 upptÀckte forskare flera sÄrbarheter i MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979) som möjliggjorde DNS cache poisoning-attacker, dvs. möjligheten att förfalska DNS-poster i routerns DNS-cache, dÀr CVE-2019-3978 tillÄter angriparen att initiera en sÄdan begÀran sjÀlv via port 8291 (UDP och TCP) utan att vÀnta pÄ att nÄgon i det interna nÀtverket ska begÀra en post pÄ sin DNS-server. SÄrbarheten ÄtgÀrdades av MikroTik i versionerna RouterOS 6.45.7 (stabil) och 6.44.6 (lÄngsiktig) den 28 oktober 2019, men enligt har majoriteten av anvÀndarna för nÀrvarande inte installerat patcharna.
Det Àr tydligt att detta problem för nÀrvarande utnyttjas aktivt "i realtid".
Vad Àr faran med detta
Angriparen kan förfalska DNS-posten för vilken vÀrd som helst som en anvÀndare i det interna nÀtverket kontaktar, och dÀrmed avlyssna trafiken till den. Om kÀnslig information överförs utan kryptering (t.ex. via http:// utan TLS) eller om anvÀndaren gÄr med pÄ att acceptera ett falskt certifikat kan angriparen fÄ tillgÄng till all data som skickas genom anslutningen, exempelvis inloggning eller lösenord. TyvÀrr visar erfarenheten att om anvÀndaren har möjlighet att acceptera ett falskt certifikat kommer de att utnyttja den möjligheten.
Varför just SMTP- och IMAP-servrar, och vad skyddade anvÀndarna
Varför försökte angriparna fÄnga SMTP/IMAP-trafik frÄn e-postapplikationer istÀllet för webbtrafik, Àven om en stor del av anvÀndarna kommer Ät e-posten via webblÀsare över HTTPS?
Inte alla e-postprogram som anvÀnder SMTP och IMAP/POP3 skyddar anvÀndaren frÄn fel, genom att förhindra att denne skickar inloggning och lösenord över en osÀker eller komprometterad anslutning, trots att standarden , antogs redan 2018 (och implementerades i Mail.ru mycket tidigare), borde de skydda anvÀndaren frÄn att lösenordet fÄngas över vilken osÀker anslutning som helst. Dessutom anvÀnds protokollet OAuth mycket sÀllan i e-postklienter (det stöds av Mail.ru:s e-postservrar), och utan det överförs inloggning och lösenord i varje session.
WebblÀsare kan vara nÄgot bÀttre skyddade mot Man-in-the-Middle-attacker. PÄ alla kritiska domÀner mail.ru har vi dessutom aktiverat HSTS-policy (HTTP strict transport security) utöver HTTPS. Med HSTS aktiverat ger moderna webblÀsare anvÀndaren inte en enkel möjlighet att acceptera ett falskt certifikat, Àven om anvÀndaren skulle vilja. Förutom HSTS har anvÀndarna skyddats av det faktum att sedan 2017 har SMTP-, IMAP- och POP3-servrarna frÄn Mail.ru förbjudit överföring av lösenord över osÀkra anslutningar; alla vÄra anvÀndare har anvÀnt TLS för Ätkomst via SMTP, POP3 och IMAP, och dÀrför kan inloggning och lösenord endast fÄngas om anvÀndaren sjÀlv gÄr med pÄ att acceptera ett manipulerat certifikat.
För mobila anvÀndare rekommenderar vi alltid att anvÀnda Mail.ru-appar för att fÄ Ätkomst till e-posten, eftersom det Àr sÀkrare att arbeta med e-post i dem Àn i webblÀsare eller inbyggda SMTP/IMAP-klienter.
Vad som behöver göras
Det Ă€r nödvĂ€ndigt att uppdatera firmware för MikroTik RouterOS till en sĂ€ker version. Om detta av nĂ„gon anledning inte Ă€r möjligt, mĂ„ste trafiken filtreras efter port 8291 (tcp och udp), vilket gör det svĂ„rare att utnyttja problemet, Ă€ven om det inte eliminerar möjligheten för passiv injektion i DNS-cache. Internetleverantörer bör filtrera denna port i sina nĂ€tverk för att skydda företagsanvĂ€ndare.Â
Alla anvÀndare som accepterat det manipulerade certifikatet bör omedelbart byta lösenord för e-post och andra tjÀnster för vilka detta certifikat accepterades. Vi kommer ocksÄ att informera anvÀndare som loggar in pÄ e-posten via sÄrbara enheter.
P.S. Det finns en relaterad sÄrbarhet som beskrivs i inlÀgget "".
KĂ€lla: habr.com
