ການໂຈມຕີ NXNSAttack ມີຜົນຕໍ່ຕົວແກ້ໄຂ DNS ທັງໝົດ

ກຸ່ມນັກຄົ້ນຄ້ວາຈາກມະຫາວິທະຍາໄລ Tel Aviv ແລະສູນ Interdisciplinary ໃນ Herzliya (Israel) ໄດ້ພັດທະນາ ວິ​ທີ​ການ​ໂຈມ​ຕີ​ໃຫມ່​ NXNSAttack (PDF), ໃຫ້ທ່ານສາມາດນໍາໃຊ້ຕົວແກ້ໄຂ DNS ໃດເປັນເຄື່ອງຂະຫຍາຍສຽງ, ໃຫ້ອັດຕາການຂະຫຍາຍເຖິງ 1621 ເທື່ອໃນຈໍານວນແພັກເກັດ (ສໍາລັບແຕ່ລະຄໍາຮ້ອງຂໍທີ່ຖືກສົ່ງໄປຫາຕົວແກ້ໄຂ, ທ່ານສາມາດບັນລຸຄໍາຮ້ອງຂໍ 1621 ຖືກສົ່ງໄປຫາເຄື່ອງແມ່ຂ່າຍຂອງຜູ້ຖືກເຄາະຮ້າຍ) ແລະເຖິງ 163 ຄັ້ງໃນດ້ານການຈະລາຈອນ.

ບັນຫາແມ່ນກ່ຽວຂ້ອງກັບລັກສະນະພິເສດຂອງໂປໂຕຄອນແລະຜົນກະທົບຕໍ່ເຄື່ອງແມ່ຂ່າຍ DNS ທັງຫມົດທີ່ສະຫນັບສະຫນູນການປຸງແຕ່ງຄໍາຖາມ recursive, ລວມທັງ. BIND (CVE-2020-8616) Knot (CVE-2020-12667) ພະລັງງານ (CVE-2020-10995) Windows DNS Server и ບໍ່ມີຂໍ້ຜູກມັດ (CVE-2020-12662), ເຊັ່ນດຽວກັນກັບການບໍລິການ DNS ສາທາລະນະຂອງ Google, Cloudflare, Amazon, Quad9, ICANN ແລະບໍລິສັດອື່ນໆ. ການແກ້ໄຂໄດ້ຖືກປະສານງານກັບຜູ້ພັດທະນາເຄື່ອງແມ່ຂ່າຍ DNS, ຜູ້ທີ່ພ້ອມກັນອອກການປັບປຸງເພື່ອແກ້ໄຂຄວາມອ່ອນແອໃນຜະລິດຕະພັນຂອງພວກເຂົາ. ການປ້ອງກັນການໂຈມຕີຖືກປະຕິບັດໃນການປ່ອຍ
ບໍ່ມີການຜູກມັດ 1.10.1, Knot Resolver 5.1.1, PowerDNS Recursor 4.3.1, 4.2.2, 4.1.16, ຜູກມັດ 9.11.19, 9.14.12, 9.16.3.

