Posodobite RouterOS na vašem MikroTiku

Posodobite RouterOS na vašem MikroTiku
10. marca zvečer je služba za podporo Mail.ru začela prejemati pritožbe uporabnikov o nezmožnosti povezave s strežniki IMAP/SMTP Mail.ru prek e-poštnih programov. Hkrati nekatere povezave niso uspele, nekatere pa kažejo napako potrdila. Napako povzroči "strežnik", ki izda samopodpisano potrdilo TLS.
 
Posodobite RouterOS na vašem MikroTiku
V dveh dneh je prišlo več kot 10 pritožb uporabnikov v najrazličnejših omrežjih in z različnimi napravami, zaradi česar je malo verjetno, da bi bila težava v omrežju katerega koli ponudnika. Podrobnejša analiza problema je pokazala, da se strežnik imap.mail.ru (pa tudi drugi poštni strežniki in storitve) zamenja na ravni DNS. Nadalje smo z aktivno pomočjo naših uporabnikov ugotovili, da je bil razlog napačen vnos v predpomnilnik njihovega usmerjevalnika, ki je tudi lokalni razreševalec DNS in se je v mnogih (vendar ne vseh) primerih izkazalo, da je MikroTik naprava, zelo priljubljena v omrežjih majhnih podjetij in pri majhnih internetnih ponudnikih.

V čem je problem

Septembra 2019 so raziskovalci najdeno več ranljivosti v MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), ki so omogočile napad z zastrupitvijo predpomnilnika DNS, tj. zmožnost ponarejanja zapisov DNS v predpomnilniku DNS usmerjevalnika, CVE-2019-3978 pa napadalcu omogoča, da ne čaka, da nekdo iz notranjega omrežja zahteva vnos na njegovem strežniku DNS, da bi zastrupil predpomnilnik razreševalca, ampak sproži tako sam zahteva prek vrat 8291 (UDP in TCP). Ranljivost je MikroTik odpravil v različicah RouterOS 6.45.7 (stabilna) in 6.44.6 (dolgoročna) 28. oktobra 2019, vendar glede na raziskave Večina uporabnikov trenutno še ni namestila popravkov.

Očitno je, da se ta problem zdaj aktivno izkorišča »v živo«.

Zakaj je nevarno

Napadalec lahko ponaredi zapis DNS katerega koli gostitelja, do katerega dostopa uporabnik v notranjem omrežju, in tako prestreže promet do njega. Če se občutljivi podatki prenašajo brez šifriranja (na primer prek http:// brez TLS) ali se uporabnik strinja, da bo sprejel ponarejeno potrdilo, lahko napadalec pridobi vse podatke, ki so poslani prek povezave, na primer prijavo ali geslo. Na žalost praksa kaže, da če ima uporabnik možnost sprejeti ponarejeno potrdilo, jo bo izkoristil.

Zakaj strežnika SMTP in IMAP in kaj je rešilo uporabnike

Zakaj so napadalci poskušali prestreči promet SMTP/IMAP e-poštnih aplikacij in ne spletnega prometa, čeprav večina uporabnikov do svoje pošte dostopa prek brskalnika HTTPS?

Vsi e-poštni programi, ki delujejo prek SMTP in IMAP/POP3, ne ščitijo uporabnika pred napakami in mu preprečujejo pošiljanje prijave in gesla prek nezaščitene ali ogrožene povezave, čeprav po standardu RFC 8314, sprejet že leta 2018 (in implementiran v Mail.ru veliko prej), morajo zaščititi uporabnika pred prestrezanjem gesla prek katere koli nezavarovane povezave. Poleg tega se protokol OAuth zelo redko uporablja v e-poštnih odjemalcih (podpirajo ga poštni strežniki Mail.ru), brez njega pa se prijava in geslo prenašata v vsaki seji.

Brskalniki so morda malo bolje zaščiteni pred napadi Man-in-the-Middle. Na vseh kritičnih domenah mail.ru je poleg HTTPS omogočen pravilnik HSTS (HTTP strict transport security). Z omogočenim HSTS sodoben brskalnik uporabniku ne daje enostavne možnosti, da sprejme lažno potrdilo, tudi če uporabnik to želi. Poleg HSTS je uporabnike rešilo dejstvo, da od leta 2017 strežniki SMTP, IMAP in POP3 družbe Mail.ru prepovedujejo prenos gesel prek nezaščitene povezave, vsi naši uporabniki so za dostop prek SMTP, POP3 in IMAP uporabljali TLS ter zato lahko prijavo in geslo prestrežeta le, če se uporabnik sam strinja, da sprejme lažno potrdilo.

Mobilnim uporabnikom vedno priporočamo uporabo aplikacij Mail.ru za dostop do pošte, ker... delo s pošto v njih je varnejše kot v brskalnikih ali vgrajenih odjemalcih SMTP/IMAP.

Kaj storiti

Firmware MikroTik RouterOS je treba posodobiti na varno različico. Če iz nekega razloga to ni mogoče, je treba filtrirati promet na vratih 8291 (tcp in udp), kar bo otežilo izkoriščanje težave, vendar ne bo odpravilo možnosti pasivnega vbrizgavanja v predpomnilnik DNS. Ponudniki internetnih storitev bi morali filtrirati ta vrata v svojih omrežjih, da zaščitijo poslovne uporabnike. 

Vsi uporabniki, ki so sprejeli zamenjano potrdilo, naj nujno spremenijo geslo za elektronsko pošto in druge storitve, za katere je bilo to potrdilo sprejeto. Z naše strani bomo obvestili uporabnike, ki do pošte dostopajo prek ranljivih naprav.

PS V objavi je opisana tudi povezana ranljivost LukaSafonov "Ranljivost povratnih vrat v sistemu RouterOS ogroža več sto tisoč naprav".

Vir: www.habr.com

Dodaj komentar