นักวิจัยด้านความปลอดภัยจาก Tsinghua University และ Nankai University ได้เปิดเผยช่องโหว่วิกฤตใน Dnsmasq ซึ่งเป็นซอฟต์แวร์ DNS ที่ใช้กันอย่างแพร่หลายในเราเตอร์และอุปกรณ์เครือข่ายนับไม่ถ้วนทั่วโลก ช่องโหว่นี้ได้รับชื่อว่า SHAR Attack (Single-character Hijack via ASCII Resolver-silence) ซึ่งช่วยให้ผู้โจมตีสามารถวางยาพิษใน DNS cache ได้โดยการใช้ประโยชน์จากวิธีที่ซอฟต์แวร์จัดการกับ query ที่มีอักขระพิเศษ
ตัวอักษรที่เสี่ยงต่อการโจมตี:
- ตัวอักษรพิเศษที่ทำให้เกิดการเงียบของระบบต้นทาง: ~, !, *, _
- ซอฟต์แวร์ที่ได้รับผลกระทบ: Dnsmasq (ทุกเวอร์ชัน)
- ผลกระทบ: การปลอมแปลงแคชของชื่อโดเมนใดก็ได้
- ประเภทการโจมตี: Off-path ไม่จำเป็นต้องใช้การแยกส่วน IP
ปัญหาหลัก: การตอบสนองแบบเงียบจาก Upstream
ช่องโหว่นี้มีจุดศูนย์กลางอยู่ที่ความไม่ตรงกันพื้นฐานในวิธีที่คอมโพเนนต์ DNS ต่างๆ จัดการกับ query ที่มีอักขระพิเศษ เมื่อ Dnsmasq ได้รับ DNS query ที่มีอักขระเช่น ~, !, หรือ* มันจะส่งต่อคำขอไปยัง upstream DNS server อย่างซื่อสัตย์ อย่างไรก็ตาม upstream resolver บางตัวจะทิ้ง query เหล่านี้อย่างเงียบๆ แทนที่จะตอบกลับด้วยข้อความแสดงข้อผิดพลาดที่เหมาะสม สิ่งนี้สร้างสถานการณ์อันตรายที่ Dnsmasq รอการตอบสนองที่จะไม่มีวันมาอย่างไม่มีกำหนด
ในช่วงเวลารอที่ยาวนานนี้ ผู้โจมตีสามารถใช้ประโยชน์จาก birthday paradox เพื่อ brute-force ทั้ง 16-bit transaction ID และ 16-bit source port แม้ว่าสิ่งนี้จะแสดงถึงความเป็นไปได้มากกว่า 4 พันล้านการผสมผสาน แต่ความเป็นจริงทางคณิตศาสตร์นั้นเอื้ออำนวยต่อผู้โจมตีมากกว่าที่ปรากฏ
การอภิปรายของชุมชนเกี่ยวกับรายละเอียดทางเทคนิค
การเปิดเผยนี้ได้จุดประกายการอภิปรายทางเทคนิคอย่างเข้มข้นในหมู่ผู้เชี่ยวชาญ DNS สมาชิกชุมชนบางคนโต้แย้งว่าการกำหนดกรอบอักขระพิเศษนั้นทำให้เข้าใจผิด โดยชี้ไปที่ RFC 2181 ซึ่งระบุอย่างชัดเจนว่าสตริงไบนารีใดๆ สามารถใช้ใน domain name ได้ ปัญหาที่แท้จริง พวกเขาโต้แย้ง อยู่ที่ upstream resolver ที่ทิ้งคำขอที่ถูกต้องอย่างไม่ถูกต้องและความล้มเหลวของ Dnsmasq ในการจัดการกับการตอบสนองที่หายไปอย่างเหมาะสม
คนอื่นๆ สังเกตว่าผู้ให้บริการ DNS หลักเช่น Google 8.8.8.8 และ Cloudflare 1.1.1.1 ตอบสนองต่อ query เหล่านี้อย่างถูกต้องด้วยข้อความแสดงข้อผิดพลาดที่เหมาะสม ซึ่งปิดหน้าต่างการโจมตีได้อย่างมีประสิทธิภาพ สิ่งนี้บ่งชี้ว่าผลกระทบของช่องโหว่นี้แตกต่างกันอย่างมากขึ้นอยู่กับว่า upstream DNS server ตัวไหนที่ถูกกำหนดค่าไว้
ตัวเลือกในการแก้ไขปัญหา:
- แบบเร่งด่วน: เปลี่ยนไปใช้ Google DNS ( 8.8.8.8 ) หรือ Cloudflare ( 1.1.1.1 )
- ความปลอดภัยในการส่งข้อมูล: เปิดใช้งาน DNS-over-HTTPS ( DoH ) หรือ DNS-over-TLS ( DoT )
- ระยะยาว: นำ DNSSEC validation มาใช้งาน
- ระดับเครือข่าย: ติดตั้ง DNS cookies เพื่อการป้องกันเพิ่มเติม
ผลกระทบการโจมตีในทางปฏิบัติ
นักวิจัยได้แสดงให้เห็นอัตราความสำเร็จ 100% ในการโจมตี 20 ครั้ง โดยมีเวลาดำเนินการเฉลี่ยประมาณ 9,469 วินาที (ประมาณ 2.6 ชั่วโมง) เวลานี้ทำให้การโจมตีเป็นไปได้ในสถานการณ์จริง โดยเฉพาะอย่างยิ่งเมื่อพิจารณาว่าการติดตั้ง Dnsmasq หลายตัวทำงานบนเราเตอร์ของผู้บริโภคที่อาจไม่เคยได้รับการอัปเดตความปลอดภัย
ช่องโหว่นี้กลายเป็นเรื่องที่น่ากังวลเป็นพิเศษเมื่อรวมกับเทคนิคการโจมตีที่มีอยู่เช่น SADDNS และ Tudoor ซึ่งนักวิจัยระบุว่าสามารถขยายผลได้ด้วยช่องโหว่นี้ ความสามารถในการวางยาพิษ DNS cache โดยไม่ต้องใช้เทคนิคขั้นสูงหรือการวางตำแหน่งเครือข่ายช่วยลดอุปสรรคสำหรับผู้โจมตีที่มีศักยภาพอย่างมีนัยสำคัญ
สstatisticsการโจมตี:
- อัตราความสำเร็จ: 20/20 (100%) ความพยายามที่สำเร็จ
- เวลาดำเนินการเฉลี่ย: ~9,469 วินาที (2.6 ชั่วโมง)
- พื้นผิวการโจมตี: การบังคับแบบ 32-bit (16-bit TxID + 16-bit source port)
- แพ็กเก็ตที่จำเป็นอย่างมีประสิทธิภาพ: ~65,535 (เนื่องจาก birthday paradox)
กลยุทธ์การบรรเทาและแนวทางแก้ไขระยะยาว
ในขณะที่นักวิจัยแนะนำให้ใช้กลไกการตรวจจับสำหรับความเงียบของ upstream และการจำกัดอัตราคล้ายกับ PowerDNS การอภิปรายของชุมชนเผยให้เห็นว่าแนวทางแก้ไขพื้นฐานอยู่ที่การตรวจสอบความถูกต้องด้วยการเข้ารหัส DNSSEC ซึ่งออกแบบมาเพื่อจัดการกับการโจมตี DNS spoofing โดยเฉพาะ ยังคงเป็นการป้องกันที่แข็งแกร่งที่สุดต่อความพยายามวางยาพิษ cache
อย่างไรก็ตาม ความเป็นจริงคือการนำ DNSSEC มาใช้ยังคงมีจำกัด และหลายโดเมนที่จะเป็นเป้าหมายในการโจมตีดังกล่าวขาดการลงนามที่เหมาะสม สำหรับการป้องกันทันที ผู้ดูแลเครือข่ายสามารถเปลี่ยนไปใช้ผู้ให้บริการ DNS สาธารณะหลักที่จัดการกับ query ที่มีรูปแบบผิดอย่างถูกต้อง หรือใช้ DNS-over-HTTPS (DoH) และ DNS-over-TLS (DoT) เพื่อเพิ่มการเข้ารหัสการขนส่ง
การเปิดเผยนี้เน้นย้ำถึงปัญหาที่กว้างขึ้นเกี่ยวกับช่องโหว่ที่มีอยู่ในโปรโตคอล DNS ซึ่งเป็นที่รู้จักมาตั้งแต่ปี 1993 แต่ยังคงส่งผลกระทบต่อระบบสมัยใหม่เนื่องจากการใช้งานที่แพร่หลายของโปรโตคอลและความท้าทายในการใช้มาตรการรักษาความปลอดภัยที่ครอบคลุมในสภาพแวดล้อมเครือข่ายที่หลากหลาย
อ้างอิง: [Dnsmasq-discuss] [Security Report] Critical Cache Poisoning Vulnerability in Dnsmasq