จ่าย $20 เพื่อทำ RCE ได้สำเร็จ แล้วดันกลายเป็นแอดมินของ .mobi โดยบังเอิญ

 (labs.watchtowr.com)
2 คะแนน โดย GN⁺ 2024-09-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

สรุป

  • ภูมิหลังของงานวิจัย

    • งานวิจัยนี้เริ่มต้นขึ้นเพื่อความสนุก โดยทำร่วมกับเพื่อนร่วมงาน
    • ศึกษาว่าช่องโหว่ของไคลเอนต์ WHOIS สามารถถูกนำไปใช้โจมตีได้จริงในโลกความเป็นจริงหรือไม่
    • พบว่าเซิร์ฟเวอร์ WHOIS ของ TLD .MOBI ถูกย้ายออกไป และโดเมนเดิมหมดอายุแล้ว
    • จึงซื้อโดเมนนั้นในราคา $20 และตั้งค่าเป็นเซิร์ฟเวอร์ WHOIS

  • ผลการวิจัย

    • มีระบบมากกว่า 135,000 ระบบส่งคิวรีมายังเซิร์ฟเวอร์ WHOIS
    • แหล่งที่มาของคิวรีหลัก ได้แก่ หน่วยงาน .GOV, .MIL, เครื่องมือด้านไซเบอร์ซีเคียวริตี้ และบริษัทต่างๆ
    • หน่วยงานออกใบรับรองใช้เซิร์ฟเวอร์ WHOIS เพื่อตรวจสอบความเป็นเจ้าของโดเมน
    • ผ่าน GlobalSign ผู้วิจัยสามารถตั้งค่าอีเมลเจ้าของโดเมนของ microsoft.mobi เป็น whois@watchtowr.com ได้
    • ส่งผลให้กระบวนการของ CA ถูกทำให้ไร้ประสิทธิภาพ

  • สถานการณ์การโจมตี

    • การใช้ประโยชน์จากช่องโหว่ของไคลเอนต์ WHOIS ต้องมีเงื่อนไขต่อไปนี้:
      • การโจมตีแบบ MiTM
      • การเข้าถึงเซิร์ฟเวอร์ WHOIS
      • การตั้งค่า WHOIS referral
    • ทีมวิจัยพิสูจน์ความเป็นไปได้ของการโจมตีด้วยการตั้งค่าเซิร์ฟเวอร์ WHOIS และได้รับคิวรีจริง

  • ช่องโหว่ที่เฉพาะเจาะจง

    • phpWHOIS (CVE-2015-5243): รันข้อมูลที่ได้รับจากเซิร์ฟเวอร์ WHOIS ผ่านฟังก์ชัน PHP eval ทำให้เกิด RCE
    • Fail2Ban (CVE-2021-32749): ตรวจสอบผลลัพธ์จากไคลเอนต์ WHOIS ไม่รัดกุมพอ จึงเกิดช่องโหว่ command injection

  • ผลกระทบในโลกความเป็นจริง

    • โครงสร้างพื้นฐานอินเทอร์เน็ตจำนวนมากยังอ้างอิงเซิร์ฟเวอร์ WHOIS รุ่นเก่า
    • นายทะเบียนโดเมนรายใหญ่ เว็บไซต์ที่มีฟังก์ชัน WHOIS และเครื่องมือด้านไซเบอร์ซีเคียวริตี้จำนวนมากได้รับผลกระทบ
    • หน่วยงานออกใบรับรอง TLS/SSL ใช้ข้อมูล WHOIS เพื่อตรวจสอบความเป็นเจ้าของโดเมน

  • แนวทางแก้ไข

    • ทีมวิจัยร่วมมือกับ ShadowServer เพื่อเปลี่ยนโดเมน dotmobiregistry.net ไปเป็นระบบ sinkhole
    • ผลการวิจัยนี้ชี้ให้เห็นปัญหาของโครงสร้างพื้นฐานแบบเลกาซีและช่องโหว่ของหน่วยงานออกใบรับรอง TLS/SSL

