Kovo 10 d. vakare Mail.ru palaikymo tarnyba pradėjo gauti vartotojų skundų dėl nesugebėjimo prisijungti prie Mail.ru IMAP/SMTP serverių per el. pašto programas. Tuo pačiu metu kai kurie ryšiai nevyko, o kai kurie rodo sertifikato klaidą. Klaida atsirado dėl to, kad „serveris“ išduoda savarankiškai pasirašytą TLS sertifikatą.
Per dvi dienas gauta daugiau nei 10 skundų iš įvairių tinklų ir įvairių įrenginių naudotojų, todėl mažai tikėtina, kad problema buvo vieno tiekėjo tinkle. Išsamesnė problemos analizė atskleidė, kad serveris imap.mail.ru (kaip ir kiti pašto serveriai bei paslaugos) yra keičiamas DNS lygiu. Be to, aktyviai padedant mūsų vartotojams, nustatėme, kad priežastis buvo neteisingas įrašas jų maršrutizatoriaus talpykloje, kuri taip pat yra vietinis DNS sprendėjas ir daugeliu (bet ne visais) atvejų buvo MikroTik. įrenginys, labai populiarus mažuose įmonių tinkluose ir iš mažų interneto tiekėjų.
Kokia problema
2019 metų rugsėjo mėn keletas MikroTik RouterOS spragų (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), kurios leido įvykdyti DNS talpyklos apsinuodijimo ataką, t.y. galimybė suklastoti DNS įrašus maršrutizatoriaus DNS talpykloje, o CVE-2019-3978 leidžia užpuolikui nelaukti, kol kas nors iš vidinio tinklo paprašys įrašo į jo DNS serverį, kad būtų užnuodytas sprendiklio talpyklos atmintis, o inicijuoti tokius veiksmus. pats užklausa per prievadą 8291 (UDP ir TCP). MikroTik pažeidžiamumą ištaisė RouterOS 6.45.7 (stabilios) ir 6.44.6 (ilgalaikės) versijose 28 m. spalio 2019 d., tačiau pagal Dauguma vartotojų šiuo metu nėra įdiegę pataisų.
Akivaizdu, kad ši problema dabar aktyviai išnaudojama „gyvai“.
Kodėl tai pavojinga
Užpuolikas gali suklaidinti bet kurio pagrindinio kompiuterio, prie kurio prisijungė vartotojas vidiniame tinkle, DNS įrašą, taip perimdamas srautą į jį. Jei slapta informacija perduodama be šifravimo (pavyzdžiui, per http:// be TLS) arba vartotojas sutinka priimti netikrą sertifikatą, užpuolikas gali gauti visus per ryšį siunčiamus duomenis, pvz., prisijungimo vardą arba slaptažodį. Deja, praktika rodo, kad jei vartotojas turi galimybę priimti netikrą sertifikatą, jis ja pasinaudos.
Kodėl SMTP ir IMAP serveriai ir kas išgelbėjo vartotojus
Kodėl užpuolikai bandė perimti el. pašto programų SMTP/IMAP srautą, o ne žiniatinklio srautą, nors dauguma vartotojų savo paštą pasiekia per HTTPS naršyklę?
Ne visos el. pašto programos, veikiančios per SMTP ir IMAP/POP3, apsaugo vartotoją nuo klaidų, neleidžiant jam siųsti prisijungimo vardo ir slaptažodžio per nesaugų ar pažeistą ryšį, nors pagal standartą , priimtas dar 2018 m. (ir įdiegtas Mail.ru daug anksčiau), jie turi apsaugoti vartotoją nuo slaptažodžio perėmimo per bet kokį neapsaugotą ryšį. Be to, el. pašto programose OAuth protokolas naudojamas labai retai (jį palaiko Mail.ru pašto serveriai), o be jo prisijungimo vardas ir slaptažodis perduodami kiekvienoje sesijoje.
Naršyklės gali būti šiek tiek geriau apsaugotos nuo „Man-in-the-Middle“ atakų. Visuose svarbiuose mail.ru domenuose, be HTTPS, įjungta ir HSTS (HTTP griežtos transporto saugos) politika. Įjungus HSTS, šiuolaikinė naršyklė nesuteikia vartotojui lengvos galimybės priimti netikrą sertifikatą, net jei vartotojas to nori. Be HSTS, vartotojus išgelbėjo tai, kad nuo 2017 m. Mail.ru SMTP, IMAP ir POP3 serveriai draudžia perduoti slaptažodžius nesaugiu ryšiu, visi mūsų vartotojai naudojo TLS prieigai per SMTP, POP3 ir IMAP ir todėl prisijungimas ir slaptažodis gali perimti tik tuo atveju, jei vartotojas pats sutinka priimti suklastotą sertifikatą.
Mobiliųjų telefonų vartotojams visada rekomenduojame naudoti Mail.ru programas, kad pasiektumėte paštą, nes... dirbti su paštu juose yra saugiau nei naršyklėse ar integruotose SMTP/IMAP programose.
Ką daryti
Būtina atnaujinti MikroTik RouterOS programinę-aparatinę įrangą į saugią versiją. Jei dėl kokių nors priežasčių tai neįmanoma, būtina filtruoti srautą prie 8291 prievado (tcp ir udp), tai apsunkins problemos išnaudojimą, nors tai nepanaikins pasyvios injekcijos į DNS talpyklą galimybės. IPT turėtų filtruoti šį prievadą savo tinkluose, kad apsaugotų įmonių vartotojus.
Visi vartotojai, kurie priėmė pakeistą sertifikatą, turėtų skubiai pakeisti el. pašto ir kitų paslaugų, kurioms šis sertifikatas buvo priimtas, slaptažodį. Savo ruožtu informuosime vartotojus, kurie pasiekia paštą per pažeidžiamus įrenginius.
PS Taip pat yra susijęs pažeidžiamumas, aprašytas pranešime "".
Šaltinis: www.habr.com