กลุ่มนักวิจัยจากมหาวิทยาลัยเทลอาวีฟและศูนย์สหวิทยาการในเฮอร์ซลิยา (อิสราเอล) วิธีการโจมตีแบบใหม่ () ช่วยให้คุณสามารถใช้ตัวแก้ไข DNS ใด ๆ เป็นตัวขยายการรับส่งข้อมูล โดยให้อัตราการขยายสูงสุดถึง 1621 เท่าในแง่ของจำนวนแพ็คเก็ต (สำหรับแต่ละคำขอที่ส่งไปยังตัวแก้ไข คุณสามารถบรรลุถึง 1621 คำขอที่ถูกส่งไปยังเซิร์ฟเวอร์ของเหยื่อ) และมากถึง 163 เท่าในแง่ของปริมาณการใช้งาน
ปัญหาเกี่ยวข้องกับลักษณะเฉพาะของโปรโตคอลและส่งผลต่อเซิร์ฟเวอร์ DNS ทั้งหมดที่รองรับการประมวลผลแบบสอบถามแบบเรียกซ้ำ รวมถึง (CVE-2020-8616) (CVE-2020-12667) (CVE-2020-10995) и (CVE-2020-12662) รวมถึงบริการ DNS สาธารณะของ Google, Cloudflare, Amazon, Quad9, ICANN และบริษัทอื่นๆ การแก้ไขดังกล่าวได้รับการประสานงานกับนักพัฒนาเซิร์ฟเวอร์ DNS ซึ่งเผยแพร่การอัปเดตเพื่อแก้ไขช่องโหว่ในผลิตภัณฑ์ของตนไปพร้อมๆ กัน การป้องกันการโจมตีถูกนำมาใช้ในรุ่นต่างๆ
, , , .
การโจมตีขึ้นอยู่กับผู้โจมตีโดยใช้คำขอที่อ้างถึงบันทึก 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 เนื่องจากชื่อเซิร์ฟเวอร์ 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 ครั้ง มีการสังเกตตัวบ่งชี้ที่เห็นได้ชัดเจนยิ่งขึ้น
ระดับ 3 (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 ใช้ เพื่อป้องกันการเลี่ยงแคช DNS เนื่องจากคำขอถูกส่งไปพร้อมกับชื่อแบบสุ่ม สาระสำคัญของวิธีนี้คือการสร้างการตอบสนองเชิงลบโดยไม่ต้องติดต่อกับเซิร์ฟเวอร์ DNS ที่เชื่อถือได้ โดยใช้การตรวจสอบช่วงผ่าน DNSSEC แนวทางที่ง่ายกว่าคือการจำกัดจำนวนชื่อที่สามารถกำหนดได้เมื่อประมวลผลคำขอที่ได้รับมอบสิทธิ์เดียว แต่วิธีนี้อาจทำให้เกิดปัญหากับการกำหนดค่าที่มีอยู่บางส่วน เนื่องจากขีดจำกัดไม่ได้ถูกกำหนดไว้ในโปรโตคอล
ที่มา: opennet.ru