Om aftenen den 10. marts begyndte Mail.ru-supporttjenesten at modtage klager fra brugere om manglende evne til at oprette forbindelse til Mail.ru IMAP/SMTP-servere via e-mail-programmer. Samtidig gik nogle forbindelser ikke igennem, og nogle viser en certifikatfejl. Fejlen skyldes, at "serveren" har udstedt et selvsigneret TLS-certifikat.
På to dage kom der mere end 10 klager fra brugere på en række forskellige netværk og med en række forskellige enheder, hvilket gjorde det usandsynligt, at problemet var i netværket hos en udbyder. En mere detaljeret analyse af problemet viste, at imap.mail.ru-serveren (såvel som andre mailservere og tjenester) udskiftes på DNS-niveau. Yderligere, med aktiv hjælp fra vores brugere, fandt vi ud af, at årsagen var en forkert indtastning i cachen på deres router, som også er en lokal DNS-resolver, og som i mange (men ikke alle) tilfælde viste sig at være MikroTik enhed, meget populær i små virksomhedsnetværk og fra små internetudbydere.
Hvad er problemet
I september 2019, forskere flere sårbarheder i MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), som tillod et DNS-cache-forgiftningsangreb, dvs. evnen til at spoofe DNS-poster i routerens DNS-cache, og CVE-2019-3978 tillader angriberen ikke at vente på, at nogen fra det interne netværk anmoder om en indgang på sin DNS-server for at forgifte resolver-cachen, men at starte en sådan en anmodning selv gennem porten 8291 (UDP og TCP). Sårbarheden blev rettet af MikroTik i versioner af RouterOS 6.45.7 (stabil) og 6.44.6 (langsigtet) den 28. oktober 2019, men iflg. De fleste brugere har i øjeblikket ikke installeret patches.
Det er indlysende, at dette problem nu bliver aktivt udnyttet "live".
Hvorfor er det farligt
En hacker kan forfalske DNS-posten for enhver vært, som en bruger har adgang til på det interne netværk, og derved opsnappe trafik til den. Hvis følsomme oplysninger transmitteres uden kryptering (for eksempel over http:// uden TLS), eller brugeren accepterer at acceptere et falsk certifikat, kan angriberen få alle de data, der sendes gennem forbindelsen, såsom et login eller adgangskode. Desværre viser praksis, at hvis en bruger har mulighed for at acceptere et falsk certifikat, vil han benytte sig af det.
Hvorfor SMTP- og IMAP-servere, og hvad reddede brugere
Hvorfor forsøgte angriberne at opsnappe SMTP/IMAP-trafik fra e-mail-applikationer og ikke webtrafik, selvom de fleste brugere tilgår deres e-mail via HTTPS-browseren?
Ikke alle e-mail-programmer, der arbejder via SMTP og IMAP/POP3, beskytter brugeren mod fejl, hvilket forhindrer ham i at sende login og adgangskode gennem en usikker eller kompromitteret forbindelse, selvom det er i henhold til standarden , vedtaget tilbage i 2018 (og implementeret i Mail.ru meget tidligere), skal de beskytte brugeren mod adgangskodeaflytning gennem enhver usikret forbindelse. Derudover bruges OAuth-protokollen meget sjældent i e-mail-klienter (den understøttes af Mail.ru-mailservere), og uden den overføres login og adgangskode i hver session.
Browsere er muligvis lidt bedre beskyttet mod Man-in-the-Middle-angreb. På alle mail.ru-kritiske domæner er HSTS-politikken (HTTP strict transport security) aktiveret ud over HTTPS. Med HSTS aktiveret giver en moderne browser ikke brugeren en nem mulighed for at acceptere et falsk certifikat, selvom brugeren ønsker det. Ud over HSTS blev brugerne reddet af, at siden 2017 har SMTP-, IMAP- og POP3-servere på Mail.ru forbyder overførsel af adgangskoder via en usikker forbindelse, alle vores brugere brugte TLS til adgang via SMTP, POP3 og IMAP, og login og adgangskode kan derfor kun opsnappes, hvis brugeren selv accepterer at acceptere det forfalskede certifikat.
For mobile brugere anbefaler vi altid at bruge Mail.ru-applikationer til at få adgang til mail, fordi... at arbejde med mail i dem er mere sikkert end i browsere eller indbyggede SMTP/IMAP-klienter.
Hvad skal man gøre
Det er nødvendigt at opdatere MikroTik RouterOS-firmwaren til en sikker version. Hvis dette af en eller anden grund ikke er muligt, er det nødvendigt at filtrere trafik på port 8291 (tcp og udp), dette vil komplicere udnyttelsen af problemet, selvom det ikke vil eliminere muligheden for passiv indsprøjtning i DNS-cachen. Internetudbydere bør filtrere denne port på deres netværk for at beskytte virksomhedsbrugere.
Alle brugere, der har accepteret et erstattet certifikat, bør omgående ændre adgangskoden til e-mail og andre tjenester, som dette certifikat blev accepteret for. For vores vedkommende vil vi underrette brugere, der får adgang til mail via sårbare enheder.
PS Der er også en relateret sårbarhed beskrevet i indlægget "".
Kilde: www.habr.com