Opdater RouterOS på dit MikroTik

Om aftenen den 10. marts begyndte Mail.ru's supportteam at modtage klager fra brugere om, at de ikke kunne oprette forbindelse til Mail.rus IMAP/SMTP-servere via mailprogrammer. Nogle forbindelser mislykkedes, mens andre viste en certifikatfejl. Fejlen skyldes, at "serveren" returnerer et selvsigneret TLS-certifikat.
 

I løbet af to dage kom der mere end 10 klager fra brugere fra forskellige netværk og med forskellige enheder, hvilket gjorde det usandsynligt, at problemet stammede fra en enkelt udbyder. En mere detaljeret analyse af problemet viste, at serveren imap.mail.ru (og også andre mailservere og tjenester) blev forfalsket på DNS-niveau. Med aktiv hjælp fra vores brugere fandt vi ud af, at årsagen var en forkert post i cache'en på deres router, som samtidig fungerede som lokal DNS-opløser, og som i mange (men ikke alle) tilfælde viste sig at være en MikroTik-enhed, som er meget populær i små virksomheders netværk og hos små internetudbydere.

Hvad er problemet

I september 2019 fandt forskere flere sårbarheder i MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), som muliggjorde DNS cache poisoning-angreb, dvs. muligheden for at ændre DNS-poster i routerens DNS-cache, hvor CVE-2019-3978 tillader angriberen at initiere en forespørgsel selv via port 8291 (UDP og TCP) uden at vente på, at nogen i det indre netværk anmoder om posten på hans DNS-server for at forgifte resolverens cache. Sårbarheden blev rettet af MikroTik i versionerne RouterOS 6.45.7 (stabil) og 6.44.6 (langtids-support) den 28. oktober 2019, men ifølge undersøgelserne har størstedelen af brugerne på nuværende tidspunkt ikke installeret patchene. Det er åbenlyst, at dette problem i øjeblikket bliver udnyttet "live".

Hvor farligt er det

Angriberen kan ændre DNS-posten for enhver vært, som en bruger af det indre netværk tilgår, og dermed opsnappe trafik til denne vært. Hvis følsomme oplysninger sendes uden kryptering (for eksempel over http:// uden TLS) eller brugeren accepterer et falsk certifikat, kan angriberen få alle data, der sendes gennem forbindelsen, såsom login eller adgangskode. Desværre viser praksis, at hvis brugeren har mulighed for at acceptere et falsk certifikat, vil han tage det.

Angriberen kan ændre DNS-posten for enhver vært, som brugeren på det interne netværk henvender sig til, og dermed opsnappe trafikken til den. Hvis følsomme oplysninger overføres uden kryptering (f.eks. via http:// uden TLS) eller brugeren accepterer et falsk certifikat, kan angriberen få adgang til alle de data, der sendes gennem forbindelsen, såsom brugernavn eller adgangskode. Desværre viser erfaringen, at hvis en bruger har mulighed for at acceptere et falsk certifikat, vil de gøre det.

Hvorfor netop SMTP- og IMAP-servere, og hvad der beskyttede brugerne

Hvorfor forsøgte angriberne at opsnappe netop SMTP/IMAP-trafikken fra emailapplikationer og ikke web-trafikken, selvom størstedelen af brugerne tilgår deres email via en browser over HTTPS?

Ikke alle emailprogrammer, der arbejder med SMTP og IMAP/POP3, beskytter brugeren mod fejlen ved at forhindre dem i at sende login og kodeord over en usikker eller kompromitteret forbindelse, selvom standarden RFC 8314, vedtaget allerede i 2018 (og implementeret i Mail.ru meget tidligere), kræver, at de skal beskytte brugeren mod opsnapning af kodeord gennem enhver usikker forbindelse. Derudover er det stadig sjældent, at emailklienter bruger OAuth-protokollen (som understøttes af Mail.ru's emailservere), og uden den overføres login og kodeord i hver session.

Browsere kan være en smule bedre beskyttet mod Man-in-the-Middle-angreb. På alle kritiske domæner for mail.ru er politikken HSTS (HTTP Strict Transport Security) aktiveret ud over HTTPS. Når HSTS er aktiveret, tillader moderne browsere ikke brugeren at vælge et falsk certifikat, selvom de ønsker det. Ud over HSTS blev brugerne beskyttet af det faktum, at siden 2017 har SMTP-, IMAP- og POP3-servere fra Mail.ru forbudt overførsel af kodeord over usikre forbindelser, så alle vores brugere brugte TLS til at få adgang til SMTP, POP3 og IMAP, og derfor kan login og kodeord kun opsnappes, hvis brugeren selv accepterer det forfalskede certifikat.

For mobilbrugere anbefaler vi altid at bruge Mail.ru-apps til at få adgang til email, da arbejdet med email i dem er mere sikkert end i browsere eller indbyggede SMTP/IMAP-klienter.

Hvad skal der gøres

Det er nødvendigt at opdatere firmware af MikroTik RouterOS 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), da dette vil vanskeliggøre udnyttelsen af problemet, selvom det ikke fjerner muligheden for passiv injektion i DNS-cachen. Internetudbydere bør filtrere denne port i deres netværk for at beskytte virksomhedens brugere. 

Alle brugere, der har accepteret det manipulerede certifikat, bør straks ændre deres e-mailadgangskoder og adgangskoder til andre tjenester, som dette certifikat blev accepteret for. Vi vil informere brugere, der tilgår deres e-mail fra sårbare enheder.

P.S. Der er en anden relateret sårbarhed beskrevet i indlægget. LukaSafonov "Backport-sårbarhed i RouterOS sætter hundredtusindvis af enheder i fare".

Kilde: habr.com