Kemas kini RouterOS pada MikroTik anda

Pada petang 10 Mac, perkhidmatan sokongan Mail.ru mula menerima aduan daripada pengguna tentang ketidakupayaan untuk menyambung ke pelayan IMAP/SMTP Mail.ru melalui program e-mel. Pada masa yang sama, beberapa sambungan tidak berjaya, dan ada yang menunjukkan ralat sijil. Ralat disebabkan oleh "pelayan" yang mengeluarkan sijil TLS yang ditandatangani sendiri.
 

Dalam dua hari, lebih daripada 10 aduan masuk daripada pengguna pada pelbagai rangkaian dan dengan pelbagai peranti, menjadikannya tidak mungkin masalah itu berada dalam rangkaian mana-mana satu pembekal. Analisis yang lebih terperinci tentang masalah mendedahkan bahawa pelayan imap.mail.ru (serta pelayan dan perkhidmatan mel lain) sedang diganti pada peringkat DNS. Selanjutnya, dengan bantuan aktif pengguna kami, kami mendapati bahawa sebabnya adalah kemasukan yang salah dalam cache penghala mereka, yang juga merupakan penyelesai DNS tempatan, dan yang dalam banyak (tetapi tidak semua) kes ternyata MikroTik peranti, sangat popular dalam rangkaian korporat kecil dan daripada pembekal Internet kecil.

Apa masalahnya

Pada September 2019, penyelidik dijumpai beberapa kelemahan dalam MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), yang membenarkan serangan keracunan cache DNS, i.e. keupayaan untuk memalsukan rekod DNS dalam cache DNS penghala, dan CVE-2019-3978 membolehkan penyerang tidak menunggu seseorang daripada rangkaian dalaman meminta kemasukan pada pelayan DNSnya untuk meracuni cache penyelesai, tetapi untuk memulakan sedemikian permintaan sendiri melalui port 8291 (UDP dan TCP). Kerentanan telah diperbaiki oleh MikroTik dalam versi RouterOS 6.45.7 (stabil) dan 6.44.6 (jangka panjang) pada 28 Oktober 2019, tetapi menurut penyelidikan Kebanyakan pengguna belum memasang patch pada masa ini.

Jelas sekali bahawa masalah ini kini sedang dieksploitasi secara aktif "secara langsung".

Mengapa ia berbahaya

Penyerang boleh memalsukan rekod DNS mana-mana hos yang diakses oleh pengguna pada rangkaian dalaman, dengan itu memintas trafik ke sana. Jika maklumat sensitif dihantar tanpa penyulitan (contohnya, melalui http:// tanpa TLS) atau pengguna bersetuju untuk menerima sijil palsu, penyerang boleh mendapatkan semua data yang dihantar melalui sambungan, seperti log masuk atau kata laluan. Malangnya, amalan menunjukkan bahawa jika pengguna mempunyai peluang untuk menerima sijil palsu, dia akan mengambil kesempatan daripadanya.

Mengapa pelayan SMTP dan IMAP, dan perkara yang disimpan pengguna

Mengapakah penyerang cuba memintas trafik SMTP/IMAP bagi aplikasi e-mel, dan bukan trafik web, walaupun kebanyakan pengguna mengakses mel mereka melalui penyemak imbas HTTPS?

Tidak semua program e-mel yang berfungsi melalui SMTP dan IMAP/POP3 melindungi pengguna daripada ralat, menghalangnya daripada menghantar log masuk dan kata laluan melalui sambungan yang tidak selamat atau terjejas, walaupun mengikut standard RFC 8314, diterima pakai pada 2018 (dan dilaksanakan dalam Mail.ru lebih awal), mereka mesti melindungi pengguna daripada pemintasan kata laluan melalui sebarang sambungan tidak selamat. Di samping itu, protokol OAuth sangat jarang digunakan dalam klien e-mel (ia disokong oleh pelayan mel Mail.ru), dan tanpa itu, log masuk dan kata laluan dihantar dalam setiap sesi.

Pelayar mungkin dilindungi sedikit lebih baik daripada serangan Man-in-the-Middle. Pada semua domain kritikal mail.ru, sebagai tambahan kepada HTTPS, dasar HSTS (HTTP strict transport security) didayakan. Dengan HSTS didayakan, penyemak imbas moden tidak memberi pengguna pilihan mudah untuk menerima sijil palsu, walaupun pengguna mahu. Sebagai tambahan kepada HSTS, pengguna telah diselamatkan oleh fakta bahawa sejak 2017, pelayan SMTP, IMAP dan POP3 Mail.ru melarang pemindahan kata laluan melalui sambungan tidak selamat, semua pengguna kami menggunakan TLS untuk akses melalui SMTP, POP3 dan IMAP, dan oleh itu log masuk dan kata laluan boleh memintas hanya jika pengguna itu sendiri bersetuju untuk menerima sijil yang dipalsukan.

Untuk pengguna mudah alih, kami sentiasa mengesyorkan menggunakan aplikasi Mail.ru untuk mengakses mel, kerana... bekerja dengan mel di dalamnya adalah lebih selamat daripada dalam penyemak imbas atau pelanggan SMTP/IMAP terbina dalam.

Apa yang perlu dilakukan

Ia adalah perlu untuk mengemas kini perisian tegar MikroTik RouterOS kepada versi selamat. Jika atas sebab tertentu ini tidak mungkin, adalah perlu untuk menapis trafik pada port 8291 (tcp dan udp), ini akan merumitkan eksploitasi masalah, walaupun ia tidak akan menghapuskan kemungkinan suntikan pasif ke dalam cache DNS. ISP harus menapis port ini pada rangkaian mereka untuk melindungi pengguna korporat. 

Semua pengguna yang menerima sijil yang diganti harus segera menukar kata laluan untuk e-mel dan perkhidmatan lain yang sijil ini diterima. Bagi pihak kami, kami akan memberitahu pengguna yang mengakses mel melalui peranti yang terdedah.

PS Terdapat juga kelemahan berkaitan yang diterangkan dalam siaran LukaSafonov "Kerentanan backport dalam RouterOS meletakkan ratusan ribu peranti berisiko".

Sumber: www.habr.com