เหตุการณ์ที่ตั้งใจหา RCE ด้วยเงิน $20 แต่บังเอิญกลายเป็นผู้ดูแล .mobi

 (labs.watchtowr.com)
2 คะแนน โดย GN⁺ 2024-09-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • watchTowr Labs จดทะเบียนโดเมน dotmobiregistry.net ที่หมดอายุแล้วด้วยเงินประมาณ $20 ทำให้ควบคุม hostname ของเซิร์ฟเวอร์ WHOIS เดิมของ .mobi ได้ และยืนยันว่าไคลเอนต์ WHOIS รุ่นเก่า รวมถึงกระบวนการตรวจสอบใบรับรอง TLS/SSL ยังคงเชื่อถือที่อยู่นั้นอยู่
  • แม้เซิร์ฟเวอร์ WHOIS อย่างเป็นทางการของ .mobi จะย้ายไปที่ whois.nic.mobi แล้ว แต่เครื่องมือจำนวนมากยังคง hardcode ที่อยู่เดิม whois.dotmobiregistry.net และส่งคำค้นหาไปเรื่อย ๆ
  • หลังจากเปิดใช้เซิร์ฟเวอร์ WHOIS ชั่วคราวเมื่อวันที่ 30 สิงหาคม 2024 จนถึงวันที่ 4 กันยายน มี ระบบที่ไม่ซ้ำกันมากกว่า 135,000 ระบบ และคำค้นหา 2.5 ล้านครั้งเข้ามา แสดงให้เห็นว่าโดเมน legacy ที่ถูกปล่อยทิ้งไว้ยังเชื่อมโยงกับโครงสร้างพื้นฐานอินเทอร์เน็ตจริงอย่างกว้างขวาง
  • ผู้ออกใบรับรอง TLS/SSL บางรายใช้ การยืนยันอีเมลผ่าน WHOIS เพื่อตรวจสอบความเป็นเจ้าของโดเมน .mobi และในการทดสอบกับ GlobalSign มีการแสดง whois@watchtowr.com เป็นหนึ่งในอีเมลผู้สมัครสำหรับยืนยัน microsoft.mobi
  • นักวิจัยไม่ได้ออกใบรับรองที่เป็นอันตรายจริง และต่อมา NCSC ของสหราชอาณาจักรกับ ShadowServer ได้ดำเนินการเชื่อมโดเมนดังกล่าวเข้ากับ sinkhole เพื่อ proxy คำตอบ WHOIS ของ .mobi ที่ถูกต้องตามกฎหมาย

โดเมนหมดอายุราคา $20 ฟื้นคืนชีพเป็นโครงสร้างพื้นฐาน WHOIS

  • เป้าหมายเดิมของ watchTowr Labs คือการหา RCE ที่นำไปใช้โจมตีได้จริง ในกระบวนการที่ไคลเอนต์ WHOIS parse คำตอบจากเซิร์ฟเวอร์
  • ในการทดลองช่วงแรก พวกเขาปลอมเป็นเซิร์ฟเวอร์ WHOIS แล้วส่งสตริงยาวกลับไป และยืนยันว่าไคลเอนต์บางตัว crash ได้ง่าย
  • อย่างไรก็ตาม หากผู้โจมตีต้องการควบคุมคำตอบ WHOIS โดยทั่วไปต้องมีอย่างใดอย่างหนึ่งต่อไปนี้
    • MITM ที่ดักทราฟฟิก WHOIS ในชั้นเครือข่าย
    • สิทธิ์เข้าถึงเซิร์ฟเวอร์ WHOIS จริง
    • WHOIS referral ที่ชี้ไปยังเซิร์ฟเวอร์ที่ผู้โจมตีควบคุม
  • เงื่อนไขเหล่านี้เป็นอุปสรรคสูงในการโจมตีจริง แต่สถานการณ์เปลี่ยนไปเมื่อโดเมนเซิร์ฟเวอร์ WHOIS เดิมของ .mobi หมดอายุ
  • เซิร์ฟเวอร์ WHOIS ของ .mobi เคยย้ายจาก whois.dotmobiregistry.net ไปเป็น whois.nic.mobi และโดเมนเดิม dotmobiregistry.net อยู่ในสถานะหมดอายุราวเดือนธันวาคม 2023
  • watchTowr จดทะเบียนโดเมนนี้ แล้ววางเซิร์ฟเวอร์ WHOIS ไว้หลัง whois.dotmobiregistry.net เพื่อตรวจสอบว่าไคลเอนต์ WHOIS ที่ hardcode ที่อยู่เดิมยังคงส่งคำค้นหาหรือไม่

