Përditësoni RouterOS në MikroTik tuaj

Përditësoni RouterOS në MikroTik tuaj
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 kalonin, ndërsa disa tregonin një gabim të certifikatës. Gabimi shkaktohet nga fakti se "serveri" jep një certifikatë vetë-nënshkruese TLS.
 
Përditësoni RouterOS në MikroTik tuaj
Gjatë dy ditëve, erdhën më shumë se 10 ankesa nga përdorues të ndryshëm nga rrjete të ndryshme dhe me pajisje të ndryshme, duke e bërë të pamundur që problemi të ishte në rrjetin e ndonjë provajderi të vetëm. Një analizë më e detajuar e problemit zbuloi se kishte një zëvendësim të serverit imap.mail.ru (ashtu si dhe të tjerë serverë dhe shërbime të postës) në nivelin DNS. Më pas, me ndihmën aktive të përdoruesve tanë, ne gjetëm se shkaku ishte një shënim i gabuar në cache-in e ruterit të tyre, i cili përveç kësaj funksionon si një zgjidhës lokal DNS, dhe që në shumë (por jo të gjitha) raste doli të ishte pajisja MikroTik, shumë e popullarizuar në rrjetet e vogla korporative dhe te provajderët e vegjël të Internetit.

Cila është problemi

Në shtator 2019, studiuesit gjetëm disa vulnerabilitete në MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), që lejonin një sulm të helmit të cache-it DNS, dmth. mundësinë për të zëvendësuar shënimet DNS në cache-in e ruterit, dhe CVE-2019-3978 lejon sulmuesin që të mos presë që dikush nga rrjeti i brendshëm të lidhet për një shënim në serverin e tij DNS, për të helmuar cache-in e zgjidhësit, por të inicijojë një kërkesë përmes portit 8291 (UDP dhe TCP) vetë. Vulnerabiliteti u rregullua nga MikroTik në versionet RouterOS 6.45.7 (stable) dhe 6.44.6 (long-term) më 28 tetor 2019, por sipas studimeve shumica e përdoruesve në këtë moment nuk i kishin instaluar patch-et.

Është e qartë se tani ky problem po eksploatohet aktivisht "në jetët".

Çfarë rreziku paraqet

Sulmuesi mund të zëvendësojë shënimin DNS të çdo hosti që përdoruesi i rrjetit të brendshëm i qaset, duke kështu kapur trafikun për të. Nëse informacioni sensitv transmetohet pa enkriptim (për shembull në http:// pa TLS) ose përdoruesi pranon të marrë një certifikatë të rreme, sulmuesi mund të marrë të gjitha të dhënat që dërgohen përmes lidhjes, për shembull emrin e përdoruesit ose fjalëkalimin. Fatkeqësisht, praktika tregon se nëse përdoruesit kanë mundësinë të pranojnë një certifikatë të rreme, ata e shfrytëzojnë atë.

Pse vetëm serverët SMTP dhe IMAP, dhe çfarë i shpëtoi përdoruesve

Pse sulmuesit përpiqeshin të kapnin pikërisht trafikun SMTP/IMAP të programeve të postës, dhe jo trafikun e webit, përkundër faktit se shumica e përdoruesve hyjnë në postë përmes një shfletuesi në HTTPS?

Jo të gjithë programet e postës që funksionojnë me SMTP dhe IMAP/POP3 mbrojnë përdoruesin nga gabimet, duke mos lejuar të dërgojnë emrin e përdoruesit dhe fjalëkalimin përmes një lidhjeje të pasigurt ose të kompromentuar, ndonëse sipas standardit RFC 8314, i miratuar në vitin 2018 (dhe i implementuar në Mail.ru shumë më herët), ata duhet të mbrojnë përdoruesin nga kapja e fjalëkalimit përmes çdo lidhjeje të pa siguruar. Për më tepër, ndërsa në klientët e postës rrallë përdoret protokolli OAuth (ai përkrahët nga serverët e postës Mail.ru), pa të, emri i përdoruesit dhe fjalëkalimi dërgohen në çdo seancë.

Shfletuesit mund të jenë pak më mirë të mbrojtur nga sulmet Man-in-the-Middle. Në të gjitha domenet kritike të mail.ru, përveç HTTPS është aktivizuar politika HSTS (siguria e transportit të ngurtë HTTP). Kur HSTS është aktivizuar, shfletuesi modern nuk i jep përdoruesit mundësinë e lehtë për të pranuar një certifikatë të rreme, edhe nëse përdoruesi dëshiron. Përveç HSTS, përdoruesit shpëtojnë nga fakti se që nga viti 2017, serverët SMTP, IMAP dhe POP3 të Mail.ru ndalojnë transmetimin e fjalëkalimit përmes një lidhjeje të pa siguruar, të gjithë përdoruesit tanë përdorën TLS për qasje në SMTP, POP3 dhe IMAP, dhe kështu emri i përdoruesit dhe fjalëkalimi mund të kapen vetëm nëse përdoruesi vetë pranon një certifikatë të zëvendësuar.

Për përdoruesit mobilë, ne gjithmonë rekomandojmë të përdorin aplikacionet Mail.ru për të hyrë në postë, pasi puna me postën në to është më e sigurt se në shfletues ose në klientë të inkorporuar SMTP/IMAP.

Çfarë duhet të bëni

Duhet të përditësoni firmware-n MikroTik RouterOS në një version të sigurt. Nëse për ndonjë arsye kjo nuk është e mundur, duhet të filtrohet trafiku në portin 8291 (tcp dhe udp), kjo do të bëjë më të vështirë shfrytëzimin e problemit, ndonëse nuk do të eliminojë mundësinë e injektimit pasiv në cache-in DNS. Provajderët e internetit duhet të filtrojnë këtë port në rrjetet e tyre për të mbrojtur përdoruesit korporativë. 

Të gjithë përdoruesit që pranuan një certifikatë të zëvendësuar duhet të ndryshojnë menjëherë fjalëkalimin e postës elektronike dhe të shërbimeve të tjera për të cilat u pranuar kjo certifikatë. Nga ana jonë, ne do t'i njoftojmë përdoruesit që hyjnë në postë përmes pajisjeve të ndjeshme.

P.S. Ekziston një vulnerabilitet tjetër i lidhur, i përshkruar në post. LukaSafonov "Backport vulnerabiliteti në RouterOS kërcënon qindra mijëra pajisje".

Burimi: habr.com

Bleni hostim të besueshëm për faqe me mbrojtje nga DDoS, serverë VPS VDS 🔥 Bleni hostim të besueshëm për faqe me mbrojtje nga DDoS, serverë VPS VDS | ProHoster