พบการพิมพ์ DNS ของ Mastercard ผิดโดยไม่ถูกตรวจพบเกือบ 5 ปี

 (krebsonsecurity.com)
1 คะแนน โดย GN⁺ 2025-01-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • MasterCard ตั้งค่า ชื่อเซิร์ฟเวอร์ DNS ของ Akamai ตัวหนึ่งที่ใช้ชี้ทราฟฟิกบางส่วนของ mastercard.com ผิดเป็น akam.ne แทนที่จะเป็น akam.net และการพิมพ์ผิดนี้คงอยู่เกือบ 5 ปี ตั้งแต่ 30 มิถุนายน 2020 ถึง 14 มกราคม 2025
  • Philippe Caturegli นักวิจัยความปลอดภัยพบว่า akam.ne ภายใต้โดเมนระดับบนสุดตามรหัสประเทศของไนเจอร์ยังไม่ได้จดทะเบียน จึงใช้เงิน 300 ดอลลาร์และเวลาประมาณ 3 เดือนเพื่อครอบครองโดเมนดังกล่าว และปิดกั้นความเป็นไปได้ในการนำไปใช้ในทางที่ผิด
  • เมื่อเปิดเซิร์ฟเวอร์ DNS บน akam.ne ก็มี คำขอ DNS หลายแสนครั้งต่อวัน จากทั่วโลกเข้ามา และในบรรดาองค์กรที่พิมพ์ผิดแบบเดียวกัน MasterCard เป็นกรณีที่ใหญ่ที่สุด
  • หากโดเมนนี้ถูกนำไปใช้ในทางที่ผิด อาจนำไปสู่การรับอีเมลที่ถูกส่งผิดทาง การได้มาซึ่ง ใบรับรอง SSL/TLS สำหรับเว็บไซต์ที่ได้รับผลกระทบ และการรับข้อมูลยืนยันตัวตนของ Windows บางส่วนแบบพาสซีฟ
  • MasterCard ระบุว่า “ระบบไม่มีความเสี่ยง” และแก้ไขการพิมพ์ผิดแล้ว แต่ภายหลังยังมีคำขอผ่าน Bugcrowd ให้ลบโพสต์ LinkedIn จึงยังเกิดข้อถกเถียงเรื่องวิธีการเปิดเผยข้อมูล

การพิมพ์ DNS ผิดที่ถูกปล่อยทิ้งไว้เกือบ 5 ปี

  • MasterCard ใช้ เซิร์ฟเวอร์ DNS แบบแชร์ของ Akamai 5 ตัว เพื่อชี้ทราฟฟิกบางส่วนของเครือข่าย mastercard.com
  • ตั้งแต่ 30 มิถุนายน 2020 ถึง 14 มกราคม 2025 หนึ่งในนั้นถูกตั้งค่าเป็นชื่อที่ไม่ถูกต้อง
    • ชื่อเซิร์ฟเวอร์ที่ถูกต้องควรลงท้ายด้วย akam.net
    • การตั้งค่าที่มีปัญหาชี้ไปที่ akam.ne
  • akam.ne เป็นโดเมนที่อยู่ภายใต้ขอบเขตการจัดการโดเมนระดับบนสุดตามรหัสประเทศของไนเจอร์ในแอฟริกาตะวันตก

นักวิจัยครอบครองโดเมนไว้ก่อน

  • Philippe Caturegli ผู้ก่อตั้งบริษัทที่ปรึกษาด้านความปลอดภัย Seralys เป็นผู้พบการพิมพ์ผิดนี้
  • Caturegli คาดว่า akam.ne ยังไม่ได้จดทะเบียน จึงครอบครองโดเมนผ่านรีจิสทรีของไนเจอร์
    • ค่าใช้จ่ายอยู่ที่ 300 ดอลลาร์
    • ใช้เวลาเกือบ 3 เดือน กว่าจะจดทะเบียนสำเร็จ
  • เมื่อเปิดใช้งานเซิร์ฟเวอร์ DNS ก็มีคำขอ DNS หลายแสนครั้งต่อวันจากทั่วโลกเข้ามา
  • ไม่ใช่แค่ MasterCard ที่พิมพ์ผิดแบบเดียวกัน แต่เมื่อดูจากจำนวนคำขอที่เข้ามา MasterCard เป็นองค์กรที่ใหญ่ที่สุด