พื้นผิวโจมตีที่เกิดจากการ hardcode ที่อยู่เซิร์ฟเวอร์ WHOIS

  • WHOIS ใช้เซิร์ฟเวอร์แยกกันตามแต่ละ TLD แต่กลไกมาตรฐานสำหรับให้ไคลเอนต์ค้นหาเซิร์ฟเวอร์นั้นแบบเรียลไทม์ยังอ่อนแอ
  • ในทางปฏิบัติ เครื่องมือ WHOIS มักอ้างอิงรายการข้อความที่ IANA เผยแพร่ แล้ว hardcode ที่อยู่เซิร์ฟเวอร์ในช่วงพัฒนา
  • เมื่อที่อยู่เซิร์ฟเวอร์ไม่ค่อยเปลี่ยน ปัญหานี้จึงไม่ค่อยปรากฏ แต่หากที่อยู่เปลี่ยนและโดเมนเดิมหมดอายุ ไคลเอนต์เก่าก็อาจส่งคำค้นหาไปยังที่อยู่ที่ถูกเลิกใช้ต่อไปได้
  • watchTowr ตอบคำขอ WHOIS ที่เข้ามายังเซิร์ฟเวอร์ lglass และส่งข้อมูล WHOIS ปลอมที่ทำให้ดูเหมือนว่าเจ้าของเป้าหมายทุกคำค้นหาคือ watchTowr
  • ในคำตอบยังมี ASCII art และคำขอให้หยุดส่งคำค้นหารวมอยู่ด้วย

ปริมาณและแหล่งที่มาของคำค้นหาที่สังเกตได้

  • หลังจากเปิดใช้เซิร์ฟเวอร์ WHOIS เมื่อวันที่ 30 สิงหาคม 2024 ภายในไม่กี่ชั่วโมงมี IP ต้นทางที่ไม่ซ้ำกันมากกว่า 76,000 รายการ ส่งคำค้นหาเข้ามา
  • ในเวลาประมาณสองวัน มีคำค้นหา 1.3 ล้านครั้ง สะสมใน SQLite DB และ ณ วันที่ 4 กันยายน 2024 พบคำค้นหา 2.5 ล้านครั้ง กับ ระบบที่ไม่ซ้ำกันมากกว่า 135,000 ระบบ
  • แหล่งที่มาของคำค้นหารวมถึงผู้รับจดทะเบียนโดเมนรายใหญ่และเว็บไซต์ที่ให้ฟังก์ชัน WHOIS
    • domain.com
    • godaddy.com
    • who.is
    • whois.ru
    • smallseo.tools
    • seocheki.net
    • centralops.net
    • name.com
    • webchart.org
  • บริการวิเคราะห์ความปลอดภัยก็ใช้เซิร์ฟเวอร์ WHOIS เดิมของ .mobi เช่นกัน
    • urlscan.io ใช้ผล WHOIS ดังกล่าวในหน้าโดเมน .mobi
    • VirusTotal ส่งคำค้นหาไปยังเซิร์ฟเวอร์ WHOIS ชั่วคราวของ watchTowr แล้วแสดงผลลัพธ์
  • พบเมลเซิร์ฟเวอร์และตัวกรองสแปมจำนวนมากด้วย
    • ตัวกรองสแปมสามารถทำ WHOIS lookup กับโดเมนของผู้ส่งได้
    • ครอบคลุมตั้งแต่ cheapsender.email ไปจนถึงโฮสต์อย่าง mail.bdcustoms.gov.bd ที่ดูเหมือนเป็นโครงสร้างพื้นฐานของรัฐบาลบังกลาเทศ
  • พบที่อยู่ที่เกี่ยวข้องกับ .gov จากหลายประเทศ
    • Argentina, Pakistan, India, Bangladesh, Indonesia, Bhutan, Philippines, Israel, Ethiopia, Ukraine, USA
    • ตัวอย่างที่เกี่ยวข้องกับ Brazil ได้แก่ antispam.ap.gov.br, master.aneel.gov.br
  • ในแหล่งที่มาจาก .mil มี Swedish Armed Forces ถูกยกเป็นตัวอย่าง
  • ยังพบแหล่งที่มาจาก .edu และบริษัทความปลอดภัย โดยมีการกล่าวถึง Group-IB, Detectify, Censys เป็นต้น
  • หาก .gov และเมลเซิร์ฟเวอร์ส่งคำค้นหาไปยังเซิร์ฟเวอร์ WHOIS ทุกครั้งที่รับอีเมลจากโดเมน .mobi ก็อาจเกิดความเป็นไปได้ในการ สังเกตแบบ passive ว่าใครสื่อสารกับใคร

