Ĝisdatigu RouterOS sur via MikroTik

Ĝisdatigu RouterOS sur via MikroTik
Vespere de la 10-a de marto, la helpservo de Mail.ru komencis ricevi plendojn de uzantoj pri la malkapablo konekti al Mail.ru IMAP/SMTP-serviloj per retpoŝtaj programoj. Samtempe, kelkaj konektoj ne trapasis, kaj kelkaj montras atestileraron. La eraro estas kaŭzita de la "servilo" emisianta memsubskribitan TLS-atestilon.
 
Ĝisdatigu RouterOS sur via MikroTik
En du tagoj, pli ol 10 plendoj venis de uzantoj en diversaj retoj kaj kun diversaj aparatoj, igante neprobabla ke la problemo estis en la reto de iu ajn provizanto. Pli detala analizo de la problemo malkaŝis, ke la servilo imap.mail.ru (same kiel aliaj poŝtserviloj kaj servoj) estas anstataŭigita ĉe la DNS-nivelo. Plue, kun la aktiva helpo de niaj uzantoj, ni trovis, ke la kialo estis malĝusta eniro en la kaŝmemoro de ilia enkursigilo, kiu ankaŭ estas loka DNS-solvilo, kaj kiu en multaj (sed ne ĉiuj) kazoj montriĝis esti la MikroTik. aparato, tre populara en malgrandaj kompaniaj retoj kaj de malgrandaj interretaj provizantoj.

Kio estas la problemo

En septembro 2019, esploristoj trovita pluraj vundeblecoj en MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), kiuj permesis DNS-kaŝan venenatakon, t.e. la kapablo falsigi DNS-rekordojn en la DNS-kaŝmemoro de la enkursigilo, kaj CVE-2019-3978 permesas al la atakanto ne atendi ke iu el la interna reto petu eniron sur sia DNS-servilo por veneni la solvigan kaŝmemoron, sed komenci tian. peto mem tra la haveno 8291 (UDP kaj TCP). La vundebleco estis riparita de MikroTik en versioj de RouterOS 6.45.7 (stabila) kaj 6.44.6 (longtempa) la 28-an de oktobro 2019, sed laŭ esploro Plej multaj uzantoj nuntempe ne instalis diakilojn.

Estas evidente, ke ĉi tiu problemo nun estas aktive ekspluatata "vive".

Kial ĝi estas danĝera?

Atakanto povas falsigi la DNS-rekordon de iu ajn gastiganto alirita de uzanto en la interna reto, tiel kaptante trafikon al ĝi. Se sentemaj informoj estas transdonitaj sen ĉifrado (ekzemple, super http:// sen TLS) aŭ la uzanto konsentas akcepti falsan atestilon, la atakanto povas akiri ĉiujn datumojn, kiuj estas senditaj per la konekto, kiel ensaluton aŭ pasvorton. Bedaŭrinde, praktiko montras, ke se uzanto havas la ŝancon akcepti falsan atestilon, li profitos ĝin.

Kial SMTP kaj IMAP-serviloj, kaj kio savis uzantojn

Kial la atakantoj provis kapti SMTP/IMAP-trafikon de retpoŝtaj aplikoj, kaj ne retan trafikon, kvankam plej multaj uzantoj aliras sian poŝton per HTTPS-retumilo?

Ne ĉiuj retpoŝtaj programoj laborantaj per SMTP kaj IMAP/POP3 protektas la uzanton kontraŭ eraroj, malhelpante lin sendi ensaluton kaj pasvorton per nesekurigita aŭ kompromitita konekto, kvankam laŭ la normo. RFC 8314, adoptita reen en 2018 (kaj efektivigita en Mail.ru multe pli frue), ili devas protekti la uzanton de pasvortkapto per iu nesekurigita konekto. Krome, la OAuth-protokolo tre malofte estas uzata en retpoŝtaj klientoj (ĝi estas subtenata de poŝtserviloj de Mail.ru), kaj sen ĝi, la ensaluto kaj pasvorto estas transdonitaj en ĉiu sesio.

Retumiloj eble estas iom pli bone protektitaj kontraŭ atakoj de Man-en-la-Mezo. Sur ĉiuj kritikaj domajnoj de mail.ru, krom HTTPS, la politiko HSTS (HTTP strikta transporta sekureco) estas ebligita. Kun HSTS ebligita, moderna retumilo ne donas al la uzanto facilan eblon akcepti falsan atestilon, eĉ se la uzanto volas. Krom HSTS, uzantoj saviĝis pro tio, ke ekde 2017, SMTP, IMAP kaj POP3-serviloj de Mail.ru malpermesas la translokigon de pasvortoj per nesekurigita konekto, ĉiuj niaj uzantoj uzis TLS por aliro per SMTP, POP3 kaj IMAP, kaj tial ensaluto kaj pasvorto povas interkapti nur se la uzanto mem konsentas akcepti la falsan atestilon.

Por poŝtelefonaj uzantoj, ni ĉiam rekomendas uzi Mail.ru-aplikojn por aliri poŝton, ĉar... labori kun poŝto en ili estas pli sekura ol en retumiloj aŭ enkonstruitaj SMTP/IMAP-klientoj.

Kion oni devas fari

Necesas ĝisdatigi la firmware de MikroTik RouterOS al sekura versio. Se ial tio ne eblas, necesas filtri trafikon sur la haveno 8291 (tcp kaj udp), tio malfaciligos la ekspluaton de la problemo, kvankam ĝi ne forigos la eblecon de pasiva injekto en la DNS-kaŝmemoron. ISP-oj devas filtri ĉi tiun havenon en siaj retoj por protekti kompaniajn uzantojn. 

Ĉiuj uzantoj, kiuj akceptis anstataŭigitan atestilon, urĝe ŝanĝu la pasvorton por retpoŝto kaj aliaj servoj, por kiuj ĉi tiu atestilo estis akceptita. Niaflanke, ni sciigos uzantojn, kiuj aliras poŝton per vundeblaj aparatoj.

PS Estas ankaŭ rilata vundebleco priskribita en la afiŝo LukaSafonov "Backport vundebleco en RouterOS metas centojn da miloj da aparatoj en risko".

fonto: www.habr.com

Aldoni komenton