ความเสี่ยงที่โดเมนพิมพ์ผิดอาจสร้างขึ้นได้

  • หาก Caturegli เปิดเซิร์ฟเวอร์อีเมลบน akam.ne เขาอาจรับ อีเมลที่ถูกส่งผิดทาง ซึ่งเดิมควรไปยัง mastercard.com หรือโดเมนอื่นที่ได้รับผลกระทบได้
  • หากใช้สิทธิ์เข้าถึงในทางที่ผิด ก็อาจมีความเป็นไปได้ที่จะได้ ใบรับรอง SSL/TLS ที่สามารถรับและส่งต่อทราฟฟิกของเว็บไซต์ที่ได้รับผลกระทบ
  • ยังมีความเป็นไปได้ที่จะรับข้อมูลยืนยันตัวตนของ Microsoft Windows จากคอมพิวเตอร์พนักงานแบบพาสซีฟ
  • Caturegli ไม่ได้พยายามทำสิ่งเหล่านี้ และแจ้งว่าเขาสามารถโอนโดเมนให้ MasterCard ได้
    • ในการแจ้งเตือนดังกล่าวมีการใส่ผู้เขียน Krebs on Security เป็นผู้รับทราบด้วย

การตอบสนองของ MasterCard และ Bugcrowd

  • ไม่กี่ชั่วโมงต่อมา MasterCard ยอมรับข้อผิดพลาด แต่ระบุว่าไม่มีความเสี่ยงจริงต่อความปลอดภัยในการดำเนินงาน
    • “ระบบไม่มีความเสี่ยง”
    • “การพิมพ์ผิดนี้ได้รับการแก้ไขแล้ว”
  • หลังจากนั้น Caturegli ได้รับข้อความผ่าน Bugcrowd
    • ข้อความมีใจความว่า การที่ Caturegli ครอบครอง akam.ne แล้วเปิดเผยบน LinkedIn ไม่สอดคล้องกับแนวปฏิบัติด้านความปลอดภัยเชิงจริยธรรม
    • ข้อความยังระบุด้วยว่า MasterCard ขอให้ลบโพสต์ดังกล่าว
  • Caturegli ตอบว่าเขาไม่เคยรายงานผ่านโปรแกรม Bugcrowd และได้รายงานปัญหาโดยตรงต่อ MasterCard
  • เขาระบุว่าได้จดทะเบียนโดเมนที่ได้รับผลกระทบก่อนเปิดเผย เพื่อป้องกันการนำไปใช้ในทางที่ผิด และเป็นผู้ออกค่าใช้จ่ายเอง

ขอบเขตผลกระทบที่ DNS cache อาจขยายให้กว้างขึ้น

  • โดยทั่วไป องค์กรจะมีเซิร์ฟเวอร์ DNS แบบ authoritative อย่างน้อย 2 ตัว แต่องค์กรที่มีคำขอจำนวนมากจะใช้โดเมนเซิร์ฟเวอร์ DNS มากขึ้นเพื่อกระจายโหลด
  • เนื่องจาก MasterCard ใช้เซิร์ฟเวอร์ DNS 5 ตัว จึงอาจดูเหมือนว่าหากผู้โจมตียึดได้เพียงหนึ่งตัว ก็จะเห็นคำขอ DNS ทั้งหมดได้ประมาณ หนึ่งในห้า เท่านั้น
  • แต่ในความเป็นจริง ผู้ใช้อินเทอร์เน็ตพึ่งพา public DNS resolver เช่น Cloudflare หรือ Google จึงอาจทำให้ผลกระทบใหญ่ขึ้นได้
    • เพียง resolver หนึ่งตัวสอบถาม nameserver ที่ผิด แล้ว cache ผลลัพธ์ไว้
    • หากตั้งค่า TTL ยาวใน DNS record คำสั่งชี้ทางที่ผิดอาจแพร่ผ่านผู้ให้บริการคลาวด์รายใหญ่ได้
  • Caturegli เห็นว่าหากใช้ TTL ยาว ขอบเขตของการ reroute ทราฟฟิกอาจใหญ่กว่าหนึ่งในห้าอย่างมาก

