În seara zilei de 10 martie, serviciul de suport Mail.ru a început să primească plângeri de la utilizatori cu privire la imposibilitatea de a se conecta la serverele IMAP/SMTP Mail.ru prin intermediul aplicațiilor de e-mail. Unele conexiuni nu reușeau să treacă, în timp ce altele afișau o eroare de certificat. Eroarea a fost cauzată de faptul că „serverul” returna un certificat TLS auto-semnat.
În decurs de două zile, au sosit peste 10 plângeri de la utilizatori din cele mai diverse rețele și cu dispozitive variate, ceea ce făcea puțin probabil ca problema să fie legată de rețeaua unui anumit furnizor. O analiză mai detaliată a problemei a relevat că serverul imap.mail.ru (și alte servere și servicii de e-mail) era înlocuit la nivel DNS. Ulterior, cu ajutorul activ al utilizatorilor noștri, am descoperit că problema se afla într-o înregistrare greșită în cache-ul routerului lor, care este de asemenea un rezolvator DNS local, iar în multe (dar nu toate) cazuri, dispozitivul era MikroTik, foarte popular în rețelele mici de afaceri și la furnizorii de internet mici.
Care este problema
În septembrie 2019, cercetătorii câteva vulnerabilități în MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), care permiteau atacuri de tip DNS cache poisoning, adică posibilitatea de a înlocui înregistrările DNS în cache-ul routerului; în plus, CVE-2019-3978 permite atacatorului să nu aștepte ca cineva din rețeaua internă să solicite o înregistrare de la serverul său DNS, ci să inițieze el însuși o astfel de solicitare prin portul 8291 (UDP și TCP). Vulnerabilitatea a fost corectată de MikroTik în versiunile RouterOS 6.45.7 (stabil) și 6.44.6 (pe termen lung) pe 28 octombrie 2019, însă, conform majoritatea utilizatorilor în prezent nu au aplicat patch-urile.
Este evident că acum această problemă este exploatată activ „live”.
De ce este aceasta periculoasă
Atacatorul poate modifica înregistrarea DNS a oricărui host la care se conectează un utilizator din rețeaua internă, interceptând astfel traficul către acel host. Dacă informații sensibile sunt transmise fără criptare (de exemplu, prin http:// fără TLS) sau utilizatorul acceptă un certificat fals, atacatorul poate obține toate datele transmise prin conexiune, cum ar fi numele de utilizator sau parola. Din păcate, practica arată că, dacă utilizatorul are opțiunea de a accepta un certificat fals, acest lucru va fi folosit.
De ce anume serverele SMTP și IMAP, și ce i-a protejat pe utilizatori
De ce atacatorii au încercat să intercepteze traficul SMTP/IMAP al aplicațiilor de email și nu traficul web, deși cea mai mare parte a utilizatorilor accesează emailul prin browser folosind HTTPS?
Nu toate programele de email care funcționează pe baza SMTP și IMAP/POP3 protejează utilizatorul de eroare, permițându-i să-și trimită loginul și parola printr-o conexiune nesigură sau compromisă, deși conform standardului , adoptat în 2018 (și implementat în Mail.ru mult mai devreme), acestea ar trebui să protejeze utilizatorul de interceptarea parolei prin orice conexiune nesecurizată. În plus, în prezent, în clienții de email se folosește foarte rar protocolul OAuth (acesta este suportat de serverele de email Mail.ru), iar fără acesta, loginul și parola sunt transmise în fiecare sesiune.
Broserele pot fi puțin mai bine protejate împotriva atacurilor Man-in-the-Middle. Pe toate domeniile critice mail.ru, pe lângă HTTPS, este activată politica HSTS (HTTP strict transport security). Când HSTS este activat, un browser modern nu permite utilizatorului o opțiune simplă de a accepta un certificat fals, chiar dacă utilizatorul dorește acest lucru. Pe lângă HSTS, utilizatorii au fost salvați de faptul că, începând cu 2017, serverele SMTP, IMAP și POP3 Mail.ru interzic transmiterea parolei printr-o conexiune nesecurizată; toți utilizatorii noștri au utilizat TLS pentru accesul prin SMTP, POP3 și IMAP, iar prin urmare, loginul și parola pot fi interceptate doar dacă utilizatorul însuși este de acord să accepte un certificat falsificat.
Pentru utilizatorii mobili, întotdeauna recomandăm să folosească aplicațiile Mail.ru pentru accesul la email, deoarece lucrul cu emailul în acestea este mai sigur decât în browsere sau în clienții SMTP/IMAP încorporați.
Ce trebuie făcut
Este necesară actualizarea firmware-ului MikroTik RouterOS la o versiune sigură. Dacă din orice motiv aceasta nu este posibilă, este necesar să se filtreze traficul pe portul 8291 (tcp și udp), acest lucru va îngreuna exploatarea problemei, deși nu va elimina posibilitatea de injecție pasivă în cache-ul DNS. Furnizorii de internet ar trebui să filtreze acest port în rețelele lor pentru a proteja utilizatorii corporativi.
Toți utilizatorii care au acceptat certificatul falsificat ar trebui să schimbe urgent parola de email și a altor servicii pentru care acest certificat a fost acceptat. Din partea noastră, vom informa utilizatorii care accesează emailul prin dispozitive vulnerabile.
P.S. Există o vulnerabilitate asociată, descrisă în postare "".
Sursa: habr.com
