Noong gabi ng Marso 10, nagsimulang makatanggap ang serbisyo ng suporta ng Mail.ru ng mga reklamo mula sa mga user tungkol sa kawalan ng kakayahang kumonekta sa Mail.ru IMAP/SMTP server sa pamamagitan ng mga email program. Kasabay nito, ang ilang mga koneksyon ay hindi dumaan, at ang ilan ay nagpapakita ng error sa sertipiko. Ang error ay sanhi ng "server" na nag-isyu ng self-signed TLS certificate.
Sa loob ng dalawang araw, mahigit sa 10 reklamo ang dumating mula sa mga user sa iba't ibang uri ng network at sa iba't ibang device, kaya hindi malamang na ang problema ay nasa network ng alinmang provider. Ang isang mas detalyadong pagsusuri ng problema ay nagsiwalat na ang imap.mail.ru server (pati na rin ang iba pang mga mail server at serbisyo) ay pinapalitan sa antas ng DNS. Dagdag pa, sa aktibong tulong ng aming mga user, nalaman namin na ang dahilan ay isang hindi tamang pagpasok sa cache ng kanilang router, na isa ring lokal na DNS resolver, at na sa marami (ngunit hindi lahat) mga kaso ay naging MikroTik. device, napakasikat sa maliliit na corporate network at mula sa maliliit na Internet provider.
Ano ang problema
Noong Setyembre 2019, ang mga mananaliksik ilang mga kahinaan sa MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), na nagbigay-daan sa isang DNS cache poisoning attack, i.e. ang kakayahang manloko ng mga tala ng DNS sa DNS cache ng router, at ang CVE-2019-3978 ay nagbibigay-daan sa umaatake na huwag maghintay para sa isang tao mula sa panloob na network na humiling ng isang entry sa kanyang DNS server upang lason ang cache ng solver, ngunit upang simulan ang naturang isang kahilingan mismo sa pamamagitan ng port 8291 (UDP at TCP). Ang kahinaan ay inayos ng MikroTik sa mga bersyon ng RouterOS 6.45.7 (stable) at 6.44.6 (pangmatagalang) noong Oktubre 28, 2019, ngunit ayon sa Karamihan sa mga user ay hindi kasalukuyang nag-install ng mga patch.
Malinaw na ang problemang ito ay aktibong pinagsamantalahan nang "live".
Bakit ito delikado
Ang isang umaatake ay maaaring madaya ang DNS record ng anumang host na na-access ng isang user sa panloob na network, at sa gayon ay naharang ang trapiko dito. Kung naipadala ang sensitibong impormasyon nang walang pag-encrypt (halimbawa, sa http:// nang walang TLS) o sumang-ayon ang user na tumanggap ng pekeng certificate, maaaring makuha ng attacker ang lahat ng data na ipinadala sa pamamagitan ng koneksyon, gaya ng login o password. Sa kasamaang palad, ipinapakita ng kasanayan na kung ang isang gumagamit ay may pagkakataon na tumanggap ng isang pekeng sertipiko, sasamantalahin niya ito.
Bakit SMTP at IMAP server, at kung ano ang nag-save ng mga user
Bakit sinubukan ng mga umaatake na harangin ang trapiko ng SMTP/IMAP ng mga email application, at hindi trapiko sa web, bagama't ina-access ng karamihan sa mga user ang kanilang mail sa pamamagitan ng HTTPS browser?
Hindi lahat ng email program na gumagana sa pamamagitan ng SMTP at IMAP/POP3 ay nagpoprotekta sa user mula sa mga error, na pumipigil sa kanya sa pagpapadala ng login at password sa pamamagitan ng hindi secure o nakompromisong koneksyon, bagama't ayon sa pamantayan , na pinagtibay noong 2018 (at ipinatupad sa Mail.ru nang mas maaga), dapat nilang protektahan ang user mula sa pagharang ng password sa pamamagitan ng anumang hindi secure na koneksyon. Bilang karagdagan, ang OAuth protocol ay napakabihirang ginagamit sa mga email client (ito ay suportado ng Mail.ru mail server), at kung wala ito, ang pag-login at password ay ipinapadala sa bawat session.
Maaaring mas protektado ang mga browser laban sa mga pag-atake ng Man-in-the-Middle. Sa lahat ng mga kritikal na domain ng mail.ru, bilang karagdagan sa HTTPS, pinagana ang patakaran ng HSTS (HTTP strict transport security). Kapag pinagana ang HSTS, hindi binibigyan ng modernong browser ang user ng madaling opsyon na tumanggap ng pekeng certificate, kahit na gusto ng user. Bilang karagdagan sa HSTS, ang mga gumagamit ay na-save sa pamamagitan ng katotohanan na mula noong 2017, ipinagbabawal ng SMTP, IMAP at POP3 server ng Mail.ru ang paglipat ng mga password sa isang hindi secure na koneksyon, ang lahat ng aming mga gumagamit ay gumamit ng TLS para sa pag-access sa pamamagitan ng SMTP, POP3 at IMAP, at samakatuwid ang pag-login at password ay maaaring maka-intercept lamang kung ang user mismo ay sumang-ayon na tanggapin ang spoofed certificate.
Para sa mga gumagamit ng mobile, palagi naming inirerekomenda ang paggamit ng mga application ng Mail.ru upang ma-access ang mail, dahil... Ang pagtatrabaho sa mail sa mga ito ay mas ligtas kaysa sa mga browser o built-in na SMTP/IMAP client.
Ano ang gagawin
Kinakailangang i-update ang firmware ng MikroTik RouterOS sa isang secure na bersyon. Kung sa ilang kadahilanan ay hindi ito posible, kinakailangan na i-filter ang trapiko sa port 8291 (tcp at udp), ito ay magpapalubha sa pagsasamantala ng problema, bagaman hindi nito maaalis ang posibilidad ng passive injection sa DNS cache. Dapat i-filter ng mga ISP ang port na ito sa kanilang mga network upang maprotektahan ang mga corporate na user.
Ang lahat ng user na tumanggap ng pinalitang certificate ay dapat na agarang baguhin ang password para sa email at iba pang mga serbisyo kung saan tinanggap ang certificate na ito. Sa aming bahagi, aabisuhan namin ang mga user na nag-a-access ng mail sa pamamagitan ng mga mahihinang device.
PS Mayroon ding nauugnay na kahinaan na inilarawan sa post "".
Pinagmulan: www.habr.com