ช่องโหว่ของไคลเอนต์ WHOIS รุ่นเก่าและความเป็นไปได้ของ RCE

  • watchTowr ค้นหากรณีก่อนหน้าของช่องโหว่ในการ parse คำตอบ WHOIS และสรุปว่าจากผลการค้นหา CVE ที่เกี่ยวข้อง 26 รายการ เหลือเพียง 3 รายการ ที่เป็นบั๊กซึ่งถูก trigger ได้ด้วยคำตอบ WHOIS ที่ผิดรูปแบบ
  • เหตุผลที่มีกรณีน้อยเช่นนี้อาจเกี่ยวข้องกับความเข้าใจว่าการนำไปใช้โจมตีจริงต้องอาศัยเงื่อนไขตั้งต้นที่ยาก เช่น การควบคุมเซิร์ฟเวอร์ WHOIS ของ TLD
  • phpWHOIS CVE-2015-5243 เป็นช่องโหว่ที่นำข้อมูลจากเซิร์ฟเวอร์ WHOIS ไป execute ด้วย PHP eval ทำให้เกิด RCE ได้
    • โค้ดที่มีช่องโหว่ escape เฉพาะ " จากสตริงคำตอบ WHOIS แบบไม่สมบูรณ์ ก่อนส่งต่อให้ eval
    • บทวิเคราะห์ของ Netitude นำเสนอ payload ตัวอย่างอย่าง ”;phpinfo();//
    • phpWHOIS เวอร์ชันที่มีช่องโหว่ hardcode whois.dotmobiregistry.net ไว้
  • Fail2Ban CVE-2021-32749 เป็นช่องโหว่ที่ output ของ WHOIS ถูกส่งต่อไปยังเครื่องมือ mail โดยไม่ได้ทำความสะอาดอย่างเหมาะสม ทำให้เกิด command injection ได้
    • Fail2Ban สามารถค้นหาข้อมูลเจ้าของ IP ที่ถูกบล็อกด้วย WHOIS แล้วใส่ไว้ในอีเมลถึงผู้ดูแลระบบ
    • อย่างไรก็ตาม ช่องโหว่นี้เกิดกับ WHOIS lookup สำหรับ IP address ดังนั้นการควบคุมเซิร์ฟเวอร์ WHOIS ของโดเมน .mobi ที่ watchTowr ได้มาเพียงอย่างเดียวจึงยังไม่เข้าถึงโดยตรง
  • การ execute โค้ดจริงยังต้องมีทั้งไคลเอนต์ที่ยังส่งคำค้นหาไปยังเซิร์ฟเวอร์ WHOIS เดิมของ .mobi และ implementation ของไคลเอนต์ที่มีช่องโหว่ร่วมกัน

