ອັບເດດ RouterOS ໃນ MikroTik ຂອງທ່ານ

ໃນຕອນແລງຂອງວັນທີ 10 ມີນາ, ບໍລິການສະຫນັບສະຫນູນ Mail.ru ເລີ່ມໄດ້ຮັບການຮ້ອງທຸກຈາກຜູ້ໃຊ້ກ່ຽວກັບການບໍ່ສາມາດເຊື່ອມຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍຂອງ Mail.ru IMAP / SMTP ຜ່ານໂຄງການອີເມວ. ໃນເວລາດຽວກັນ, ການເຊື່ອມຕໍ່ບາງຢ່າງບໍ່ຜ່ານ, ແລະບາງອັນສະແດງໃຫ້ເຫັນຄວາມຜິດພາດຂອງໃບຢັ້ງຢືນ. ຄວາມຜິດພາດແມ່ນເກີດມາຈາກ "ເຊີບເວີ" ອອກໃບຢັ້ງຢືນ TLS ທີ່ເຊັນດ້ວຍຕົນເອງ.
 

ໃນສອງມື້, ຫຼາຍກວ່າ 10 ຄໍາຮ້ອງທຸກເຂົ້າມາຈາກຜູ້ໃຊ້ໃນເຄືອຂ່າຍທີ່ຫຼາກຫຼາຍແລະອຸປະກອນທີ່ຫລາກຫລາຍ, ເຮັດໃຫ້ມັນບໍ່ຫນ້າຈະເປັນບັນຫາຢູ່ໃນເຄືອຂ່າຍຂອງຜູ້ໃຫ້ບໍລິການໃດນຶ່ງ. ການວິເຄາະລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບບັນຫາໄດ້ເປີດເຜີຍວ່າເຄື່ອງແມ່ຂ່າຍ imap.mail.ru (ເຊັ່ນດຽວກັນກັບເຄື່ອງແມ່ຂ່າຍເມລແລະບໍລິການອື່ນໆ) ຈະຖືກປ່ຽນແທນໃນລະດັບ DNS. ນອກຈາກນັ້ນ, ດ້ວຍການຊ່ວຍເຫຼືອຂອງຜູ້ໃຊ້ຂອງພວກເຮົາ, ພວກເຮົາພົບວ່າເຫດຜົນແມ່ນການເຂົ້າບໍ່ຖືກຕ້ອງໃນ cache ຂອງ router ຂອງພວກເຂົາ, ເຊິ່ງເປັນຕົວແກ້ໄຂ DNS ທ້ອງຖິ່ນ, ແລະໃນຫຼາຍໆກໍລະນີ (ແຕ່ບໍ່ແມ່ນທັງຫມົດ) ໄດ້ກາຍເປັນ MikroTik. ອຸປະກອນ, ເປັນທີ່ນິຍົມຫຼາຍໃນເຄືອຂ່າຍບໍລິສັດຂະຫນາດນ້ອຍ ແລະຈາກຜູ້ໃຫ້ບໍລິການອິນເຕີເນັດຂະຫນາດນ້ອຍ.

ມີ​ບັນ​ຫາ​ຫຍັງ

ໃນເດືອນກັນຍາ 2019, ນັກຄົ້ນຄວ້າ ພົບ ຊ່ອງໂຫວ່ຫຼາຍອັນໃນ MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), ເຊິ່ງອະນຸຍາດໃຫ້ການໂຈມຕີ DNS cache poisoning, i.e. ຄວາມສາມາດໃນການຫຼອກລວງບັນທຶກ DNS ໃນ DNS cache ຂອງ router, ແລະ CVE-2019-3978 ຊ່ວຍໃຫ້ຜູ້ໂຈມຕີບໍ່ລໍຖ້າຜູ້ໃດຜູ້ນຶ່ງຈາກເຄືອຂ່າຍພາຍໃນເພື່ອຮ້ອງຂໍການເຂົ້າຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ DNS ຂອງລາວເພື່ອພິດກັບການແກ້ໄຂ cache, ແຕ່ການເລີ່ມຕົ້ນດັ່ງກ່າວ. ການຮ້ອງຂໍຕົວເອງຜ່ານພອດ 8291 (UDP ແລະ TCP). ຊ່ອງໂຫວ່ໄດ້ຖືກແກ້ໄຂໂດຍ MikroTik ໃນລຸ້ນຂອງ RouterOS 6.45.7 (ຄົງທີ່) ແລະ 6.44.6 (ໄລຍະຍາວ) ໃນວັນທີ 28 ຕຸລາ 2019, ແຕ່ອີງຕາມ ການຄົ້ນຄວ້າ ຜູ້​ໃຊ້​ສ່ວນ​ໃຫຍ່​ຍັງ​ບໍ່​ໄດ້​ຕິດ​ຕັ້ງ patches ໃນ​ປັດ​ຈຸ​ບັນ​.

