Március 10-én este a Mail.ru támogatási szolgálatához panaszok érkeztek a felhasználóktól arról, hogy nem tudnak e-mail programokon keresztül csatlakozni a Mail.ru IMAP/SMTP-kiszolgálókhoz. Ugyanakkor néhány kapcsolat nem ment át, és néhány tanúsítványhibat mutat. A hibát az okozza, hogy a "szerver" önaláírt TLS-tanúsítványt ad ki.
Két nap alatt több mint 10 panasz érkezett a felhasználóktól különböző hálózatokon és különféle eszközökön, így nem valószínű, hogy a probléma egyetlen szolgáltató hálózatában lenne. A probléma részletesebb elemzése során kiderült, hogy az imap.mail.ru szervert (valamint más levelezőszervereket és szolgáltatásokat) DNS-szinten lecserélik. Továbbá felhasználóink aktív közreműködésével azt találtuk, hogy az ok az útválasztójuk gyorsítótárában történt hibás bejegyzés, amely egyben helyi DNS-feloldó is, és amely sok esetben (de nem minden esetben) a MikroTik volt. eszköz, nagyon népszerű a kisvállalati hálózatokban és a kis internetszolgáltatóknál.
Mi a probléma
2019 szeptemberében a kutatók a MikroTik RouterOS számos sérülékenysége (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), amely lehetővé tette a DNS-gyorsítótár-mérgezés támadást, pl. az útválasztó DNS-gyorsítótárában található DNS-rekordok meghamisításának képessége, a CVE-2019-3978 pedig lehetővé teszi a támadó számára, hogy ne várja meg, amíg valaki a belső hálózatról bejegyzést kér a DNS-kiszolgálóján a feloldó gyorsítótár megmérgezése érdekében, hanem ezt kezdeményezi. saját kérést a 8291-es porton keresztül (UDP és TCP). A sebezhetőséget a MikroTik javította a RouterOS 6.45.7 (stabil) és 6.44.6 (hosszú távú) verzióiban 28. október 2019-án, de a A legtöbb felhasználó jelenleg nem telepített javításokat.
Nyilvánvaló, hogy ezt a problémát most aktívan "élőben" használják ki.
Miért veszélyes?
A támadó meghamisíthatja a belső hálózaton a felhasználó által elért bármely gazdagép DNS-rekordját, ezáltal elfoghatja az arra irányuló forgalmat. Ha bizalmas információkat titkosítás nélkül továbbítanak (például http://-n keresztül TLS nélkül), vagy a felhasználó beleegyezik egy hamis tanúsítvány elfogadásába, a támadó megszerezheti a kapcsolaton keresztül küldött összes adatot, például bejelentkezési nevet vagy jelszót. Sajnos a gyakorlat azt mutatja, hogy ha a felhasználónak lehetősége van elfogadni egy hamis tanúsítványt, akkor élni fog vele.
Miért SMTP- és IMAP-kiszolgálók, és mi mentette meg a felhasználókat?
Miért próbálták a támadók az e-mail alkalmazások SMTP/IMAP forgalmát elfogni, és nem a webes forgalmat, bár a legtöbb felhasználó HTTPS böngészőn keresztül éri el leveleit?
Nem minden SMTP-n és IMAP/POP3-on keresztül működő levelezőprogram védi meg a felhasználót a hibáktól, megakadályozva, hogy nem biztonságos vagy feltört kapcsolaton keresztül bejelentkezési nevet és jelszót küldjön, bár a szabvány szerint. , amelyet még 2018-ban fogadtak el (és a Mail.ru-ban jóval korábban implementálták), meg kell védeniük a felhasználót a jelszavak elfogásától bármilyen nem biztonságos kapcsolaton keresztül. Ezenkívül az OAuth protokollt nagyon ritkán használják az e-mail kliensekben (a Mail.ru levelezőszerverei támogatják), és enélkül minden munkamenetben továbbítják a bejelentkezési nevet és a jelszót.
Lehet, hogy a böngészők egy kicsit jobban védettek a Man-in-the-Middle támadásokkal szemben. Az összes mail.ru kritikus tartományban a HTTPS mellett a HSTS (HTTP szigorú szállítási biztonság) házirend is engedélyezve van. Ha a HSTS engedélyezve van, a modern böngészők nem adnak könnyű lehetőséget a hamis tanúsítvány elfogadására, még akkor sem, ha a felhasználó akarja. A felhasználókat a HSTS mellett az mentette meg, hogy 2017 óta a Mail.ru SMTP, IMAP és POP3 szerverei tiltják a jelszavak nem biztonságos kapcsolaton keresztüli átvitelét, minden felhasználónk TLS-t használt az SMTP, POP3 és IMAP hozzáféréshez, ill. ezért a bejelentkezés és a jelszó csak akkor tud lehallgatni, ha a felhasználó maga vállalja a hamisított tanúsítvány elfogadását.
Mobilfelhasználóknak mindig javasoljuk a Mail.ru alkalmazások használatát a levelek eléréséhez, mert... A bennük lévő levelekkel való munkavégzés biztonságosabb, mint a böngészőkben vagy a beépített SMTP/IMAP kliensekben.
Mi a teendő
Frissíteni kell a MikroTik RouterOS firmware-t biztonságos verzióra. Ha ez valamilyen oknál fogva nem lehetséges, akkor a 8291-es porton (tcp és udp) szűrni kell a forgalmat, ez megnehezíti a probléma kihasználását, bár nem zárja ki a DNS-gyorsítótárba való passzív befecskendezés lehetőségét. Az internetszolgáltatóknak szűrniük kell ezt a portot hálózatukon a vállalati felhasználók védelme érdekében.
Minden felhasználónak, aki elfogadta a helyettesített tanúsítványt, sürgősen meg kell változtatnia az e-mail és más szolgáltatások jelszavát, amelyekhez ezt a tanúsítványt elfogadták. A magunk részéről értesíteni fogjuk azokat a felhasználókat, akik sebezhető eszközökön keresztül érik el a leveleket.
PS A bejegyzésben egy kapcsolódó sebezhetőség is található "".
Forrás: will.com