ผลกระทบถึงกระบวนการตรวจสอบใบรับรอง TLS/SSL

  • ผู้ออกใบรับรอง TLS/SSL บางรายรองรับวิธี parse อีเมลผู้ติดต่อฝ่ายดูแล จากข้อมูล WHOIS เพื่อยืนยันความเป็นเจ้าของโดเมน แล้วส่งลิงก์ยืนยันไปยังอีเมลนั้น
  • ตัวอย่างผู้ออกใบรับรองหรือ reseller ที่ watchTowr ระบุว่ารองรับการยืนยันความเป็นเจ้าของผ่าน WHOIS มีดังนี้
    • Trustico
    • Comodo
    • SSLS
    • GoGetSSL
    • GlobalSign
    • DigiSign
    • Sectigo
  • ในการทดสอบ GoGetSSL เมื่ออัปโหลด CSR ของ watchTowr.mobi สมมติ ระบบไม่แสดง whois@watchtowr.com ที่ watchTowr ตั้งไว้ และแสดงเพียงอีเมล placeholder ที่ดูเหมือนว่า WHOIS ยังไม่สำเร็จ
  • ในการทดสอบ Entrust มีการ parse ระเบียน WHOIS ที่ถูกต้องตามกฎหมายของ microsoft.mobi และแสดงเฉพาะอีเมลในโดเมน microsoft.com เป็นผู้สมัครสำหรับยืนยัน ส่วน watchTowr.mobi ไม่ถูก parse
  • ในการทดสอบ GlobalSign ตอนแรกดูเหมือนว่าจะ parse ระเบียน WHOIS ของ microsoft.mobi ไม่ได้ แต่เมื่อ watchTowr คัดลอกรูปแบบ output ของ microsoft.mobi จากเซิร์ฟเวอร์ WHOIS ที่ถูกต้องตามกฎหมายแล้วปรับให้เซิร์ฟเวอร์ WHOIS ของตนเองส่งออก ผลลัพธ์ก็เปลี่ยนไป
  • GlobalSign ส่งคำค้นหาไปยังเซิร์ฟเวอร์ WHOIS ของ watchTowr และ parse whois@watchtowr.com จากคำตอบเพื่อนำเสนอเป็นอีเมลยืนยันสำหรับ microsoft.mobi
  • watchTowr หยุดที่จุดนี้ และ ไม่ได้ออกใบรับรอง TLS/SSL ที่เป็นอันตรายจริง
  • ลำดับการโจมตีในเชิงทฤษฎีเป็นดังนี้
    • วางเซิร์ฟเวอร์ WHOIS ที่เป็นอันตรายไว้บน hostname เดิมที่เคยมีอำนาจ
    • พยายามซื้อใบรับรอง TLS/SSL สำหรับโดเมน .mobi เป้าหมาย
    • ผู้ออกใบรับรอง query WHOIS แล้วส่งอีเมลยืนยันไปยังอีเมลของผู้โจมตี ไม่ใช่เจ้าของจริง
    • หากผู้โจมตีคลิกลิงก์ ก็อาจได้รับใบรับรอง TLS/SSL สำหรับโดเมนเป้าหมาย
  • หากมีความสามารถนี้ ในทางทฤษฎีอาจโจมตีได้ เช่น ดักทราฟฟิกหรือปลอมเป็นเซิร์ฟเวอร์เป้าหมาย