ซับโดเมนที่มีปัญหาและร่องรอยการจดทะเบียนในอดีต

  • ในสกรีนช็อตที่ Caturegli เปิดเผย เซิร์ฟเวอร์ DNS ที่ตั้งค่าผิดเกี่ยวข้องกับซับโดเมน az.mastercard.com ของ MasterCard
  • ยังไม่ชัดเจนว่าซับโดเมนนี้ถูกใช้งานอย่างไรแน่ชัด
  • จากรูปแบบชื่อ ดูเหมือนเป็นโดเมนที่เกี่ยวข้องกับเซิร์ฟเวอร์โปรดักชันบนคลาวด์ Microsoft Azure และ Caturegli ระบุว่าโดเมนเหล่านี้ resolve ไปยังที่อยู่อินเทอร์เน็ตของ Microsoft
  • akam.ne เคยถูกจดทะเบียนมาก่อนในอดีต
    • ในเดือนธันวาคม 2016 ผู้ใช้ที่ใช้อีเมล um-i-delo@yandex.ru เป็นผู้จดทะเบียน
    • Yandex แสดงว่าบัญชีนี้เป็นของ “Ivan I.” ในมอสโก
    • ตามบันทึก DNS แบบพาสซีฟของ DomainTools.com ตั้งแต่ปี 2016 ถึง 2018 โดเมนนี้เชื่อมกับเซิร์ฟเวอร์อินเทอร์เน็ตในเยอรมนี และหมดอายุในปี 2018
  • อดีตพนักงาน Cloudflare ลิงก์รายงานที่กล่าวถึงกรณีคล้ายกันในคอมเมนต์ใต้โพสต์ LinkedIn ของ Caturegli
    • เป็นกรณีโดเมนพิมพ์ผิดที่บางองค์กรอาจพิมพ์เซิร์ฟเวอร์ DNS ของ AWS awsdns-06.net เป็น awsdns-06.ne
    • ตามข้อมูลของ DomainTools โดเมนพิมพ์ผิดนี้ก็ถูกจดทะเบียนโดยผู้ใช้ Yandex และโฮสต์อยู่กับ Team Internet ซึ่งเป็น ISP เยอรมันรายเดียวกัน

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

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

 
GN⁺ 2025-01-23
ความคิดเห็นจาก Hacker News

  • เนมเซิร์ฟเวอร์ที่เปิดให้จดทะเบียนได้แบบกรณีนี้เป็นเพียงประเภทย่อยที่ค่อนข้างพบได้น้อยของปัญหา dangling DNS เท่านั้น ส่วนที่พบบ่อยกว่าคือกรณีที่โดเมนถูกแมปโดยตรงไปยังที่อยู่ IP ของผู้ให้บริการคลาวด์ที่ผู้โจมตีสามารถครอบครองได้
    บริการคลาวด์มีขอบเขตกว้างและมักขาดการมองเห็นแบบทั่วทั้งระบบ องค์กรที่ใช้คลาวด์จึงมีโอกาสสูงที่จะมีช่องโหว่แบบนี้อยู่ที่ใดที่หนึ่งในซับโดเมน
    โปรแกรม bug bounty มักยกเว้น “การยึดซับโดเมน” แบบเหมารวม แต่เมื่อพบแล้วก็นำไปใช้โจมตีได้ง่าย และยังมีข้อมูลภายใน/สาธารณะที่มีข้อมูลอ่อนไหวรั่วไหลจากการตั้งค่าผิดพลาดแบบนี้ด้วย
    สภาพแวดล้อมการเปิดเผยช่องโหว่ในปัจจุบันทำให้องค์กรหลีกเลี่ยงการยอมรับช่องโหว่จริงได้ง่ายเกินไป และนักวิจัยฝ่ายดีถูกข้อจำกัดด้านจริยธรรมและกฎหมายทำให้ยากที่จะเสนอหลักฐานในระดับที่ผู้ให้บริการต้องการ
    ความเสี่ยงที่ช่องโหว่แบบนี้ทำให้สามารถ ออกใบรับรอง TLS ได้อย่างง่ายดายก็ยังถูกประเมินต่ำเกินไป
    [1] https://dl.acm.org/doi/pdf/10.1145/2976749.2978387
    [2] https://escholarship.org/content/qt9r59r676/qt9r59r676.pdf
    [3] https://pauley.me/post/2022/cloud-squatting/
    [4] https://arxiv.org/pdf/2204.05122

    • ไม่ใช่แค่ IP เท่านั้น แต่ยังมีปัญหาหมวดใหญ่คือ “ระเบียน DNS ที่ชี้ไปยัง ทรัพยากรคลาวด์แบบแชร์ ที่องค์กรไม่ได้ควบคุมอีกต่อไป” และยิ่งบริษัทใหญ่เท่าไรก็ยิ่งแพร่หลายมากขึ้น
      ตัวอย่างเช่น CNAME ที่ชี้ไปยังบัคเก็ต S3 ที่ถูกปล่อยแล้ว, อินสแตนซ์ Azure Website/WebApp, ระเบียน A ที่ชี้ไปยัง IP แบบไม่ยืดหยุ่น, เนมเซิร์ฟเวอร์ Route53 ที่ไม่ได้อยู่ในบัญชี AWS ขององค์กรอีกต่อไป, บัญชี Heroku/Shopify/GitHub Pages ที่ถูกลบหรือปิดใช้งาน, ระเบียน MX ที่ชี้ไปยังโดเมนของผู้ให้บริการอีเมลธุรกรรมที่เจ๊งไปแล้ว เป็นต้น
      สาเหตุคือการกระจายศูนย์ด้าน IT ทำให้คนที่ไม่ค่อยเข้าใจสร้างโครงสร้างพื้นฐานขึ้นมา แล้วลืม DNS ตอนรื้อถอน อีกทั้งมีบริษัทลูก แบรนด์ และองค์กรตามภูมิภาคจำนวนมาก ทำให้ค้นพบนโยบายและบังคับใช้ได้ยาก มีเว็บไซต์/แอปแยกตามประเทศจำนวนมาก และมีการใช้ผู้ให้บริการภายนอกโดยไม่แจ้งทีมความปลอดภัยสะสมมากขึ้นเรื่อย ๆ
      ผมทำงานเป็น Field CTO ที่บริษัทความปลอดภัยไซเบอร์ของอิสราเอลในสาขานี้ เมื่อวานเพิ่งคุยกับบริษัทชิ้นส่วนคอมพิวเตอร์รายใหญ่แห่งหนึ่งเกี่ยวกับเว็บพนันอินโดนีเซียราว 12 เว็บที่ “ดำเนินงาน” โดยใช้โดเมน PageRank และลิงก์ของบริษัทนั้น และบทสนทนาแบบนี้เกิดซ้ำทุกสัปดาห์
    • การที่ bug bounty มอง “การยึดซับโดเมน” ทั้งหมดว่าใช้ไม่ได้ เป็นการตอบสนองที่เหมารวมเกินไป ควรแยกตามว่าครอบครองโดเมนได้ง่ายเพียงใด
      “ถ้ายึด google.com ได้ด้วยวิธีใดก็ตาม ก็ละเมิดผู้ใช้ Google ได้” แบบนั้นไม่ใช่ช่องโหว่ความปลอดภัยที่ใช้ได้ แต่ถ้าการยึด โดเมนที่ยังไม่จดทะเบียนหรือหมดอายุ อย่างกรณีนี้นำไปสู่การละเมิดได้ ก็ควรถูกนับเป็นช่องโหว่ที่ใช้ได้
    • การเปิดเผยผ่าน bug bounty อาจมีประสิทธิภาพมากขึ้นถ้าถูกรายงานอัตโนมัติไปยัง หน่วยงานรัฐ เช่น FCC และสำเนาอีเมลถึงบริษัทนั้นด้วย
      หากบริษัทจะปฏิเสธรายงาน ก็ควรต้องแสดงหลักฐานที่ชัดเจน และถ้าการนำไปใช้โจมตีจากรายงานนั้นพิสูจน์ได้ หรือบริษัทเปลี่ยนแปลงจนขั้นตอนการทำซ้ำในรายงานใช้ไม่ได้อีกต่อไป ก็ควรเข้าข่ายต้องจ่ายรางวัลหรือถูกปรับ
    • เว็บเทรดคริปโตแห่งหนึ่งเคยจัดการรายการอนุญาตของที่อยู่ IP ที่เข้าถึงโหลดบาลานเซอร์ที่เร็วกว่าได้ โดยไม่มีการควบคุมระดับแอปพลิเคชัน
      พวกเขาจัดสรร IP คลาวด์จำนวนมหาศาลแล้ววนหาซ้ำ ๆ เพื่อหา IP เก่า จนได้ความจุมากกว่าเดิมมาก และส่งคำขอด้วย rate limit ที่สูงกว่า
      ตอนนี้คิดว่าน่าจะใช้ไม่ได้แล้ว และตอนนี้ก็เป็นวิธีที่ทุกคนรู้กันแล้ว

  • ส่วนของ Bugcrowd ในเรื่องนี้คาดไม่ถึง
    ภาพหน้าจออีเมลดูเหมือนมาจาก “Platform Behavior Standards Team” ถ้าเป็นอย่างนั้นก็แปลว่า Bugcrowd ตีความมาตรฐานแพลตฟอร์มกว้างเกินไปจนพยายามควบคุมพฤติกรรมนอกแพลตฟอร์ม หรือไม่ก็ Mastercard แอบอ้างเป็นพนักงานทางการของ Bugcrowd
    ไม่ว่าทางไหนก็รับได้ยากทั้งนั้น
    [1] https://www.bugcrowd.com/resources/hacker-resources/platform...

    • มีการตีความว่าแพลตฟอร์ม Bug Bounty มีอยู่เพื่อยึดครองและขัดขวางการเปิดเผยอย่างรับผิดชอบ มากกว่าจะส่งเสริมมัน
      คนที่มักพูดข้ออ้างนี้น่าจะอธิบายให้ชัดได้ดีกว่า
    • ถ้อยคำก็แย่มาก
      เขียนเหมือนถูกตัดสินแล้วว่าทำผิด และตัวเลือกมีแค่ทำตามหรือขอคำอธิบายเพิ่มเติมว่าทำไมถึงผิด
      ไม่มีโอกาสให้อธิบายว่าตัวเองไม่ได้ทำผิด
    • จากประสบการณ์ของผม BugCrowd ทำทุกอย่างเพื่อหน่วงและลากรายงานไม่ให้ไปถึงบริษัทจริง ๆ
      ในมุมบริษัทก็ลดทั้งการจ่าย bounty และต้นทุนการตรวจสอบภายใน แถมยังมี plausible deniability ที่ดูสมเหตุสมผลทางกฎหมายด้วย
    • น่าจะมีพนักงาน Bugcrowd อยู่ที่นี่ด้วย คงช่วยอธิบายอีเมลฉบับนั้นได้

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

    • มีเหตุผลอยู่
      คืออยากทำให้ นักวิจัยความปลอดภัย กลัวที่จะเปิดเผยผลลัพธ์

  • เมื่อหลายปีก่อน ในยูเครน ธุรกรรมออนไลน์ทั้งหมดหรือเกือบทั้งหมดต้องถูกยืนยันผ่านบริการชื่อ masterpass ซึ่งดูเหมือนเป็นอะไรสักอย่างแบบ 3DS ของ Mastercard
    แต่ก็เหมือนที่มักเกิดกับเว็บขององค์กร ใบรับรอง SSL หมดอายุ และธุรกรรมออนไลน์ทั้งหมดหรือเกือบทั้งหมดที่ทำด้วยบัตร MasterCard บางประเภทก็ถูกบล็อกไปโดยสิ้นเชิงในทันที
    Mastercard ไม่ต่ออายุใบรับรองนานกว่าหนึ่งปี ต่อให้ผมในฐานะลูกค้าหรือฝ่าย IT ของธนาคารติดต่อไปเท่าไรก็ไม่เป็นผล และต่อมาก็ปิดบริการไปเงียบ ๆ
    พอลองดูพบว่าบริการเขียนด้วยสาย Microsoft (IIS), เชนใบรับรองยาวผิดปกติพร้อมใบรับรองตัวกลางที่ไม่เคยได้ยินชื่อมาก่อน และถูกโฮสต์อยู่ในประเทศโลกที่สามแห่งหนึ่งที่ค่อนข้างไกลจากยูเครน

    • masterpass คือ 3DS เวอร์ชันของ Mastercard และถูกใช้ทั่วโลกเมื่อธุรกรรมดูน่าสงสัย
      จากมุมมองของ Mastercard ดูเหมือนว่าธุรกรรมในประเทศนั้นถูกมองว่าน่าสงสัยโดยพื้นฐาน แม้ทั้งหมดจะเป็นธุรกรรมระหว่างหน่วยงานท้องถิ่นก็ตาม
      ในสหรัฐฯ ไม่เคยเห็นว่าหมดอายุ และไม่รู้ว่าเขาจัดการทราฟฟิกแยกตามประเทศอย่างไร แต่ฟังดูเหมือนทราฟฟิกถูกเราต์ไปที่อื่นที่ไม่ใช่ Mastercard

  • ชวนไม่สบายใจที่ akam.ne ถูกจดทะเบียนในปี 2016 ให้กับ “Ivan I.” ในมอสโกที่ใช้อีเมล Yandex และเคยชี้ไปยังเซิร์ฟเวอร์ในเยอรมนีช่วงปี 2016–2018 ก่อนจะหมดอายุ
    ที่น่าสงสัยเป็นพิเศษคือโดเมนพิมพ์ผิดที่ดูเหมือนตั้งใจเล็งองค์กรที่พิมพ์เซิร์ฟเวอร์ DNS ของ AWS awsdns-06.net ผิดเป็น awsdns-06.ne ก็ถูกจดด้วยบัญชี Yandex และโฮสต์อยู่กับ Team Internet (AS61969) ซึ่งเป็น ISP เยอรมันรายเดียวกัน

    • “Ivan I” มีความเป็นไปได้สูงว่าหมายถึง Ivan Ivanov ชื่อปลอมแบบรัสเซียที่พบได้ทั่วไป คล้าย “John Smith” ในโลกภาษาอังกฤษ

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

    • ฝ่ายหนึ่งมีแรงจูงใจระดับหลายพันล้านดอลลาร์ให้โกหกหรือพูดเกินจริง ส่วนอีกฝ่ายนั่งคิดถึงสถานการณ์เลวร้ายที่สุดจากผู้โจมตีที่มีความสามารถทั้งวัน
      ถ้าเป็นเซิร์ฟเวอร์ CS:GO การโจมตีเลวร้ายที่สุดจากผู้โจมตีที่มีความสามารถอาจเป็นการพูดเกินจริงได้ แต่เมื่อพูดถึงหนึ่งในบริษัทประมวลผลการชำระเงินรายใหญ่ที่สุดของโลก นั่นไม่ใช่การพูดเกินจริง
    • ถ้ารู้แม้แต่นิดเดียวว่าใบรับรองออกกันอย่างไร ก็จะรู้ว่านักวิจัยพูดถูกและ MasterCard กำลังพูดเหลวไหล
      แค่สืบค้น 10 นาทีก็ได้ข้อสรุปเดียวกัน
    • ถ้าไม่มีผลกระทบ ก็ให้เขาเปิดเผย รายการ DNS query ทั้งหมด ที่เขาจับได้ก็พอ
      เหตุผลที่จะไม่ทำเช่นนั้นคือรายการนั้นจะให้เบาะแสด้านโครงสร้างพื้นฐานแก่ผู้ไม่ประสงค์ดี
      MasterCard กำลังโกหก หรือไม่ก็ไม่รู้เรื่องและไร้ความสามารถ
    • ประเด็นหลักขึ้นอยู่มากว่า az.mastercard.com จริง ๆ แล้วคืออะไรและทำอะไร
      การบอกว่าจะรับอีเมลที่ส่งไปยัง x@mastercard.com ได้นั้นดูไม่ถูกต้อง และนี่เป็นเพียงซับโดเมนที่ไม่รู้วัตถุประสงค์
      TLS น่าจะทำได้ แต่ความเสี่ยงขึ้นกับว่าโดเมนนั้นคืออะไร และดูไม่น่าจะกระทบผู้ใช้ที่เข้า mastercard.com โดยตรง
    • ถ้าพูดถึงใบรับรอง SSL/TLS สิ่งแรกที่นึกถึงคือ ผู้ให้บริการใบรับรองแบบ ACME
      แค่มีสิทธิ์ควบคุม DNS ของโดเมนก็เพียงพอแล้ว และทำได้ด้วยการใช้ TXT record หรือส่งคำขอไปยัง HTTP server ที่ตนควบคุม

  • แน่นอนว่านี่เป็นความผิดพลาดครั้งใหญ่ของ Mastercard แต่การปล่อยให้มีโดเมนที่ต่างจากโดเมนระดับบนสุดเดิมเพียงตัวอักษรเดียวก็ดูเหมือนเป็นความผิดพลาดในตัวมันเอง
    เช่น .com กับ .co, .net กับ .ne ซึ่งเป็นโครงสร้างที่เชื้อเชิญปัญหา
    ถ้าไม่มีโดเมนแบบนั้น ก็จดทะเบียนไม่ได้ และคำขอ DNS ที่พิมพ์ผิดก็จะไม่ไปไหนเลย

    • ไม่จำเป็นต้องเป็นอย่างนั้นเสมอไป
      การพิมพ์ผิดเกิดได้ทุกตำแหน่งของชื่อ ไม่ใช่แค่โดเมนระดับบนสุด และแม้ไม่มีการพิมพ์ผิด ก็ยังใช้ bitsquatting จับโดเมนที่ต่างจากชื่อเว็บยอดนิยมเพียง 1 บิตเพื่อรับทราฟฟิกจากข้อผิดพลาดต่าง ๆ ของคอมพิวเตอร์ได้
      มีงานวิจัยพร้อมตัวอย่างด้วย
      [1] https://en.wikipedia.org/wiki/Bitsquatting
      [2] https://www.securitee.org/files/bitsquatting_www2013.pdf
    • ถ้าเป็นบริษัทใหญ่ ผมคาดว่าจะจัดการเรื่องนี้ด้วย Markmonitor
      โดยพื้นฐานคือจดโดเมนพิมพ์ผิดที่มี edit distance เท่ากับ 1 ไว้ด้วยให้มากที่สุดเท่าที่ทำได้
      ตาม Wikipedia Akamai เป็นหนึ่งในลูกค้าของ Markmonitor ดังนั้นจึงน่าแปลกที่โดเมนนี้ยังไม่ได้ถูกจดไว้แล้ว
    • คำถามคือจะทำอย่างไรกับ รหัส ISO 3166-2 ของ Niger และ Colombia
    • ผมไม่เห็นว่าต่างอะไรจากการมีหมายเลขโทรศัพท์ที่ต่างจากหมายเลขสำคัญเพียงหลักเดียว
    • โดเมนระดับบนสุดแบบ ISO 3166-1 alpha-2 มีประโยชน์แน่นอน แต่ด้วยลักษณะของพื้นที่ที่อยู่ จึงเกิดการพิมพ์ผิดต่างกันหนึ่งตัวอักษรได้มาก
      โดเมนที่ไม่ใช่รหัสประเทศก็อาจซ้อนกับรูปแบบที่เหมือนโดเมนระดับบนสุดรหัสประเทศซึ่งตกตัวอักษรไปหนึ่งตัวได้ จึงไม่ได้ต่างกันมากนัก
      อย่างไรก็ตาม การตั้งค่าผิดแบบนี้ เครื่องมือตรวจสอบ DNS ที่ดีควรจับได้
      เช่น เนมเซิร์ฟเวอร์ที่จดทะเบียนไว้ตัวหนึ่ง resolve ไม่ได้ หรือเนมเซิร์ฟเวอร์แต่ละตัวไม่คืนค่าเลขลำดับโซนเดียวกันหรือคำตอบจริงเดียวกัน
      ใน .is หากต้องการจดโดเมน เคยต้องระบุเนมเซิร์ฟเวอร์ที่ทำงานได้ปกติ 2 ตัว แต่ .com ตอนนี้ไม่ได้เข้มงวดขนาดนั้นแล้ว

  • ชื่อโดเมนนั้นควรถูกส่งมอบให้ akamai
    ยังมีคำขออื่น ๆ มาที่ที่อยู่เดียวกันด้วย และ akamai ควรรับผิดชอบจัดการอย่างเหมาะสม

  • “เราตรวจสอบตัวเองแล้วพบว่าไม่ได้ทำอะไรผิด” เป็นการตอบสนองแบบคลาสสิก
    Mastercard เป็นบริษัทมหาชนมูลค่าหลายพันล้านดอลลาร์ที่มีบัตรแบรนด์ของตนอย่างน้อย 3.4 พันล้านใบทั่วโลก และประมวลผลธุรกรรมเครดิต เดบิต และเงินสดทั่วโลก 44.3 พันล้านรายการในไตรมาส 3 ปี 2024
    การยอมรับความผิดอาจเสียหายในระยะสั้นในตลาด แต่การมีวัฒนธรรมปฏิเสธทำลายวัฒนธรรมองค์กร
    ไม่ต่างจาก ClownStrike และถึงเวลาแล้วที่เครือข่ายเครดิต/เดบิตแบบล่าเหยื่อและเกาะกินจะต้องเจอกับความปั่นป่วน

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

    • การคำนวณของพวกเขาคงเป็นแบบนี้
      ถ้ายอมรับว่ามีปัญหา ราคาหุ้นอาจหายไปหลายล้านดอลลาร์ แต่ถ้าปฏิเสธ ก็แค่มีพวกเนิร์ดบ่นงอแงเพิ่มอีกหน่อยเท่านั้น
      หากไม่มีหลักฐานการถูกเจาะ ก็ยากจะบังคับอะไรได้ และถ้ามีหลักฐานการถูกเจาะ ก็ต้องเข้าคุก
    • ความหมายจริง ๆ น่าจะใกล้เคียงกับ “เราได้คุยกับพนักงานฝ่าย IT ที่ไม่รู้อะไรเลยคนหนึ่ง ซึ่งพนักงานคนนั้นมีแรงจูงใจส่วนตัวที่จะไม่มองหาการเปิดเผยข้อมูล และคิดวิธีนำไปโจมตีไม่ออกภายใน 15 วินาที”
      คนที่รู้เรื่องจริง ๆ แทบจะไม่เคยมั่นใจพอที่จะฟันธงว่าอะไรสักอย่างปลอดภัยจนไม่สามารถถูกนำไปโจมตีได้