ການໂຈມຕີແມ່ນອີງໃສ່ຜູ້ໂຈມຕີໂດຍໃຊ້ຄໍາຮ້ອງຂໍທີ່ອ້າງເຖິງຈໍານວນບັນທຶກ NS ປອມທີ່ບໍ່ເຄີຍເຫັນກ່ອນຫນ້ານີ້, ເຊິ່ງການກໍານົດຊື່ໄດ້ຖືກມອບຫມາຍ, ແຕ່ບໍ່ໄດ້ລະບຸບັນທຶກກາວທີ່ມີຂໍ້ມູນກ່ຽວກັບທີ່ຢູ່ IP ຂອງເຄື່ອງແມ່ຂ່າຍ NS ໃນການຕອບສະຫນອງ. ຕົວຢ່າງ, ຜູ້ໂຈມຕີສົ່ງຄໍາຖາມເພື່ອແກ້ໄຂຊື່ sd1.attacker.com ໂດຍການຄວບຄຸມເຄື່ອງແມ່ຂ່າຍ DNS ທີ່ຮັບຜິດຊອບສໍາລັບໂດເມນ attacker.com. ໃນການຕອບສະຫນອງຄໍາຮ້ອງຂໍຂອງຜູ້ແກ້ໄຂຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍ DNS ຂອງຜູ້ໂຈມຕີ, ການຕອບສະຫນອງແມ່ນອອກໃຫ້ຕົວແທນການກໍານົດທີ່ຢູ່ sd1.attacker.com ໃຫ້ກັບເຄື່ອງແມ່ຂ່າຍ DNS ຂອງຜູ້ຖືກເຄາະຮ້າຍໂດຍການຊີ້ບອກບັນທຶກ NS ໃນການຕອບສະຫນອງໂດຍບໍ່ມີລາຍລະອຽດກ່ຽວກັບເຄື່ອງແມ່ຂ່າຍ IP NS. ເນື່ອງຈາກເຄື່ອງແມ່ຂ່າຍ NS ທີ່ໄດ້ກ່າວມາບໍ່ໄດ້ພົບມາກ່ອນແລະທີ່ຢູ່ IP ຂອງມັນບໍ່ໄດ້ຖືກລະບຸ, ຜູ້ແກ້ໄຂພະຍາຍາມກໍານົດທີ່ຢູ່ IP ຂອງເຄື່ອງແມ່ຂ່າຍ NS ໂດຍການສົ່ງຄໍາຖາມໄປຫາເຄື່ອງແມ່ຂ່າຍ DNS ຂອງຜູ້ຖືກເຄາະຮ້າຍທີ່ໃຫ້ບໍລິການໂດເມນເປົ້າຫມາຍ (victim.com).

ບັນຫາແມ່ນວ່າຜູ້ໂຈມຕີສາມາດຕອບສະຫນອງດ້ວຍບັນຊີລາຍຊື່ໃຫຍ່ຂອງເຄື່ອງແມ່ຂ່າຍ NS ທີ່ບໍ່ຊ້ໍາກັນກັບຊື່ໂດເມນຍ່ອຍຂອງຜູ້ຖືກເຄາະຮ້າຍທີ່ບໍ່ມີຕົວຕົນ (fake-1.victim.com, fake-2.victim.com, ... fake-1000. ຜູ້ເຄາະຮ້າຍ.com). ຜູ້ແກ້ໄຂຈະພະຍາຍາມສົ່ງຄໍາຮ້ອງຂໍໄປຫາເຄື່ອງແມ່ຂ່າຍ DNS ຂອງຜູ້ຖືກເຄາະຮ້າຍ, ແຕ່ຈະໄດ້ຮັບການຕອບສະຫນອງວ່າໂດເມນບໍ່ພົບ, ຫຼັງຈາກນັ້ນມັນຈະພະຍາຍາມກໍານົດເຄື່ອງແມ່ຂ່າຍ NS ຕໍ່ໄປໃນບັນຊີລາຍຊື່, ແລະອື່ນໆຈົນກ່ວາມັນພະຍາຍາມທັງຫມົດ. ບັນທຶກ NS ລະບຸໄວ້ໂດຍຜູ້ໂຈມຕີ. ດັ່ງນັ້ນ, ສໍາລັບຄໍາຮ້ອງຂໍຂອງຜູ້ໂຈມຕີຫນຶ່ງ, ຜູ້ແກ້ໄຂຈະສົ່ງຄໍາຮ້ອງຂໍຈໍານວນຫລາຍເພື່ອກໍານົດ NS hosts. ນັບຕັ້ງແຕ່ຊື່ເຊີບເວີ NS ຖືກສ້າງແບບສຸ່ມແລະອ້າງອີງເຖິງໂດເມນຍ່ອຍທີ່ບໍ່ມີຢູ່, ພວກມັນບໍ່ໄດ້ຖືກດຶງອອກຈາກແຄດແລະແຕ່ລະຄໍາຮ້ອງຂໍຈາກຜູ້ໂຈມຕີເຮັດໃຫ້ເກີດຄວາມວຸ່ນວາຍຂອງຄໍາຮ້ອງຂໍໃຫ້ກັບເຄື່ອງແມ່ຂ່າຍ DNS ທີ່ຮັບໃຊ້ໂດເມນຂອງຜູ້ຖືກເຄາະຮ້າຍ.