การดำเนินการภายหลังและปัญหาที่ยังเหลือ

  • ก่อนการเผยแพร่ NCSC ของสหราชอาณาจักรและ ShadowServer Foundation ร่วมกันรับมือ
  • โดเมน dotmobiregistry.net และ hostname whois.dotmobiregistry.net ถูกเชื่อมไปยัง ระบบ sinkhole ที่ ShadowServer ให้บริการ
  • sinkhole ดังกล่าว proxy คำตอบ WHOIS ที่ถูกต้องตามกฎหมายสำหรับโดเมน .mobi
  • มีการจัดเตรียมกระบวนการแจ้งผู้เกี่ยวข้องที่ได้รับผลกระทบด้วย
  • กรณีนี้แสดงให้เห็น ข้อบกพร่องเชิงโครงสร้าง ที่เกิดขึ้นเมื่อโครงสร้างพื้นฐาน legacy, โดเมนที่ถูกปล่อยทิ้ง, การประมวลผลที่อิง WHOIS และกระบวนการตรวจสอบของผู้ออกใบรับรอง TLS/SSL ทำงานร่วมกัน
  • ผู้ที่ทำ MITM ได้ก็สามารถปลอมข้อมูล WHOIS แล้วพยายามโจมตีในรูปแบบเดียวกันได้เช่นกัน และแม้จะมีกลไกอย่าง Certificate Transparency ก็ยังมีอุปสรรคด้านปฏิบัติการสำหรับการโจมตีในวงกว้าง

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

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

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

  • กว่าจะมาถึงสถานการณ์นี้คงมีความผิดพลาดของหลายคนซ้อนกัน แต่มีสิ่งหนึ่งที่ชัดเจนว่าสามารถป้องกันการโจมตีแบบนี้ได้: อย่าปล่อยให้โดเมนหมดอายุเด็ดขาด
    เซิร์ฟเวอร์ WHOIS ของโดเมนระดับบนสุด .MOBI ถูกย้ายจาก whois.dotmobiregistry.net ไปเป็น whois.nic.mobi เมื่อหลายปีก่อน และดูเหมือนว่าโดเมน dotmobiregistry.net ถูกปล่อยให้หมดอายุค้างไว้ราวเดือนธันวาคม 2023
    เมื่อบริษัทเริ่มใช้โดเมนใหม่โดยคิดว่าแค่ปีละ 10 ดอลลาร์ โดเมนนั้นก็กลายเป็นสินทรัพย์ที่ต้องจ่าย ปีละ 10 ดอลลาร์ไปตลอดกาล ในทางปฏิบัติ เมื่อโดเมนเคยเชื่อมโยงกับธุรกิจแล้ว ก็ไม่สามารถตัดความเชื่อมโยงนั้นให้ขาดได้อย่างสมบูรณ์

    • นี่เป็นเหตุผลที่ชัดเจนที่สุดว่า ทำไม Verisign ถึงเป็น ผู้ให้บริการผูกขาด และควรถูกกำกับดูแลเหมือนสาธารณูปโภคอย่างไฟฟ้าหรือน้ำประปา คำกล่าวที่ว่ามีทางเลือกและไม่ถูกผูกมัดนั้นใกล้เคียงภาพลวงตา เพราะเมื่อซื้อโดเมนมาใช้แล้ว ในทางปฏิบัติก็ถูกผูกไว้ตลอดไป Verisign เองก็รู้เรื่องนี้ จึงต่อสู้อย่างสุดกำลังเพื่อรักษาการผูกขาดไว้
    • แม้แต่ Google ก็เคยพลาดเรื่องนี้อยู่ช่วงหนึ่ง
      https://money.cnn.com/2016/01/29/technology/google-domain-pu...
    • ควรใช้ ซับโดเมน เสมอ สำหรับบริษัทแล้ว โดเมนปีละ 10 ดอลลาร์เพียงโดเมนเดียวก็เพียงพอตลอดอายุองค์กร
    • ชอบประเด็นนี้ ทำให้นึกถึงบล็อกของ Backblaze ที่คำนวณความน่าจะเป็นที่ดิสก์จะเสียจำนวนมากจนทำให้ข้อมูลผู้ใช้สูญหาย
      สุดท้ายแล้วมองว่าค่าที่คำนวณได้เองไม่ได้สำคัญนัก เพราะโอกาสที่จะลืมจ่ายเงินเนื่องจากบัตรเครดิตหมดอายุหรืออีเมลแจ้งเตือนต่ออายุถูกกรองเป็นสแปมนั้นสูงกว่า
      บริษัทขนาดใหญ่ไม่ลืมจ่ายค่าโดเมนกันได้อย่างไร? มอบหมายให้นายทะเบียนราคาแพงต่ออายุให้เป็นระยะเวลาใกล้ “อนันต์” หรือเปล่า? ดูเหมือนเป็น ปัญหาการดำเนินธุรกิจ ที่ค่อนข้างยาก

  • รู้สึกเหมือนว่าวันหนึ่งตื่นเช้ามาแล้วจะได้เห็นข่าวว่าอินเทอร์เน็ตทั้งก้อนหายไป เพราะมีใครบางคนในห้องโรงแรมห่างไกลทำอะไรสักอย่างด้วย Raspberry Pi ที่เชื่อมต่อกับฮอตสปอต Wi-Fi ของคาเฟ่ใกล้ๆ

    • ทำให้นึกถึงตอนอยู่หอพักมหาวิทยาลัย ที่มีใครบางคนเอาเราเตอร์อะไรก็ไม่รู้จากบ้านมาเสียบ แล้วปล่อย ที่อยู่ DHCP มั่วๆ จนอินเทอร์เน็ตพัง นี่ให้ความรู้สึกเหมือนเรื่องนั้นเกิดขึ้นในระดับทั้งโลก
    • จริงอยู่ที่หลายสิ่งตั้งอยู่บนความหวังและคำอธิษฐานมากกว่าที่คิด [0] แต่อินเทอร์เน็ตถูกออกแบบมาให้ทนทานโดยโครงสร้าง [1] กรณีนี้ขอบเขตจำกัดอยู่ที่ .mobi
      [0] https://xkcd.com/2347/
      [1] https://en.wikipedia.org/wiki/ARPANET#Debate_about_design_go...
    • เรื่องนี้เกี่ยวข้องกับข่าวล่าสุด “White House asks agencies to step up internet routing security efforts” [1] ก็เป็นเพียงเรื่องบังเอิญล้วนๆ
      [1] https://news.ycombinator.com/item?id=41482087

  • ทำไมเครื่องมือต่างๆ ถึง ฮาร์ดโค้ด รายชื่อเซิร์ฟเวอร์ WHOIS ไว้ใช้กันนะ?
    ดูเหมือนจะมีวิธีมาตรฐานในการบันทึกข้อมูลนี้ลงใน DNS แต่ลองทดสอบง่ายๆ แล้วพบว่าโดเมนระดับบนสุดจำนวนมากไม่มีเรคคอร์ด ตัวอย่างที่ใช้งานได้คือ dig _nicname._tcp.fr SRV +noall +answer และจะได้ผลลัพธ์เป็น _nicname._tcp.fr. 3588 IN SRV 0 0 43 whois.nic.fr.
    นอกจากนี้ยังมีอินเทอร์เน็ตดราฟต์ที่หมดอายุแล้วเกี่ยวกับเรื่องนี้ด้วย: https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-0...

    • แค่มี mobi.whois.arpa. CNAME whois.nic.mobi ก็แก้ปัญหาได้แล้ว เพียงแต่การทำให้ทุกคนเห็นพ้องและนำวิธีแบบนี้ไปใช้เป็นเรื่องยาก
      อย่างที่ fanf2 กล่าวไว้ด้านล่าง ก็น่าจะเริ่ม query จากเซิร์ฟเวอร์ WHOIS ของ IANA ได้เช่นกัน ถ้า query mobi ที่ https://www.iana.org/whois จะมี whois: whois.nic.mobi กลับมาเป็นส่วนหนึ่งของคำตอบ
    • ในโลกความจริงมี สตริงที่ฮาร์ดโค้ดไว้ มากกว่าที่เราจินตนาการ และมากกว่าที่ควรจะมีอยู่มาก
    • WHOIS น่าจะเก่าแก่กว่าแนวคิดอย่าง SRV record อยู่มาก
    • เครื่องมือแบบนี้มักถูกสร้างขึ้นเพราะความจำเป็นเฉพาะหน้า แล้วเผยแพร่เพื่อให้คนอื่นใช้หรือให้เจ้าตัวกลับมาอ้างอิงภายหลัง “วิศวกร” คนอื่นๆ ก็คัดลอกไปวางโดยไม่ลังเล และเมื่อมันเข้าไปอยู่ในสภาพแวดล้อม production ก็กลายเป็น CVE แบบครั้งนี้
      ความสามารถของนักพัฒนาที่ไม่เพียงพอก็เป็นปัญหาอยู่แล้ว แต่ AI hallucination จะทำให้สถานการณ์นี้เลวร้ายลงอีก

  • เห็นทีมจำนวนมากเกินไปที่ไม่ตระหนักว่า เมื่อเริ่มใช้โดเมนอย่างมีนัยสำคัญแล้ว ในทางปฏิบัติต้องต่ออายุไปจนถึงความตายทางความร้อนของจักรวาล หรืออย่างน้อยก็จนถึงความตายทางความร้อนของทีม
    ไม่ว่าจะเป็นกรณีแบบนี้ หรือ URL เก่าแต่สำคัญที่ยังหลงเหลืออยู่ที่ไหนสักแห่ง หรือสมาชิกทีมเคยใช้อีเมลโดเมนเก่าสมัครบริการไว้ ก็ยากมากที่จะรู้ว่าเมื่อไรจึงจะปล่อยโดเมนเก่าได้จริงๆ

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

  • ทางออกที่แท้จริงของ WHOIS คือ RDAP
    น่าเสียดายที่ไม่ได้บังคับใช้กับโดเมนระดับบนสุดรหัสประเทศ และในบรรดาโดเมนระดับบนสุดที่ไม่ใช่รหัสประเทศ ก็ยังมีหลายแห่งที่ทำงานได้ไม่ถูกต้อง
    https://en.wikipedia.org/wiki/Registration_Data_Access_Proto...
    https://resolve.rs/domains/rdap-missing.html

    • แล้วมันช่วยบรรเทาปัญหาที่อธิบายในบทความได้อย่างไร?

  • เป็นงานที่เจ๋งมาก
    โดเมน dotmobiregistry.net และชื่อโฮสต์ whois.dotmobiregisry.net ตอนนี้ชี้ไปยังระบบ sinkhole ที่ ShadowServer จัดเตรียมไว้ และระบุว่าระบบนี้ทำหน้าที่พร็อกซีคำตอบ WHOIS ปกติของโดเมน .mobi
    ถ้าโดเมนเหล่านี้ตั้งใจจะเลิกใช้งาน การส่งคำตอบอย่าง 404 กลับไปน่าจะดีกว่า การปล่อยให้มันยังทำงานเหมือนปกติต่อไปจะลด แรงจูงใจในการย้ายไปใช้โดเมนทางการ

    • Whois ไม่รองรับรหัสสถานะ HTTP แต่ sinkhole ของ ShadowServer ตอบกลับแบบนี้:
      Domain not found.
      >>> Please update your code or tell your system administrator to use whois.nic.mobi, the authoritative WHOIS server for this domain. <<<
    • จากบทความ ดูเหมือนว่ามันเสียมาหลายปีแล้ว และไคลเอนต์จำนวนมากก็ไม่ได้สังเกตเห็น

  • ผมมองว่าแนวทางของคอมพิวเตอร์โดยรวมเองถูกกำหนดให้ล้มเหลวอยู่แล้ว มันพึ่งพาความปลอดภัยที่สมบูรณ์แบบ และตั้งสมมติฐานว่าความปลอดภัยนั้นทำได้ด้วย การตรวจสอบ SBOM กับการอัปเดตบ่อย ๆ
    แต่ในความเป็นจริงไม่มีทางเป็นแบบนั้น แค่ log4j อย่างเดียว 40% ของการดาวน์โหลดทั้งหมดก็ยังเป็นเวอร์ชันที่มีช่องโหว่แล้ว ยังไม่ต้องพูดถึงกรณีที่บริษัทในซัพพลายเชนปิดกิจการ หรือเลิกดูแลคอมโพเนนต์บางตัว
    เหมือนร่างกายของเราที่เป็นสนามรบกับจุลินทรีย์อยู่เสมอ ทุกอย่างก็ย่อมเต็มไปด้วยบั๊กและรูโหว่อยู่ตลอดเวลา

    • ไม่ใช่หรอก เราสามารถเขียนโค้ดที่ดีและโค้ดที่เชื่อถือได้อย่างช้า ๆ แต่มั่นคง แล้วใช้มันสร้างเครื่องมือที่ดีขึ้น จากนั้นก็ใช้เครื่องมือนั้นสร้างสิ่งถัดไปได้
      อาจต้องใช้เวลาหลายสิบปี แต่เส้นทางก็ดูค่อนข้างชัดเจน แค่ทุ่มเทความพยายาม นำความรู้ที่ได้จาก “บทเรียน” ทุกครั้งมาใช้ และอย่าหยุดก็พอ

  • โดยรวมแล้วชอบบรรยากาศแบบ “เราไม่ได้อยากทำเรื่องนี้เลย แต่สถานการณ์มันใหญ่ขึ้นเรื่อย ๆ และทุกขั้นตอนเราก็ได้อะไรที่ใหญ่กว่าที่คาดไว้”
    ถ้าคนที่คัดค้านยอมฟังและแก้การ parsing ผู้เขียนบทความอาจไม่ต้องลำบากขนาดนี้ก็ได้

  • ถ้ามองกลับกัน นี่หมายความว่าเราต้องเชื่อว่าเซิร์ฟเวอร์ WHOIS ทุกเครื่องทั่วโลกเป็นของจริงและปลอดภัยอยู่เสมอหรือเปล่า?
    โดยเฉพาะจากมุมมองของผู้ออกใบรับรองที่ทำการตรวจสอบ TLS คงไม่มีใครอยากรู้ว่าการรัน whois somethingarbitrary.ru จะทำให้เสี่ยงต่อ การรันโค้ดจากระยะไกล เพราะเซิร์ฟเวอร์รัสเซีย