Увечары 10 сакавіка служба падтрымкі Mail.ru пачала атрымліваць скаргі ад карыстачоў на немагчымасць падлучэння да IMAP/SMTP серверам Mail.ru праз паштовыя праграмы. Пры гэтым частка канэктаў не праходзіла, а частка паказваюць памылку сертыфіката. Памылка выклікана тым, што "сервер" аддае самападпісаны сертыфікат TLS.
За два дні прыйшло больш за 10 скаргаў ад карыстальнікаў з самых розных сетак і з самымі рознымі прыладамі, што рабіла малаверагодным праблему ў сетцы нейкага аднаго правайдэра. Больш падрабязны разбор праблемы выявіў, што ідзе падмена сервера imap.mail.ru (а гэтак жа іншых паштовых сервераў і сэрвісаў) на ўзроўні DNS. Далей, пры актыўнай дапамозе нашых карыстачоў, мы знайшлі, што чыннік у няправільным запісе ў кэшы іх роўтара, які па сумяшчальніцтве з'яўляецца лакальным DNS рэзалверам, і якім у шматлікіх (але не ўсіх) выпадках апынулася прылада MikroTik, вельмі папулярная ў невялікіх карпаратыўных сетках і у маленькіх правайдэраў Інтэрнэт.
У чым праблема
У верасні 2019 года даследчыкі некалькі ўразлівасцяў у MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), якія дазвалялі праводзіць напад DNS cache poisoning, г.зн. магчымасць падмены DNS-запісаў у DNS-кешы роўтара, прычым CVE-2019-3978 дазваляе атакаваламу не чакаць, калі хтосьці з унутранай сеткі звернецца за запісам на яго DNS-сервер, каб атруціць кэш рэзалвера, а ініцыяваць такі запыт самому праз порт 8291 (UDP і TCP). Уразлівасць была выпраўленая MikroTik у версіях RouterOS 6.45.7 (stable) і 6.44.6 (long-term) 28 кастрычніка 2019, аднак паводле большая частка карыстачоў на бягучы момант не ўсталявала патчы.
Відавочна, што цяпер гэтая праблема актыўна эксплуатуецца "ўжывую".
Чым гэта небяспечна
Атакуючы можа падмяніць DNS-запіс любога хаста, да якога звяртаецца карыстач унутранай сеткі, такім чынам перахапіўшы трафік да яго. Калі сенсітыўная інфармацыя перадаецца без шыфравання (напрыклад па http:// без TLS) ці карыстач згаджаецца прыняць падроблены сертыфікат, атакавалы можа атрымаць усе дадзеныя, якія адпраўляюцца праз злучэнне, напрыклад лагін ці пароль. Нажаль, практыка паказвае, што калі ў карыстача ёсць магчымасць прыняць падроблены сертыфікат, то ён ёй скарыстаецца.
Чаму менавіта серверы SMTP і IMAP, і што ратавала карыстальнікаў
Чаму атакуючыя спрабавалі перахапіць менавіта SMTP/IMAP-трафік паштовых дадаткаў, а не вэб-трафік, хоць большая частка карыстальнікаў ходзяць у пошту браўзэрам па HTTPS?
Не ўсе паштовыя праграмы якія працуюць па SMTP і IMAP/POP3 засцерагаюць карыстача ад памылкі, не дазваляючы яму адправіць лагін і пароль праз небяспечнае ці скампраметаванае злучэнне, хоць па стандарце , прынятаму яшчэ ў 2018 (і рэалізаваным у Mail.ru значна раней), яны павінны абараняць карыстача ад перахопу пароля праз любое неабароненае злучэнне. Акрамя таго, пакуль у паштовых кліентах вельмі рэдка выкарыстоўваецца пратакол OAuth (ён падтрымліваецца паштовымі серверамі Mail.ru), а без яго лагін і пароль перадаюцца ў кожным сеансе.
Браўзэры могуць быць крыху лепш абаронены ад нападаў Man-in-the-Middle. На ўсіх крытычных даменах mail.ru дадаткова да HTTPS уключаная палітыка HSTS (HTTP strict transport security). Пры ўключаным HSTS сучасны браўзэр не дае карыстачу простай магчымасці прыняць падроблены сертыфікат, нават калі карыстач гэтага захоча. Апроч HSTS, карыстачоў ратавала тое, што з 2017-го гады SMTP, IMAP і POP3-серверы Mail.ru забараняюць перадачу пароля праз неабароненае злучэнне, усе нашы карыстачы выкарыстоўвалі TLS для доступу па SMTP, POP3 і IMAP, і таму лагін і пароль можна перахапіць толькі калі карыстач сам згаджаецца прыняць падменены сертыфікат.
Для мабільных карыстальнікаў, мы заўсёды рэкамендуем выкарыстоўваць прыкладанні Mail.ru для доступу да пошты, т.я. праца з поштай у іх бяспечней, чым у браўзэрах ці ўбудаваных SMTP/IMAP кліентах.
Што трэба зрабіць
Неабходна абнавіць прашыўку MikroTik RouterOS да бяспечнай версіі. Калі па нейкім чынніку гэта немагчыма, неабходна адфільтраваць трафік па порце 8291 (tcp і udp), гэта абцяжарыць эксплуатацыю праблемы, хоць і не ўхіліць магчымасці пасіўнай ін'екцыі ў DNS-кэш. Інтэрнэт-правайдэрам варта фільтраваць гэты порт на сваіх сетках, каб абараніць карпаратыўных карыстачоў.
Усім карыстальнікам, якія прымалі падменены сертыфікат, варта тэрмінова змяніць пароль электроннай пошты і іншых сэрвісаў, для якіх гэты сертыфікат прымаўся. Са свайго боку, мы апавясцім карыстальнікаў, якія заходзяць у пошту праз уразлівыя прылады.
PS Ёсць яшчэ звязаная ўразлівасць, апісаная ў пасце "".
Крыніца: habr.com