ນັກຄົ້ນຄວ້າໄດ້ສຶກສາລະດັບຄວາມອ່ອນແອຂອງຕົວແກ້ໄຂ DNS ສາທາລະນະຕໍ່ບັນຫາແລະກໍານົດວ່າເມື່ອສົ່ງຄໍາຖາມໄປຫາຕົວແກ້ໄຂ CloudFlare (1.1.1.1), ມັນເປັນໄປໄດ້ທີ່ຈະເພີ່ມຈໍານວນແພັກເກັດ (PAF, Packet Amplification Factor) 48 ເທົ່າ, Google (8.8.8.8) - 30 ເທື່ອ, FreeDNS (37.235.1.174) - 50 ເທື່ອ, OpenDNS (208.67.222.222) - 32 ເທື່ອ. ຕົວຊີ້ວັດທີ່ສັງເກດເຫັນຫຼາຍແມ່ນສັງເກດເຫັນສໍາລັບ
Level3 (209.244.0.3) - 273 ເທື່ອ, Quad9 (9.9.9.9) - 415 ເທື່ອ
SafeDNS (195.46.39.39) - 274 ຄັ້ງ, Verisign (64.6.64.6) - 202 ເທື່ອ,
Ultra (156.154.71.1) - 405 ເທື່ອ, Comodo Secure (8.26.56.26) - 435 ເທື່ອ, DNS.Watch (84.200.69.80) - 486 ເທື່ອ, ແລະ Norton ConnectSafe (199.85.126.10). - 569. ສໍາລັບເຄື່ອງແມ່ຂ່າຍໂດຍອີງໃສ່ BIND 9.12.3, ເນື່ອງຈາກການຂະຫນານຂອງຄໍາຮ້ອງຂໍ, ລະດັບການໄດ້ຮັບສາມາດບັນລຸເຖິງ 1000. ໃນ Knot Resolver 5.1.0, ລະດັບການໄດ້ຮັບແມ່ນປະມານຫຼາຍສິບເທື່ອ (24-48), ນັບຕັ້ງແຕ່ການກໍານົດຂອງ ຊື່ NS ຖືກປະຕິບັດຕາມລໍາດັບແລະວາງຢູ່ໃນຂອບເຂດຈໍາກັດພາຍໃນກ່ຽວກັບຈໍານວນຂັ້ນຕອນການແກ້ໄຂຊື່ທີ່ອະນຸຍາດໃຫ້ສໍາລັບການຮ້ອງຂໍຫນຶ່ງ.

ມີສອງຍຸດທະສາດການປ້ອງກັນຕົ້ນຕໍ. ສໍາລັບລະບົບທີ່ມີ DNSSEC ສະ ເໜີ ໃຊ້ RFC-8198 ເພື່ອປ້ອງກັນບໍ່ໃຫ້ DNS cache bypass ເພາະວ່າການຮ້ອງຂໍຖືກສົ່ງດ້ວຍຊື່ແບບສຸ່ມ. ໂດຍເນື້ອແທ້ແລ້ວຂອງວິທີການແມ່ນເພື່ອສ້າງການຕອບສະຫນອງທາງລົບໂດຍບໍ່ມີການຕິດຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍ DNS ທີ່ມີອໍານາດ, ການນໍາໃຊ້ການກວດສອບຂອບເຂດຜ່ານ DNSSEC. ວິທີການທີ່ງ່າຍດາຍກວ່າແມ່ນການຈໍາກັດຈໍານວນຊື່ທີ່ສາມາດກໍານົດໄດ້ໃນເວລາທີ່ດໍາເນີນການຮ້ອງຂໍການມອບຫມາຍດຽວ, ແຕ່ວິທີການນີ້ອາດຈະເຮັດໃຫ້ເກີດບັນຫາກັບບາງການຕັ້ງຄ່າທີ່ມີຢູ່ແລ້ວເພາະວ່າຂອບເຂດຈໍາກັດບໍ່ໄດ້ຖືກກໍານົດໄວ້ໃນໂປໂຕຄອນ.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru