U večernjim satima 10. ožujka korisnička podrška Mail.ru počela je primati pritužbe korisnika o nemogućnosti povezivanja na IMAP/SMTP poslužitelje Mail.ru putem poštanskih programa. Prilikom toga, neki od povezanih pokušaja nisu prolazili, dok su drugi prikazivali grešku certifikata. Greška je uzrokovana time što „poslužitelj“ pruža samo-potpisani TLS certifikat.
Tijekom dva dana zaprimljeno je više od 10 pritužbi korisnika iz raznih mreža i s raznim uređajima, što je činilo malo vjerojatnim da je problem u mreži nekog jednoga davatelja usluga. Detaljnija analiza problema pokazala je da dolazi do zamjene poslužitelja imap.mail.ru (kao i drugih poštanskih poslužitelja i usluga) na razini DNS-a. Zatim, uz aktivnu pomoć naših korisnika, otkrili smo da je uzrok u pogrešnom unosu u predmemoriji njihovog usmjerivača, koji je ujedno služio kao lokalni DNS resolver, a koja je u mnogim (ali ne svim) slučajevima bilo uređaj MikroTik, vrlo popularan u malim korporativnim mrežama i među malim davateljima internetskih usluga.
Koji je problem
U rujnu 2019. godine, istraživači. nekoliko ranjivosti u MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), koje su omogućavale DNS cache poisoning napad, tj. mogućnost zamjene DNS zapisa u DNS predmemoriji usmjerivača, a CVE-2019-3978 omogućava napadaču da ne čeka da netko iz unutarnje mreže zatraži unos sa svog DNS poslužitelja kako bi otrovao predmemoriju resolvera, već da sam pokrene takav zahtjev putem porta 8291 (UDP i TCP). Ranjivost je ispravljena od strane MikroTik-a u verzijama RouterOS 6.45.7 (stabilna) i 6.44.6 (dugoročna) 28. listopada 2019., međutim, prema veći dio korisnika trenutno nije instalirao zakrpe.
Očigledno je da se sada ovaj problem aktivno iskorištava "u živo".
Kako to može biti opasno
Napadač može zamijeniti DNS zapis bilo kojeg hosta na koji se korisnik iz unutarnje mreže obraća, time presrećući promet prema njemu. Ako se osjetljive informacije šalju bez enkripcije (npr. putem http:// bez TLS-a) ili korisnik pristane prihvatiti lažni certifikat, napadač može dobiti sve podatke koji se šalju kroz vezu, kao što su korisničko ime ili lozinka. Nažalost, praksa pokazuje da ako korisnik ima mogućnost prihvatiti lažni certifikat, tada će je iskoristiti.
Zašto baš SMTP i IMAP poslužitelji, i što je štitilo korisnike
Zašto su napadači pokušavali presresti upravo SMTP/IMAP promet e-poštanskih aplikacija, a ne web promet, iako većina korisnika pristupa pošti putem preglednika koristeći HTTPS?
Nisu sve e-poštanske aplikacije koje koriste SMTP i IMAP/POP3 zaštitile korisnika od pogreške, onemogućujući mu slanje korisničkog imena i lozinke putem nesigurne ili kompromitirane veze, iako prema standardu , usvojenom 2018. (a provedenom u Mail.ru mnogo ranije), trebale bi štititi korisnika od presretanja lozinke putem bilo koje nezaštićene veze. Osim toga, dok se u e-poštnim klijentima vrlo rijetko koristi OAuth protokol (koji podržavaju e-poštanski poslužitelji Mail.ru), bez njega se korisničko ime i lozinka prenose u svakoj sesiji.
Preglednici mogu biti malo bolje zaštićeni od napada Man-in-the-Middle. Na svim kritičnim domenima mail.ru pored HTTPS-a uključena je HSTS politika (HTTP stroga sigurnost prijenosa). Kada je HSTS uključen, moderni preglednik ne daje korisniku jednostavnu mogućnost prihvaćanja lažnog certifikata, čak i ako korisnik to želi. Osim HSTS-a, korisnicima je pomoglo i to što od 2017. godine SMTP, IMAP i POP3 poslužitelji Mail.ru zabranjuju prijenos lozinke putem nezaštićene veze, svi naši korisnici koristili su TLS za pristup putem SMTP, POP3 i IMAP, pa se lozinka i korisničko ime mogu presresti samo ako korisnik sam pristane prihvatiti zamijenjeni certifikat.
Za mobilne korisnike uvijek preporučujemo korištenje Mail.ru aplikacija za pristup e-pošti, jer je rad s poštom u njima sigurniji nego u preglednicima ili ugrađenim SMTP/IMAP klijentima.
Što treba učiniti
Potrebno je ažurirati firmware MikroTik RouterOS na sigurnu verziju. Ako to iz bilo kojeg razloga nije moguće, potrebno je filtrirati promet na portu 8291 (tcp i udp), što će otežati iskorištavanje problema, iako neće otkloniti mogućnost pasivne injekcije u DNS cache. Internet provajderi trebaju filtrirati ovaj port u svojim mrežama kako bi zaštitili korporativne korisnike.
Svi korisnici koji su prihvatili zamijenjeni certifikat trebaju hitno promijeniti lozinku e-pošte i drugih servisa za koje je taj certifikat prihvaćen. S naše strane, obavijestit ćemo korisnike koji se prijavljuju na e-poštu putem ranjivih uređaja.
P.S. Postoji još jedna povezana ranjivost opisana u postu "".
Izvor: habr.com
