Apdet RouterOS on MikroTik Anjeun

Apdet RouterOS on MikroTik Anjeun
Dina malem 10 Maret, layanan rojongan Mail.ru mimiti narima keluhan ti pamaké ngeunaan henteu mampuh pikeun nyambung ka Mail.ru IMAP/SMTP server ngaliwatan program email. Dina waktos anu sami, sababaraha sambungan henteu ngaliwat, sareng sababaraha nunjukkeun kasalahan sertipikat. Kasalahan disababkeun ku "server" ngaluarkeun sertipikat TLS anu ditandatanganan sorangan.
 
Apdet RouterOS on MikroTik Anjeun
Dina dua dinten, langkung ti 10 keluhan sumping ti pangguna dina rupa-rupa jaringan sareng rupa-rupa alat, sahingga teu mungkin masalahna aya dina jaringan hiji panyadia. Analisis anu langkung rinci ngeunaan masalah éta ngungkabkeun yén pangladén imap.mail.ru (sareng server sareng jasa mail anu sanés) diganti dina tingkat DNS. Salajengna, kalayan bantosan aktip ti pangguna urang, kami mendakan yén alesanana nyaéta éntri anu lepat dina cache routerna, anu ogé résolusi DNS lokal, sareng anu dina seueur (tapi henteu sadayana) kasus tétéla janten MikroTik. alat, pohara populér di jaringan perusahaan leutik jeung ti panyadia Internet leutik.

Naon masalahna

Dina Séptémber 2019, peneliti kapendak sababaraha kerentanan dina MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), nu diwenangkeun serangan karacunan cache DNS, i.e. Kamampuhan pikeun spoof rékaman DNS dina cache DNS router, sareng CVE-2019-3978 ngamungkinkeun panyerang henteu ngadagoan batur ti jaringan internal nyuhunkeun éntri dina server DNS na pikeun ngaracun cache solver, tapi pikeun ngamimitian sapertos kitu. a menta sorangan ngaliwatan port 8291 (UDP na TCP). Kerentanan dibenerkeun ku MikroTik dina versi RouterOS 6.45.7 (stabil) sareng 6.44.6 (jangka panjang) dina 28 Oktober 2019, tapi numutkeun kana panalungtikan Kaseueuran pangguna ayeuna henteu acan masang patch.

Ieu atra yén masalah ieu ayeuna keur aktip dieksploitasi "live".

Naha éta bahaya?

Hiji panyerang tiasa spoof rékaman DNS tina host mana wae nu diakses ku pamaké dina jaringan internal, kukituna intercepting lalulintas keur eta. Upami inpormasi sénsitip dikirimkeun tanpa énkripsi (contona, ngalangkungan http: // tanpa TLS) atanapi pangguna satuju nampi sertipikat palsu, panyerang tiasa nampi sadaya data anu dikirim ku sambungan, sapertos login atanapi kecap akses. Hanjakalna, prakték nunjukkeun yén upami pangguna ngagaduhan kasempetan nampi sertipikat palsu, anjeunna bakal ngamangpaatkeunana.

Naha SMTP na IMAP server, sarta naon disimpen pamaké

Naha panyerang nyobian nyegat lalu lintas SMTP / IMAP tina aplikasi email, sanés lalu lintas wéb, sanaos seueur pangguna ngaksés suratna ngalangkungan browser HTTPS?

Henteu sadayana program email anu dianggo via SMTP sareng IMAP/POP3 ngajagi pangguna tina kasalahan, nyegah anjeunna ngirim login sareng kecap akses ngalangkungan sambungan anu teu aman atanapi dikompromi, sanaos dumasar kana standar. RFC 8314, diadopsi deui dina 2018 (jeung dilaksanakeun dina Mail.ru loba saméméhna), maranéhanana kudu ngajaga pamaké ti interception sandi ngaliwatan sambungan unsecured. Salaku tambahan, protokol OAuth jarang pisan dianggo dina klien email (dirojong ku server mail Mail.ru), sareng tanpa éta, login sareng kecap akses dikirimkeun dina unggal sési.

Browser bisa jadi saeutik hadé ditangtayungan tina serangan Man-in-the-Middle. Dina sadaya domain kritis mail.ru, sajaba HTTPS, kawijakan HSTS (HTTP strict transport security) diaktipkeun. Kalayan HSTS diaktipkeun, browser modern henteu masihan pilihan anu gampang pikeun nampi sertipikat palsu, sanaos pangguna hoyong. Salian HSTS, pangguna disimpen ku kanyataan yén saprak 2017, SMTP, IMAP sareng POP3 server Mail.ru nyaram pamindahan kecap akses dina sambungan anu teu aman, sadaya pangguna kami nganggo TLS pikeun aksés via SMTP, POP3 sareng IMAP, sareng kituna login sarta sandi bisa intercept ngan lamun pamaké sorangan satuju pikeun nampa sertipikat spoofed.

Pikeun pangguna sélulér, kami salawasna nyarankeun ngagunakeun aplikasi Mail.ru pikeun ngaksés surat, sabab... damel sareng mail di aranjeunna langkung aman tibatan dina browser atanapi klien SMTP/IMAP anu diwangun.

Naon anu kudu dipigawé

Perlu ngapdet firmware MikroTik RouterOS kana versi anu aman. Mun keur sababaraha alesan ieu teu mungkin, perlu pikeun nyaring lalulintas dina port 8291 (tcp na udp), ieu bakal ngahesekeun eksploitasi masalah, sanajan moal ngaleungitkeun kamungkinan suntik pasip kana cache DNS. ISP kedah nyaring port ieu dina jaringanna pikeun ngajagi pangguna perusahaan. 

Sadaya pangguna anu nampi sertipikat anu diganti kedah gancang-gancang ngarobih kecap konci pikeun email sareng jasa sanés anu sertipikat ieu ditampi. Pikeun bagian kami, kami bakal ngabéjaan pangguna anu ngaksés surat ngalangkungan alat anu rentan.

PS Aya ogé kerentanan anu aya hubunganana anu dijelaskeun dina postingan éta LukaSafonov "Kerentanan backport di RouterOS nempatkeun ratusan rébu alat dina résiko".

sumber: www.habr.com

Tambahkeun komentar