Március 10-én este a Mail.ru ügyfélszolgálata számos panaszt kapott a felhasználóktól, akik nem tudtak csatlakozni a Mail.ru IMAP/SMTP szervereihez levélprogramokon keresztül. Eközben néhány kapcsolat nem volt sikeres, míg mások tanúsítványhibát jelzettek. A hiba annak köszönhető, hogy a "szerver" önaláírt TLS tanúsítványt ad át.
Két nap alatt több mint 10 panasz érkezett felhasználóktól a legkülönbözőbb hálózatokból és eszközökről, ami kicsi valószínűséggel jelentette egyetlen szolgáltató hálózati problémáját. A probléma részletes elemzése feltárta, hogy az imap.mail.ru (és más levelezőszerverek és szolgáltatások) DNS szinten való cseréje zajlik. Később, a felhasználóink aktív segítségével kiderítettük, hogy az oka a routerük cache-ében lévő hibás bejegyzés, amely egyben helyi DNS feloldó is, és amely sok esetben MikroTik eszköz volt, amely nagyon népszerű a kisebb vállalatok hálózataiban és a kis internetszolgáltatóknál.
Mi a probléma
2019 szeptemberében a kutatók több sérülékenységet a MikroTik RouterOS-ben (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), amelyek lehetővé tették a DNS cache poisoning támadást, vagyis a DNS bejegyzések módosítását a router DNS-cache-jében, ráadásul a CVE-2019-3978 lehetővé tette a támadó számára, hogy ne várjon arra, hogy valaki a belső hálózatról egy bejegyzésért a DNS szerveréhez forduljon, hogy megmérgezze a feloldó cache-t, hanem magának igényelhet egy ilyen lekérdezést a 8291-es porton (UDP és TCP) keresztül. A sérülékenységet a MikroTik javította a RouterOS 6.45.7 (stabil) és a 6.44.6 (hosszú távú) verzióiban 2019. október 28-án, azonban a a felhasználók nagy része jelenleg nem telepítette a javításokat.
Nyilvánvaló, hogy most ezt a problémát aktívan kihasználják "élesben".
Milyen veszélyeket jelent ez
A támadó módosíthatja bármelyik gazdagép DNS-bejegyzését, amelyre a belső hálózat felhasználója hivatkozik, így elcsípheti a hozzá irányuló forgalmat. Ha érzékeny információt továbbítanak titkosítás nélkül (például http:// TLS nélkül) vagy a felhasználó elfogadja a hamis tanúsítványt, a támadó hozzáférhet az összes olyan adat számára, amelyeket a kapcsolaton keresztül küldenek, például a felhasználónevet vagy a jelszót. Sajnos a gyakorlat azt mutatja, hogy ha a felhasználónak lehetősége van hamis tanúsítvány elfogadására, akkor élni fog ezzel a lehetőséggel.
Miért éppen az SMTP és IMAP szerverek, és mivel segítették a felhasználókat?
Miért próbálták a támadók éppen az SMTP/IMAP forgalmat megfertőzni a levelező alkalmazásokban, nem pedig a webforgalmat, bár a felhasználók nagy része HTTPS-en keresztül böngészik a levelezést?
Nem minden, SMTP és IMAP/POP3 alapú levelezőprogram véd meg a felhasználói hibáktól, és nem akadályozza meg, hogy a felhasználók nem biztonságos vagy kompromittált kapcsolaton keresztül küldjenek bejelentkezési adatokat, holott a szabvány szerint , amelyet 2018-ban fogadtak el (és a Mail.ru már jóval korábban megvalósított), meg kellene hogy védje a felhasználót a jelszó kompromittálásától bármilyen nem biztonságos kapcsolaton keresztül. Ezen kívül, míg a levelező kliensekben nagyon ritkán használják az OAuth protokollt (amit a Mail.ru levelezőszerverei támogatnak), nélküle a bejelentkezési adatok minden egyes munkamenetben továbbítódnak.
A böngészők kissé jobban védettek a Man-in-the-Middle támadások ellen. Minden kritikus mail.ru domain esetében a HTTPS mellett HSTS (HTTP Strict Transport Security) politika is be van kapcsolva. Bekapcsolt HSTS mellett a modern böngészők nem adják meg a felhasználónak a lehetőséget, hogy hamis tanúsítványt fogadjon el, még akkor sem, ha azt szeretné. A HSTS-en túl a felhasználókat az is védte, hogy 2017 óta a Mail.ru SMTP, IMAP és POP3 szerverei megtiltják a jelszó nem biztonságos kapcsolaton keresztüli átadását, és minden felhasználónk TLS-t használt az SMTP, POP3 és IMAP eléréséhez, így a bejelentkezési adatok csak akkor foghatók el, ha a felhasználó elfogadja a hamis tanúsítványt.
A mobil felhasználóknak mindig azt javasoljuk, hogy a Mail.ru alkalmazásokat használják a levelezéshez, mivel sokkal biztonságosabb, mint böngészőkben vagy beépített SMTP/IMAP kliensekben dolgozni.
Mit kell tenni
Frissíteni kell a MikroTik RouterOS firmware-jét egy biztonságos verzióra. Ha valamilyen okból ez nem lehetséges, forgalmat kell szűrni a 8291-es porton (tcp és udp), ez megnehezíti a probléma kihasználását, bár nem szünteti meg a passzív DNS-készletbe való injekció lehetőségét. Az internet szolgáltatóknak is szűrniük kell ezt a portot a hálózataikon, hogy megvédjék a vállalati felhasználókat.
Minden felhasználónak, aki elfogadta a hamisított tanúsítványt, azonnal meg kell változtatnia az e-mail és más szolgáltatások jelszavát, amelyeknél ezt a tanúsítványt használták. A magunk részéről értesítjük azokat a felhasználókat, akik sebezhető eszközökön lépnek be az e-mailjükbe.
P.S. Van még egy kapcsolódó sebezhetőség, amely a bejegyzésben van leírva. "".
Forrás: habr.com
