Uuendage RouterOS oma MikroTik-is

10. märtsil hakkas Mail.ru tugiteenistus saama kaebusi, et kasutajad ei pääse Mail.ru IMAP/SMTP serveritesse oma e-posti programmide kaudu. Samal ajal ei läbinud osa ühendustest, samas kui teised näitasid sertifikaadi viga. Viga tekkis seetõttu, et "server" väljastas isesertifitseeritud TLS-sertifikaadi.
 

Kaks päeva hiljem sai rohkem kui 10 kaebust erinevatelt kasutajatelt erinevatest võrkudest ja erinevatelt seadmetelt, mis välistas ühe teenusepakkuja võrguprobleemide tõenäosuse. Probleemi põhjalikum analüüs näitas, et imap.mail.ru (nagu ka teiste e-posti serverite ja teenuste) server on DNS tasandil asendatud. Edasistes uuringutes, kus meie kasutajad aktiivselt aitasid, avastasime, et probleem seisneb vale salvestuses nende ruuteri vahemikus, mis on samal ajal kohaliku DNS-resolverina, ja millest paljudes (aga mitte kõigis) juhtudel on MikroTiki seade, mis on väga populaarne väikestes ettevõtetes ja väikestes Interneti-teenusepakkujates.

Mis on probleem

2019. aasta septembris avastasid teadlased avastasime mitmeid haavatavusi MikroTik RouterOS-is (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), mis võimaldasid DNS cache poisoning rünnakut, st DNS-kirjete asendamist ruuteri DNS-vahemikus, ja CVE-2019-3978 võimaldab ründajal mitte oodata, kuni keegi sisemistest võrgust pöördub selle DNS-serveri poole, et mürgitada resolveri vahemikku, vaid algatada sellise päringu ise porti 8291 (UDP ja TCP) kaudu. MikroTik parandas haavatavuse versioonides RouterOS 6.45.7 (stabiilne) ja 6.44.6 (pikaajaline) 28. oktoobril 2019, kuid vastavalt uuringutele enamik kasutajatest ei ole praeguseks uuendusi paigaldanud.

On ilmne, et hetkel seda probleemi kasutatakse aktiivselt "reaalses elus".

Miks see on ohtlik

Ründaja võib asendada DNS-kirje mistahes hostile, mille poole pöördub kasutaja sisemises võrgus, nii et ta püüab selle poole liiklust. Kui tundlik teave edastatakse krüptimata (näiteks http:// ilma TLS-ita) või kasutaja nõustub vale sertifikaadi vastuvõtmisega, võib ründaja saada kõik andmed, mis saadetakse ühenduse kaudu, näiteks kasutajanime või parooli. Kahjuks näitab praktika, et kui kasutajal on võimalus vale sertifikaadiga nõustuda, siis ta seda ka teeb.

Miks just SMTP ja IMAP serverid ning mis päästis kasutajad

Miks ründajad üritasid just SMTP/IMAP liiklust e-posti rakendustes töödelda, mitte sihtida veebiliiklust, kuigi suurem osa kasutajatest pääseb e-kirjadele juurde brauseri kaudu HTTPS-i abil?

Kaupade ja teenuste tarnijad, mis kasutavad SMTP ja IMAP/POP3, ei kaitse alati kasutajat vigade eest, lubades tal saata oma sisselogimisandmed ebaturvalise või kompromiteeritud ühenduse kaudu, hoolimata standardist RFC 8314, mis võeti vastu juba 2018. aastal (ja realiseeriti Mail.ru-s palju varem), peaks need kasutajad kaitsma mis tahes kaitsmata ühenduse kaudu paroolide röövimise eest. Lisaks sellele kasutatakse e-posti klientides praegu väga harva protokolli OAuth (seda toetavad Mail.ru e-posti serverid), ja ilma selleta edastatakse sisselogimisandmed igas seansis.

Sirvijad võivad olla veidi paremini kaitstud Man-in-the-Middle rünnakute eest. Kõikidel olulistel domeenidel, sealhulgas mail.ru, on lisaks HTTPS-ile rakendatud HSTS (HTTP range transport security) poliitika. Kui HSTS on sisse lülitatud, ei luba kaasaegne sirvija kasutajal lihtsalt vastu võtta vale sertifikaati, isegi kui kasutaja seda soovib. HSTS-i kõrval on kasutajaid kaitsnud ka see, et alates 2017. aastast keelavad Mail.ru SMTP, IMAP ja POP3 serverid parooli edastamise ebaturvalise ühenduse kaudu; kõik meie kasutajad kasutasid TLS-i SMTP, POP3 ja IMAP-iga juurde pääsemiseks, seetõttu saab sisselogimisandmed röövida ainult siis, kui kasutaja nõustub vale sertifikaadi aktsepteerimisega.

Mobiilikasutajatele soovitame alati kasutada Mail.ru rakendusi, et pääseda e-kirjale juurde, kuna nende kaudu on e-kirjade haldamine turvalisem kui sirvijates või sisseehitatud SMTP/IMAP klientides.

Mida on vaja teha

MikroTik RouterOS-i tarkvara tuleb uuendada turvalisse versiooni. Kui mingil põhjusel ei ole see võimalik, tuleb filtreerida liiklus sadamal 8291 (tcp ja udp), see muudab probleemi haldamise keerulisemaks, kuigi see ei likvideeri võimalust passiivseks süstimiseks DNS-i vahemälu. Internetiteenuse pakkujatel on soovitatav seda sadamat oma võrgus filtreerida, et kaitsta ärikasutajaid. 

Kasutajad, kes on aktsepteerinud vale sertifikaati, peaksid koheselt vahetama oma e-posti ja teiste teenuste parooli, mille puhul see sertifikaat kasutusele võeti. Me omalt poolt teavitame neid kasutajaid, kes pääsevad e-kirjadele juurde haavatavates seadmetes.

P.S. On veel seotud haavatavus, mis on toodud postituses. LukaSafonov "RouterOSi backport-haavatus seab ohvriks sadu tuhandeid seadmeid".

Allikas: habr.com