Večer 10. marca začala podporná služba Mail.ru dostávať sťažnosti od používateľov na nemožnosť pripojenia k serverom Mail.ru IMAP/SMTP prostredníctvom e-mailových programov. Zároveň niektoré pripojenia neprešli a niektoré vykazujú chybu certifikátu. Chyba je spôsobená tým, že „server“ vydáva certifikát TLS s vlastným podpisom.
Za dva dni prišlo viac ako 10 sťažností od používateľov v rôznych sieťach a s rôznymi zariadeniami, takže je nepravdepodobné, že by bol problém v sieti ktoréhokoľvek poskytovateľa. Podrobnejšia analýza problému odhalila, že server imap.mail.ru (ako aj ďalšie poštové servery a služby) sa nahrádza na úrovni DNS. Ďalej sme s aktívnou pomocou našich používateľov zistili, že dôvodom bol nesprávny záznam vo vyrovnávacej pamäti ich routera, ktorý je zároveň lokálnym DNS resolverom a ktorý sa v mnohých (nie však vo všetkých) prípadoch ukázal ako MikroTik. zariadenie, veľmi obľúbené v malých podnikových sieťach a od malých poskytovateľov internetu.
Aký je problém
V septembri 2019 výskumníci niekoľko zraniteľností v MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), ktoré umožňovali útok DNS cache poisoning, t.j. schopnosť sfalšovať záznamy DNS vo vyrovnávacej pamäti DNS smerovača a CVE-2019-3978 umožňuje útočníkovi nečakať, kým niekto z internej siete požiada o záznam na jeho serveri DNS, aby otrávil vyrovnávaciu pamäť resolvera, ale iniciovať takýto žiadosť cez port 8291 (UDP a TCP). Zraniteľnosť bola opravená spoločnosťou MikroTik vo verziách RouterOS 6.45.7 (stabilná) a 6.44.6 (dlhodobá) 28. októbra 2019, ale podľa Väčšina používateľov momentálne nemá nainštalované záplaty.
Je zrejmé, že tento problém sa v súčasnosti aktívne „naživo“ využíva.
Prečo je to nebezpečné?
Útočník môže sfalšovať záznam DNS akéhokoľvek hostiteľa, ku ktorému pristupuje používateľ v internej sieti, a tým zachytí prenos naň. Ak sa citlivé informácie prenášajú bez šifrovania (napríklad cez http:// bez TLS) alebo používateľ súhlasí s akceptovaním falošného certifikátu, útočník môže získať všetky údaje, ktoré sa odosielajú cez pripojenie, ako napríklad prihlasovacie meno alebo heslo. Žiaľ, prax ukazuje, že ak má používateľ možnosť akceptovať falošný certifikát, využije to.
Prečo servery SMTP a IMAP a čo zachránilo používateľov
Prečo sa útočníci pokúšali zachytiť SMTP/IMAP prevádzku e-mailových aplikácií, a nie webovú prevádzku, hoci väčšina používateľov pristupuje k svojej pošte cez HTTPS prehliadač?
Nie všetky e-mailové programy pracujúce cez SMTP a IMAP/POP3 chránia používateľa pred chybami a bránia mu v odoslaní prihlasovacieho mena a hesla cez nezabezpečené alebo kompromitované pripojenie, hoci podľa štandardu , prijaté ešte v roku 2018 (a implementované na Mail.ru oveľa skôr), musia chrániť používateľa pred zachytením hesla prostredníctvom akéhokoľvek nezabezpečeného pripojenia. Okrem toho sa protokol OAuth veľmi zriedka používa v e-mailových klientoch (podporujú ho poštové servery Mail.ru) a bez neho sa prihlasovacie meno a heslo prenášajú v každej relácii.
Prehliadače môžu byť o niečo lepšie chránené pred útokmi typu Man-in-the-Middle. Vo všetkých kritických doménach mail.ru je okrem HTTPS povolená aj politika HSTS (prísne zabezpečenie prenosu HTTP). S povoleným HSTS moderný prehliadač nedáva používateľovi jednoduchú možnosť akceptovať falošný certifikát, aj keď používateľ chce. Okrem HSTS používateľov zachránila skutočnosť, že od roku 2017 servery SMTP, IMAP a POP3 Mail.ru zakazujú prenos hesiel cez nezabezpečené pripojenie, všetci naši používatelia používali TLS na prístup cez SMTP, POP3 a IMAP a preto môže byť prihlasovacie meno a heslo zachytené iba vtedy, ak používateľ sám súhlasí s prijatím falošného certifikátu.
Pre mobilných používateľov vždy odporúčame používať na prístup k pošte aplikácie Mail.ru, pretože... práca s poštou v nich je bezpečnejšia ako v prehliadačoch alebo vstavaných SMTP/IMAP klientoch.
Čo robiť
Firmvér MikroTik RouterOS je potrebné aktualizovať na zabezpečenú verziu. Ak to z nejakého dôvodu nie je možné, je potrebné filtrovať prevádzku na porte 8291 (tcp a udp), skomplikuje to využitie problému, ale neodstráni možnosť pasívneho vstrekovania do vyrovnávacej pamäte DNS. Poskytovatelia internetových služieb by mali tento port vo svojich sieťach filtrovať, aby ochránili podnikových používateľov.
Všetci používatelia, ktorí prijali náhradný certifikát, by si mali urýchlene zmeniť heslo pre e-mail a iné služby, pre ktoré bol tento certifikát akceptovaný. Z našej strany upozorníme používateľov, ktorí pristupujú k pošte cez zraniteľné zariadenia.
PS V príspevku je opísaná aj súvisiaca zraniteľnosť "".
Zdroj: hab.com