Më 10 mars, në mbrëmje, shërbimi i mbështetjes së Mail.ru filloi të merrte ankesa nga përdoruesit për pamundësinë e lidhjes me serverët IMAP/SMTP të Mail.ru përmes programeve të postës elektronike. Disa lidhje nuk funksiononin, ndërsa disa të tjerë tregonin një gabim certifikate. Gabimi shkaktohej nga fakti se "serveri" jep një certifikatë TLS të vetë-nënshkruar.
Në dy ditët në vijim, mbërritën më shumë se 10 ankesa nga përdorues të rrjeteve të ndryshme dhe nga pajisje të ndryshme, që e bënte të pakëndshme problemin nga ndonjë provajder të vetëm. Një analizë më e detajuar e problemit zbuloi se ndodhte zëvendësimi i serverit imap.mail.ru (si dhe serverëve dhe shërbimeve të tjera të postës) në nivelin DNS. Më pas, me ndihmën aktive të përdoruesve tanë, ne gjetëm se shkaku ishte një regjistrim i gabuar në cache-n e router-it të tyre, i cili në të njëjtën kohë është një zgjidhës lokal DNS, dhe i cili në shumë (por jo të gjitha) raste ishte një pajisje MikroTik, shumë e njohur në rrjetet e vogla korporative dhe te provajderët e vegjël të internetit.
Cila është problemi
Në shtator 2019, hulumtuesit disa vulnerabilitete në MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), të cilat lejonin kryerjen e një sulmi të helmimit të caches DNS, domethënë mundësinë për të zëvendësuar regjistrimet DNS në cache-n e router-it, për më tepër, CVE-2019-3978 i mundëson sulmuesit të mos presë që ndonjë nga rrjeti i brendshëm të kërkojë një regjistrim në serverin e tij DNS, për të helmuar cache-n e zgjidhësit, por të fillojë një kërkesë të tillë vetë përmes portit 8291 (UDP dhe TCP). Vulnerabiliteti u rregullua nga MikroTik në versionet e RouterOS 6.45.7 (stable) dhe 6.44.6 (long-term) më 28 tetor 2019, megjithatë sipas më shumë se pjesa më e madhe e përdoruesve aktualisht nuk e kanë instaluar patch-in.
E dukshme është se tani ky problem po shfrytëzohet aktivisht "në jet".
Çfarë rreziku paraqet
Sulmuesi mund të zëvendësojë regjistrimin DNS të cilitdo hosti, me të cilin përdoruesi i rrjetit të brendshëm ka qasje, duke kapur kështu trafikun drejt tij. Nëse informacioni sensitiv transmetohet pa enkriptim (për shembull, me http:// pa TLS) ose përdoruesi pranon një certifikatë të rreme, sulmuesi mund të marrë të gjithë të dhënat që dërgohen përmes lidhjes, të tilla si emri i përdoruesit ose fjalëkalimi. Fatkeqësisht, praktika tregon se nëse përdoruesi ka mundësinë të pranojë një certifikatë të rreme, ai do ta shfrytëzojë atë.
Pse pikërisht serverët SMTP dhe IMAP, dhe çfarë i shpëtoi përdoruesit
Pse sulmuesit u përpoqën të kapnin pikërisht trafikun SMTP/IMAP të aplikacioneve të postës, e jo trafikun në web, megjithëse pjesa më e madhe e përdoruesve hyjnë në postë përmes shfletuesve në HTTPS?
Nuk të gjitha programet e postës që funksionojnë përmes SMTP dhe IMAP/POP3 e mbrojnë përdoruesin nga gabimet, duke mos lejuar që ai të dërgojë emrin e përdoruesit dhe fjalëkalimin përmes një lidhjeje të pasigurt ose të kompromentuar, megjithëse sipas standardit , i miratuar në vitin 2018 (dhe i implementuar në Mail.ru shumë më herët), ato duhet të mbrojnë përdoruesin nga kapja e fjalëkalimit përmes çdo lidhjeje të papërgatitur. Për më tepër, për momentin në klientët e postës përdorimi i protokollit OAuth është shumë i rrallë (ai mbështetet nga serverat e postës Mail.ru), dhe pa atë, emri i përdoruesit dhe fjalëkalimi dërgohen në çdo seancë.
Shfletuesit mund të jenë pak më të mbrojtur nga sulmet Man-in-the-Middle. Në të gjitha domenet kritike të mail.ru, përveç HTTPS, është aktivizuar politika HSTS (siguria strikte e transportit HTTP). Me HSTS-në të aktivizuar, një shfletues modern nuk i ofron përdoruesit një mundësi të thjeshtë për të pranuar një certifikatë të rreme, madje nëse përdoruesi e dëshiron këtë. Përveç HSTS, përdoruesit janë shpëtuar nga fakti se, që nga viti 2017, serverët SMTP, IMAP dhe POP3 të Mail.ru ndalojnë dërgimin e fjalëkalimeve përmes një lidhjeje të pasigurt. Të gjithë përdoruesit tanë përdornin TLS për aksesin përmes SMTP, POP3 dhe IMAP, dhe kështu fjalëkalimi dhe emri i përdoruesit mund të kapen vetëm nëse përdoruesi vetë pranon të pranojë një certifikatë të falsifikuar.
Për përdoruesit e celularëve, gjithmonë rekomandojmë të përdorin aplikacionet e Mail.ru për qasje në postë, pasi puna me postën në to është më e sigurt se në shfletues ose klientë të integruar SMTP/IMAP.
Çfarë duhet bërë
Nevoja për të përditësuar firmware-n e MikroTik RouterOS në një version të sigurt. Nëse për ndonjë arsye kjo është e pamundur, duhet të filtrohet trafiku përmes portit 8291 (tcp dhe udp), kjo do ta vështirësojë shfrytëzimin e problemit, megjithatë nuk do të eliminojë mundësinë e injeksionit pasiv në DNS-cache. Kujdesit të internetit do t'i duhet të filtrojë këtë port në rrjetet e tyre për të mbrojtur përdoruesit korporativë.
Të gjithë përdoruesit që pranuan certifikatën e falsifikuar duhet urgjentisht të ndryshojnë fjalëkalimin e postës elektronike dhe shërbimeve të tjera për të cilat kjo certifikatë ishte pranuar. Nga ana jonë, ne do të informojmë përdoruesit që hyjnë në postë përmes pajisjeve të ndjeshme.
P.S. Ka një dobësi tjetër të lidhur, e përshkruar në postim "".
Burimi: habr.com
