På kvällen den 10 mars började supporttjänsten Mail.ru ta emot klagomål från användare om oförmågan att ansluta till Mail.ru IMAP/SMTP-servrar via e-postprogram. Samtidigt gick vissa anslutningar inte igenom, och vissa visar ett certifikatfel. Felet orsakas av att "servern" utfärdar ett självsignerat TLS-certifikat.
På två dagar kom mer än 10 klagomål in från användare på en mängd olika nätverk och med en mängd olika enheter, vilket gjorde det osannolikt att problemet fanns i nätverket hos någon leverantör. En mer detaljerad analys av problemet visade att imap.mail.ru-servern (liksom andra e-postservrar och tjänster) byts ut på DNS-nivå. Vidare, med aktiv hjälp av våra användare, fann vi att orsaken var en felaktig inmatning i cachen på deras router, som också är en lokal DNS-lösare, och som i många (men inte alla) fall visade sig vara MikroTik enhet, mycket populär i små företagsnätverk och från små internetleverantörer.
Vad är problemet
I september 2019, forskare flera sårbarheter i MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), som möjliggjorde en DNS-cacheförgiftningsattack, d.v.s. möjligheten att förfalska DNS-poster i routerns DNS-cache, och CVE-2019-3978 tillåter angriparen att inte vänta på att någon från det interna nätverket ska begära en post på sin DNS-server för att förgifta resolvercachen, utan att initiera en sådan en begäran själv via porten 8291 (UDP och TCP). Sårbarheten fixades av MikroTik i versioner av RouterOS 6.45.7 (stabil) och 6.44.6 (långsiktig) den 28 oktober 2019, men enligt De flesta användare har för närvarande inte installerat patchar.
Det är uppenbart att detta problem nu aktivt utnyttjas "live".
Varför är det farligt
En angripare kan förfalska DNS-posten för vilken värd som helst som en användare kommer åt på det interna nätverket och därigenom fånga upp trafik till den. Om känslig information överförs utan kryptering (till exempel över http:// utan TLS) eller om användaren går med på att acceptera ett falskt certifikat, kan angriparen få all data som skickas via anslutningen, såsom inloggning eller lösenord. Tyvärr visar praxis att om en användare har möjlighet att acceptera ett falskt certifikat, kommer han att dra nytta av det.
Varför SMTP- och IMAP-servrar, och vad som räddade användare
Varför försökte angriparna fånga upp SMTP/IMAP-trafik från e-postprogram, och inte webbtrafik, även om de flesta användare kommer åt sin e-post via HTTPS-webbläsaren?
Inte alla e-postprogram som fungerar via SMTP och IMAP/POP3 skyddar användaren från fel, vilket hindrar honom från att skicka inloggning och lösenord via en osäker eller komprometterad anslutning, även om det är enligt standarden , som antogs redan 2018 (och implementerade i Mail.ru mycket tidigare), måste de skydda användaren från lösenordsavlyssning genom osäkra anslutningar. Dessutom används OAuth-protokollet mycket sällan i e-postklienter (det stöds av Mail.ru e-postservrar), och utan det överförs inloggningen och lösenordet i varje session.
Webbläsare kan vara lite bättre skyddade mot Man-in-the-Middle-attacker. På alla viktiga mail.ru-domäner, förutom HTTPS, är HSTS-policyn (HTTP strict transport security) aktiverad. Med HSTS aktiverat ger en modern webbläsare inte användaren ett enkelt alternativ att acceptera ett falskt certifikat, även om användaren vill. Förutom HSTS räddades användare av det faktum att sedan 2017, SMTP, IMAP och POP3-servrar för Mail.ru förbjuder överföring av lösenord via en osäkrad anslutning, alla våra användare använde TLS för åtkomst via SMTP, POP3 och IMAP, och Därför kan inloggning och lösenord endast avlyssnas om användaren själv går med på att acceptera det falska certifikatet.
För mobilanvändare rekommenderar vi alltid att du använder Mail.ru-applikationer för att komma åt e-post, eftersom... att arbeta med e-post i dem är säkrare än i webbläsare eller inbyggda SMTP/IMAP-klienter.
Vad ska man göra
Det är nödvändigt att uppdatera MikroTik RouterOS firmware till en säker version. Om detta av någon anledning inte är möjligt är det nödvändigt att filtrera trafik på port 8291 (tcp och udp), detta kommer att komplicera utnyttjandet av problemet, även om det inte kommer att eliminera möjligheten till passiv injektion i DNS-cachen. Internetleverantörer bör filtrera denna port på sina nätverk för att skydda företagsanvändare.
Alla användare som accepterat ett ersatt certifikat bör snarast ändra lösenordet för e-post och andra tjänster för vilka detta certifikat har godkänts. För vår del kommer vi att meddela användare som kommer åt e-post via sårbara enheter.
PS Det finns också en relaterad sårbarhet som beskrivs i inlägget "".
Källa: will.com