สรุปโดย GN⁺

  • งานวิจัยนี้พิสูจน์ว่าช่องโหว่ของไคลเอนต์ WHOIS สามารถถูกนำไปใช้โจมตีได้จริงในโลกความเป็นจริง
  • แสดงให้เห็นว่ากระบวนการยืนยันความเป็นเจ้าของโดเมนของหน่วยงานออกใบรับรอง TLS/SSL สามารถถูกทำให้ไร้ประสิทธิภาพได้อย่างง่ายดาย
  • โครงสร้างพื้นฐานอินเทอร์เน็ตจำนวนมากยังอ้างอิงเซิร์ฟเวอร์ WHOIS รุ่นเก่า ทำให้มีความเสี่ยงด้านความปลอดภัยสูง
  • ผลการวิจัยนี้เน้นย้ำถึงปัญหาของโครงสร้างพื้นฐานแบบเลกาซีและช่องโหว่ของหน่วยงานออกใบรับรอง TLS/SSL
  • โปรเจ็กต์ที่มีฟังก์ชันคล้ายกันคือ Let's Encrypt

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-09-12
ความคิดเห็นจาก Hacker News

  • อย่าปล่อยให้โดเมนหมดอายุเด็ดขาด

    • ถ้าเชื่อมโดเมนเข้ากับธุรกิจ ก็ต้องต่ออายุไปตลอด

  • กลัวว่าอินเทอร์เน็ตจะพังหายไป

    • ใครสักคนสามารถทำให้อินเทอร์เน็ตปั่นป่วนได้ด้วย Raspberry Pi จากในห้องโรงแรม

  • สงสัยเกี่ยวกับเครื่องมือที่ hardcode รายการเซิร์ฟเวอร์ WHOIS

    • มีวิธีมาตรฐานในการลงทะเบียนผ่าน DNS แต่หลาย TLD ไม่มีระเบียนนี้
    • ตัวอย่าง: dig _nicname._tcp.fr SRV +noall +answer

  • การต่ออายุโดเมนเก่าเป็นเรื่องสำคัญ

    • ถ้าใช้โดเมนแล้วก็ต้องต่ออายุไปจนกว่าทีมจะเลิกใช้งาน
    • เป็นเรื่องยากที่จะรู้ว่าควรปล่อยโดเมนเก่าเมื่อไร

  • โดเมน dotmobiregistry.net ถูกรีไดเรกต์ไปยังระบบ sinkhole ของ ShadowServer

    • ถ้าโดเมนกำลังจะถูกยกเลิก การตอบกลับเป็น 404 น่าจะดีกว่า

  • แนวทางการเข้าถึงคอมพิวเตอร์นั้นถูกกำหนดให้ล้มเหลว

    • เป็นไปไม่ได้ที่จะบรรลุความปลอดภัยสมบูรณ์แบบด้วยการตรวจ SBOM และอัปเดตถี่ ๆ
    • ทุกระบบจะมีบั๊กและช่องโหว่อยู่เสมอ

  • พื้นที่การโจมตีที่ได้จากการซื้อโดเมนเซิร์ฟเวอร์ WHOIS ที่หมดอายุนั้นมหาศาล

  • ทางออกที่แท้จริงของ WHOIS คือ RDAP

    • ไม่ได้เป็นข้อบังคับสำหรับ ccTLD และ non-ccTLD จำนวนมากก็ใช้งานไม่ได้
    • ลิงก์อ้างอิง: Registration Data Access Protocol

  • น่าสนใจที่มีการเก็บล็อกไว้ในฐานข้อมูล

    • สงสัยเกี่ยวกับการใช้คำสั่ง sqlite3 whois-log-copy.db "select source from queries"|sort|uniq|wc -l

  • แม้พยายามแก้ปัญหา แต่สถานการณ์กลับแย่ลง

    • ถ้าฝ่ายคัดค้านแก้ปัญหาเรื่อง parsing ได้ ก็น่าจะได้ผลลัพธ์ที่ดีกว่านี้