Večer 10. marca je podpora Mail.ru začela prejemati pritožbe uporabnikov o nemogočem povezovanju s IMAP/SSMTP strežniki Mail.ru prek e-poštnih programov. Pri tem del povezav ni deloval, del pa je prikazoval napako certifikata. Napako je povzročil dejstvo, da «strežnik» izda samopodpisan certifikat TLS.
V dveh dneh je prišlo več kot 10 pritožb uporabnikov iz različnih omrežij in z različnimi napravami, kar je naredilo malo verjetnim, da gre za težavo v omrežju enega samega ponudnika. Podrobnejša analiza problema je razkrila, da se na ravni DNS dogaja zamenjava strežnika imap.mail.ru (pa tudi drugih e-poštnih strežnikov in storitev). Kasneje smo ob aktivni pomoči naših uporabnikov ugotovili, da je vzrok v napačni zapisani keširni datoteki njihovega usmerjevalnika, ki obenem služi kot lokalni DNS resolver, pri čemer je v mnogih (a ne vseh) primerih to naprava MikroTik, zelo priljubljena v majhnih podjetniških omrežjih in med malimi internetnimi ponudniki.
Kakšen je problem
U septembru 2019. istraživači nekatere ranljivosti v MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), ki so omogočale napad z zastrupljanjem DNS predpomnilnika, tj. možnost zamenjave DNS zapisov v DNS predpomnilniku usmerjevalnika, pri čemer CVE-2019-3978 napadalcu omogoča, da ne čaka, da se kdo iz notranjega omrežja obrne na njegov DNS strežnik, da bi zastrupil predpomnilnik resolverja, temveč lahko sproži to zahtevo sam preko vrat 8291 (UDP in TCP). Ranljivost so popravili pri MikroTik v različicah RouterOS 6.45.7 (stabilno) in 6.44.6 (dolgo obdobje) 28. oktobra 2019, vendar je po navedbah večina uporabnikov trenutno ni namestila popravkov.
Očitno je, da se ta težava trenutno aktivno izkorišča v »živem« okolju.
Zakaj je to nevarno
Napadalec lahko zamenja DNS zapis katerega koli gostitelja, ki ga kliče uporabnik notranjega omrežja, in tako ujame promet do njega. Če se občutljive informacije prenašajo brez šifriranja (na primer preko http:// brez TLS) ali če uporabnik privoli v sprejem lažnega certifikata, lahko napadalec pridobi vse podatke, ki se prenesejo preko povezave, na primer prijavno ime ali geslo. Na žalost praksa kaže, da če ima uporabnik možnost sprejeti lažni certifikat, jo bo izkoristil.
Zakaj prav SMTP in IMAP strežniki, in kaj je rešilo uporabnike
Zakaj so napadalci poskušali prestreči prav SMTP/IMAP promet e-poštnih aplikacij in ne spletni promet, kljub temu da večina uporabnikov dostopa do e-pošte prek brskalnika po HTTPS?
Ne vse e-poštne aplikacije, ki delujejo prek SMTP in IMAP/POP3, zaščitijo uporabnika pred napakami, tako da mu preprečijo pošiljanje prijavnimi podatki prek nezavarovane ali kompromitirane povezave, čeprav po standardu , sprejetem že leta 2018 (in implementiranem v Mail.ru precej prej), bi morale zaščititi uporabnika pred prestrezanjem gesla prek katerekoli nezaščitene povezave. Poleg tega se protokol OAuth v e-poštnih odjemalcih redko uporablja (podpirajo ga e-poštni strežniki Mail.ru), brez njega pa se prijavni podatki prenašajo v vsakem sejmu.
Brskalniki so nekoliko bolje zaščiteni pred napadi Man-in-the-Middle. Na vseh kritičnih domenah mail.ru je poleg HTTPS vključena tudi politika HSTS (HTTP stroga varnost prevoza). Ob vklopljenem HSTS modereren brskalnik ne omogoča uporabniku enostavne možnosti sprejema ponarejenega certifikata, tudi če si to uporabnik želi. Poleg HSTS so uporabnike reševale tudi dejstvo, da od leta 2017 strežniki SMTP, IMAP in POP3 Mail.ru prepovedujejo prenos gesla prek nezaščitene povezave, vsi naši uporabniki pa so uporabljali TLS za dostop prek SMTP, POP3 in IMAP, zato so prijavni podatki lahko bili prestreženi le, če se uporabnik sam strinja s sprejemom ponarejenega certifikata.
Za mobilne uporabnike vedno priporočamo uporabo aplikacij Mail.ru za dostop do e-pošte, saj je delo z e-pošto v njih varnejše kot v brskalnikih ali v vgrajenih SMTP/IMAP odjemalcih.
Kaj je treba storiti
Potrebno je posodobiti programsko opremo MikroTik RouterOS na varno različico. Če to iz kakršnega koli razloga ni mogoče, je treba filtrirati promet po prenosnem portu 8291 (tcp in udp), kar otežuje reševanje težave, ne odpravi pa možnosti pasivne injekcije v DNS predpomnilnik. Internetni ponudniki naj filtrirajo ta port v svojih omrežjih, da zaščitijo poslovne uporabnike.
Vsem uporabnikom, ki so sprejeli ponarejen certifikat, je nujno treba spremeniti geslo za e-pošto in druge storitve, za katere je bil ta certifikat sprejet. S svoje strani bomo obvestili uporabnike, ki dostopajo do e-pošte prek ranljivih naprav.
P.S. Obstaja še ena povezana ranljivost, opisana v objavi "".
Izvor: habr.com