ມັນເປັນທີ່ຊັດເຈນວ່າບັນຫານີ້ໄດ້ຖືກຂູດຮີດຢ່າງຈິງຈັງ "ດໍາລົງຊີວິດ".

ເປັນຫຍັງມັນເປັນອັນຕະລາຍ?

ຜູ້ໂຈມຕີສາມາດຫຼອກລວງບັນທຶກ DNS ຂອງໂຮດໃດໆທີ່ເຂົ້າເຖິງໂດຍຜູ້ໃຊ້ຢູ່ໃນເຄືອຂ່າຍພາຍໃນ, ດັ່ງນັ້ນການຂັດຂວາງການຈະລາຈອນໄປຫາມັນ. ຖ້າຂໍ້ມູນທີ່ລະອຽດອ່ອນຖືກສົ່ງໂດຍບໍ່ມີການເຂົ້າລະຫັດ (ຕົວຢ່າງເຊັ່ນ: ຜ່ານ http:// ໂດຍບໍ່ມີ TLS) ຫຼືຜູ້ໃຊ້ຕົກລົງທີ່ຈະຍອມຮັບໃບຢັ້ງຢືນການປອມແປງ, ຜູ້ໂຈມຕີສາມາດໄດ້ຮັບຂໍ້ມູນທັງຫມົດທີ່ສົ່ງຜ່ານການເຊື່ອມຕໍ່ເຊັ່ນ: ເຂົ້າສູ່ລະບົບຫຼືລະຫັດຜ່ານ. ແຕ່ຫນ້າເສຍດາຍ, ການປະຕິບັດສະແດງໃຫ້ເຫັນວ່າຖ້າຜູ້ໃຊ້ມີໂອກາດທີ່ຈະຍອມຮັບໃບຢັ້ງຢືນການປອມແປງ, ລາວຈະໃຊ້ປະໂຫຍດຈາກມັນ.

ເປັນຫຍັງເຄື່ອງແມ່ຂ່າຍ SMTP ແລະ IMAP, ແລະສິ່ງທີ່ຜູ້ໃຊ້ບັນທຶກໄວ້

ເປັນຫຍັງຜູ້ໂຈມຕີຈຶ່ງພະຍາຍາມຂັດຂວາງການເຂົ້າຊົມ SMTP/IMAP ຂອງແອັບພລິເຄຊັນອີເມວ, ແລະບໍ່ແມ່ນການເຂົ້າຊົມເວັບ, ເຖິງແມ່ນວ່າຜູ້ໃຊ້ສ່ວນໃຫຍ່ຈະເຂົ້າເຖິງອີເມວຂອງພວກເຂົາຜ່ານຕົວທ່ອງເວັບ HTTPS?

ບໍ່ແມ່ນໂປຣແກມອີເມວທັງໝົດທີ່ເຮັດວຽກຜ່ານ SMTP ແລະ IMAP/POP3 ປົກປ້ອງຜູ້ໃຊ້ຈາກຄວາມຜິດພາດ, ປ້ອງກັນບໍ່ໃຫ້ລາວສົ່ງຂໍ້ມູນການເຂົ້າສູ່ລະບົບ ແລະລະຫັດຜ່ານຜ່ານການເຊື່ອມຕໍ່ທີ່ບໍ່ປອດໄພ ຫຼືຖືກທຳລາຍ, ເຖິງແມ່ນວ່າຕາມມາດຕະຖານ. RFC 8314, ຖືກຮັບຮອງເອົາໃນປີ 2018 (ແລະຖືກປະຕິບັດໃນ Mail.ru ກ່ອນຫນ້ານີ້), ພວກເຂົາຕ້ອງປົກປ້ອງຜູ້ໃຊ້ຈາກການຂັດຂວາງລະຫັດຜ່ານໂດຍຜ່ານການເຊື່ອມຕໍ່ທີ່ບໍ່ປອດໄພ. ນອກຈາກນັ້ນ, ໂປໂຕຄອນ OAuth ແມ່ນບໍ່ຄ່ອຍໄດ້ໃຊ້ໃນລູກຄ້າອີເມວ (ມັນຖືກສະຫນັບສະຫນູນໂດຍເຄື່ອງແມ່ຂ່າຍເມລ Mail.ru), ແລະບໍ່ມີມັນ, ການເຂົ້າສູ່ລະບົບແລະລະຫັດຜ່ານຈະຖືກສົ່ງໃນແຕ່ລະກອງປະຊຸມ.

ຕົວທ່ອງເວັບອາດຈະຖືກປ້ອງກັນດີກວ່າການໂຈມຕີຂອງຜູ້ຊາຍໃນກາງ. ໃນທຸກໂດເມນທີ່ສໍາຄັນຂອງ mail.ru, ນອກຈາກ HTTPS, ນະໂຍບາຍ HSTS (HTTP ຄວາມປອດໄພການຂົນສົ່ງທີ່ເຂັ້ມງວດ) ຖືກເປີດໃຊ້. ດ້ວຍການເປີດໃຊ້ HSTS, ຕົວທ່ອງເວັບທີ່ທັນສະໄຫມບໍ່ໄດ້ໃຫ້ທາງເລືອກທີ່ງ່າຍຕໍ່ການຍອມຮັບໃບຢັ້ງຢືນການປອມແປງ, ເຖິງແມ່ນວ່າຜູ້ໃຊ້ຕ້ອງການ. ນອກເຫນືອຈາກ HSTS, ຜູ້ໃຊ້ໄດ້ຖືກບັນທຶກໄວ້ໂດຍຄວາມຈິງທີ່ວ່ານັບຕັ້ງແຕ່ 2017, SMTP, IMAP ແລະ POP3 ເຄື່ອງແມ່ຂ່າຍຂອງ Mail.ru ຫ້າມການໂອນລະຫັດຜ່ານຜ່ານການເຊື່ອມຕໍ່ທີ່ບໍ່ປອດໄພ, ຜູ້ໃຊ້ທັງຫມົດຂອງພວກເຮົາໃຊ້ TLS ສໍາລັບການເຂົ້າເຖິງຜ່ານ SMTP, POP3 ແລະ IMAP, ແລະ. ດັ່ງນັ້ນການເຂົ້າສູ່ລະບົບແລະລະຫັດຜ່ານສາມາດຂັດຂວາງໄດ້ພຽງແຕ່ຖ້າຜູ້ໃຊ້ເອງຕົກລົງທີ່ຈະຍອມຮັບໃບຢັ້ງຢືນທີ່ຖືກປອມ.

ສໍາລັບຜູ້ໃຊ້ມືຖື, ພວກເຮົາແນະນໍາໃຫ້ໃຊ້ຄໍາຮ້ອງສະຫມັກ Mail.ru ເພື່ອເຂົ້າເຖິງອີເມວ, ເພາະວ່າ ... ການ​ເຮັດ​ວຽກ​ກັບ​ອີ​ເມລ​ໃນ​ພວກ​ເຂົາ​ແມ່ນ​ມີ​ຄວາມ​ປອດ​ໄພ​ກ​່​ວາ​ໃນ​ຕົວ​ທ່ອງ​ເວັບ​ຫຼື​ລູກ​ຄ້າ SMTP / IMAP ໃນ​ຕົວ​.

ສິ່ງທີ່ຄວນເຮັດ

ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະອັບເດດເຟີມແວ MikroTik RouterOS ໃຫ້ເປັນເວີຊັນທີ່ປອດໄພ. ຖ້າເຫດຜົນບາງຢ່າງນີ້ເປັນໄປບໍ່ໄດ້, ມັນຈໍາເປັນຕ້ອງການກັ່ນຕອງການຈະລາຈອນໃນພອດ 8291 (tcp ແລະ udp), ນີ້ຈະສັບສົນການຂູດຮີດຂອງບັນຫາ, ເຖິງແມ່ນວ່າມັນຈະບໍ່ລົບລ້າງຄວາມເປັນໄປໄດ້ຂອງການສັກຢາ passive ເຂົ້າໄປໃນ DNS cache. ISPs ຄວນກັ່ນຕອງພອດນີ້ຢູ່ໃນເຄືອຂ່າຍຂອງພວກເຂົາເພື່ອປົກປ້ອງຜູ້ໃຊ້ຂອງບໍລິສັດ. 

ຜູ້​ໃຊ້​ທັງ​ຫມົດ​ທີ່​ຍອມ​ຮັບ​ໃບ​ຢັ້ງ​ຢືນ​ການ​ທົດ​ແທນ​ຄວນ​ດ່ວນ​ການ​ປ່ຽນ​ແປງ​ລະ​ຫັດ​ຜ່ານ​ສໍາ​ລັບ​ອີ​ເມລ​໌​ແລະ​ການ​ບໍ​ລິ​ການ​ອື່ນໆ​ທີ່​ໃບ​ຢັ້ງ​ຢືນ​ນີ້​ໄດ້​ຮັບ​ການ​ຍອມ​ຮັບ. ສໍາລັບສ່ວນຫນຶ່ງຂອງພວກເຮົາ, ພວກເຮົາຈະແຈ້ງໃຫ້ຜູ້ໃຊ້ທີ່ເຂົ້າເຖິງ mail ຜ່ານອຸປະກອນທີ່ມີຄວາມສ່ຽງ.

PS ຍັງມີຊ່ອງໂຫວ່ທີ່ກ່ຽວຂ້ອງທີ່ອະທິບາຍໄວ້ໃນໂພສ LukaSafonov "ຊ່ອງໂຫວ່ Backport ໃນ RouterOS ເຮັດໃຫ້ຫຼາຍຮ້ອຍພັນອຸປະກອນມີຄວາມສ່ຽງ".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com