Om kvelden 10. mars begynte Mail.ru-støttetjenesten å motta klager fra brukere om manglende evne til å koble til Mail.ru IMAP/SMTP-servere via e-postprogrammer. Samtidig gikk noen tilkoblinger ikke gjennom, og noen viser en sertifikatfeil. Feilen skyldes at "serveren" utsteder et selvsignert TLS-sertifikat.
På to dager kom det inn mer enn 10 klager fra brukere på en rekke nettverk og med en rekke enheter, noe som gjorde det usannsynlig at problemet var i nettverket til en leverandør. En mer detaljert analyse av problemet viste at imap.mail.ru-serveren (så vel som andre e-postservere og tjenester) blir erstattet på DNS-nivå. Videre, med aktiv hjelp fra brukerne våre, fant vi ut at årsaken var en feil oppføring i hurtigbufferen til ruteren deres, som også er en lokal DNS-løser, og som i mange (men ikke alle) tilfeller viste seg å være MikroTik enhet, veldig populær i små bedriftsnettverk og fra små Internett-leverandører.
Hva er problemet
I september 2019, forskere flere sårbarheter i MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), som tillot et DNS-cache-forgiftningsangrep, dvs. muligheten til å forfalske DNS-poster i ruterens DNS-cache, og CVE-2019-3978 lar angriperen ikke vente på at noen fra det interne nettverket ber om en oppføring på DNS-serveren hans for å forgifte resolver-cachen, men å starte en slik en forespørsel selv gjennom porten 8291 (UDP og TCP). Sårbarheten ble fikset av MikroTik i versjoner av RouterOS 6.45.7 (stabil) og 6.44.6 (langsiktig) 28. oktober 2019, men iht. De fleste brukere har for øyeblikket ikke installert patcher.
Det er åpenbart at dette problemet nå blir aktivt utnyttet "live".
Hvorfor er det farlig?
En angriper kan forfalske DNS-posten til en hvilken som helst vert som en bruker får tilgang til på det interne nettverket, og dermed avskjære trafikk til den. Hvis sensitiv informasjon overføres uten kryptering (for eksempel over http:// uten TLS) eller brukeren godtar å godta et falskt sertifikat, kan angriperen få tak i alle dataene som sendes gjennom tilkoblingen, for eksempel pålogging eller passord. Dessverre viser praksis at hvis en bruker har mulighet til å godta et falskt sertifikat, vil han benytte seg av det.
Hvorfor SMTP- og IMAP-servere, og hva som reddet brukere
Hvorfor prøvde angriperne å avskjære SMTP/IMAP-trafikk fra e-postapplikasjoner, og ikke nettrafikk, selv om de fleste brukere får tilgang til e-posten deres via HTTPS-nettleseren?
Ikke alle e-postprogrammer som fungerer via SMTP og IMAP/POP3 beskytter brukeren mot feil, og hindrer ham i å sende innlogging og passord gjennom en usikret eller kompromittert tilkobling, selv om det er i henhold til standarden , vedtatt tilbake i 2018 (og implementert i Mail.ru mye tidligere), må de beskytte brukeren mot passordavskjæring gjennom enhver usikret tilkobling. I tillegg brukes OAuth-protokollen svært sjelden i e-postklienter (den støttes av Mail.ru e-postservere), og uten den blir pålogging og passord overført i hver økt.
Nettlesere kan være litt bedre beskyttet mot Man-in-the-Middle-angrep. På alle mail.ru-kritiske domener, i tillegg til HTTPS, er HSTS-policyen (HTTP strict transport security) aktivert. Med HSTS aktivert gir en moderne nettleser ikke brukeren et enkelt alternativ til å godta et falskt sertifikat, selv om brukeren ønsker det. I tillegg til HSTS, ble brukere reddet av det faktum at siden 2017, SMTP-, IMAP- og POP3-servere til Mail.ru forbyr overføring av passord over en usikret tilkobling, alle våre brukere brukte TLS for tilgang via SMTP, POP3 og IMAP, og derfor kan innlogging og passord bare avskjæres hvis brukeren selv samtykker i å godta det falske sertifikatet.
For mobile brukere anbefaler vi alltid å bruke Mail.ru-applikasjoner for å få tilgang til e-post, fordi... arbeid med e-post i dem er tryggere enn i nettlesere eller innebygde SMTP/IMAP-klienter.
Hva å gjøre
Det er nødvendig å oppdatere MikroTik RouterOS-fastvaren til en sikker versjon. Hvis dette av en eller annen grunn ikke er mulig, er det nødvendig å filtrere trafikk på port 8291 (tcp og udp), dette vil komplisere utnyttelsen av problemet, selv om det ikke vil eliminere muligheten for passiv injeksjon i DNS-cachen. Internett-leverandører bør filtrere denne porten på nettverkene sine for å beskytte bedriftsbrukere.
Alle brukere som godtok et erstattet sertifikat bør snarest endre passordet for e-post og andre tjenester som dette sertifikatet ble akseptert for. For vår del vil vi varsle brukere som får tilgang til e-post via sårbare enheter.
PS Det er også en relatert sårbarhet beskrevet i innlegget "".
Kilde: www.habr.com