การล็อกอินด้วย Google OAuth ป้องกันไม่ได้หากมีคนซื้อโดเมนของสตาร์ทอัพที่ล้มเหลว

• ช่องโหว่ด้านความปลอดภัยของ Google OAuth ทำให้กระบวนการยืนยันตัวตน "Sign in with Google" มีความเสี่ยงร้ายแรง
  • หลังจากซื้อโดเมนของสตาร์ทอัพที่ล้มเหลว ผู้โจมตีสามารถสร้างบัญชีอีเมลของโดเมนนั้นขึ้นใหม่และล็อกอินเข้าใช้บริการ SaaS ได้
  • สามารถเข้าถึงบริการที่มีข้อมูลอ่อนไหวได้ เช่น:
    • Slack, ChatGPT, Notion, Zoom, ระบบ HR (รวมถึงหมายเลขประกันสังคม)
  • Google ตอบกลับในรายงานแรกว่าเป็น "พฤติกรรมที่ตั้งใจไว้" และปฏิเสธการแก้ไข
• สาเหตุรากของปัญหา: Google OAuth ไม่สามารถตรวจจับการเปลี่ยนเจ้าของโดเมนได้
  • เมื่อโดเมนเปลี่ยนมือ เจ้าของใหม่สามารถล็อกอินเป็นบัญชีพนักงานเดิมได้ด้วย claims เดิม
• ข้อมูล credentials พื้นฐานที่ถูกใช้งาน:
  • hd (hosted domain): มีข้อมูลโดเมน (เช่น example.com)
  • email: มีที่อยู่อีเมลของผู้ใช้ (เช่น [e-mail])
• หากผู้ให้บริการพึ่งพาข้อมูลสองส่วนนี้ เมื่อโดเมนเปลี่ยนเจ้าของก็จะยังอนุญาตให้เข้าถึงบัญชีเดิมได้
• ขนาดของปัญหา
  • ชาวอเมริกัน 6 ล้านคนกำลังทำงานอยู่ในสตาร์ทอัพ
  • 90% ของสตาร์ทอัพล้มเหลว
  • 50% ของสตาร์ทอัพที่ล้มเหลวใช้ Google Workspaces
• มี โดเมนของสตาร์ทอัพที่ล้มเหลวราว 100,000 โดเมน ที่สามารถซื้อได้
• โดยเฉลี่ยแล้วต่อหนึ่งโดเมนมีพนักงาน 10 คนและใช้บริการ SaaS 10 รายการ → อาจมีบัญชีมากกว่า 10 ล้านบัญชีที่มีข้อมูลอ่อนไหว

ข้อเสนอแนวทางแก้ไขและการตอบสนองของ Google

• แนวทางแก้ไขที่เสนอให้ Google:
  1. รหัสผู้ใช้แบบไม่ซ้ำกัน: เพิ่มตัวระบุผู้ใช้เฉพาะที่ไม่เปลี่ยนแปลงตามเวลา
  2. รหัส Workspace แบบไม่ซ้ำกัน: เพิ่มตัวระบุ Workspace เฉพาะที่ผูกกับโดเมน
• การตอบสนองเบื้องต้นของ Google:
  • รายงานในเดือนกันยายน 2024 → ปิดเคสด้วยสถานะ "แก้ไขไม่ได้"
  • หลังนำเสนอที่งานประชุม Shmoocon ในเดือนธันวาคม 2024 Google จึงกลับมาทบทวนปัญหาอีกครั้ง
  • จ่าย bug bounty มูลค่า $1,337 และเริ่มดำเนินการแก้ไข
• ในตอนนี้ หากไม่มีการแก้ไขจาก Google ก็ไม่สามารถแก้ปัญหาที่ต้นเหตุได้
• บางบริการจะส่งคืนรายชื่อผู้ใช้ทั้งหมดเมื่อโดเมนตรงกัน ทำให้ช่องโหว่นี้ยิ่งรุนแรงขึ้น
• ต่อให้ไม่ได้ใช้การล็อกอินด้วย Google แต่ใช้รหัสผ่านแทน ก็ยังสามารถรีเซ็ตได้
  • สตาร์ทอัพบังคับใช้ SSO และ 2FA แทนการยืนยันตัวตนด้วยรหัสผ่าน
  • ผู้ให้บริการควรกำหนดให้การรีเซ็ตรหัสผ่านต้องมีการยืนยันเพิ่มเติม (รหัส SMS, การตรวจสอบบัตรเครดิต)

บทสรุป: ปัญหาเชิงโครงสร้างของความปลอดภัยใน Google OAuth

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

[sixmen]

ผมคิดว่านี่น่าจะเป็นความผิดพลาดฝั่งผู้ใช้มากกว่า ที่ใช้การยืนยันตัวตนด้วยอีเมลที่ผูกกับโดเมน แล้วพอสละโดเมนไปก็ไม่ได้ยกเลิกบริการ SaaS ที่เกี่ยวข้องให้เรียบร้อย แบบนี้ก็ควรนับเป็นช่องโหว่ด้านความปลอดภัยด้วยหรือเปล่าครับ?

[kargnas]

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

พูดแบบสุดโต่ง หากสมมติว่าโดเมนชื่อดังอย่าง gmail.com หรือ hotmail.com ถูกแฮ็ก และสิทธิ์ในการตั้งค่า DNS ของโดเมนตกไปอยู่ในมือแฮ็กเกอร์ ก็เป็นเรื่องแน่นอนมากที่บัญชีของ SaaS ทั้งหมดทั่วโลกจะตกอยู่ในความเสี่ยง

[GN⁺]

ความคิดเห็นจาก Hacker News

• กรณีที่ DankStartup ปิดกิจการแล้วมีคนอื่นเข้าซื้อโดเมนและสามารถเข้าถึงบัญชีเดิมได้ ดูเหมือนจะเป็นประเด็นความรับผิดชอบของ DankStartup, Microsoft และ OpenAI

  • การอธิบายว่านี่เป็นช่องโหว่ของ OAuth จึงไม่เหมาะสม

• ในการใช้งาน OpenID ของ Google วิธีที่ถูกต้องคือยืนยันตัวตนโดยใช้ claim sub

  • ควรมีโฟลว์รองรับกรณีที่ claim sub เปลี่ยนแปลง
  • 'รหัสผู้ใช้เฉพาะที่ไม่เปลี่ยนแปลง' ที่เสนอมาก็ไม่ได้ต่างจาก claim sub

• นี่เป็นปัญหาเชิงพื้นฐานของวิธีที่พึ่งพา DNS ซึ่งเมื่อโดเมนหมดอายุ เจ้าของใหม่ก็อาจได้สิทธิ์ของเจ้าของเดิม

  • เป็นปัญหาที่อาจเกิดขึ้นกับระบบยืนยันตัวตนที่พึ่งพาที่อยู่อีเมลหรือ DNS

• Google OAuth ไม่มีช่องโหว่ และเมื่อเข้าซื้อโดเมนก็เท่ากับได้ครอบครองอีเมลแอดเดรสทั้งหมดของโดเมนนั้น

  • ต่อให้ไม่ใช้ Google OAuth ก็อาจเกิดผลลัพธ์เดียวกันได้

• มีการแชร์ประสบการณ์จากกรณี thehunt.com ในอดีต ที่หลังเข้าซื้อโดเมนแล้วสามารถเข้าถึงทุกบริการได้

  • มีข้อเสนอไอเดียสตาร์ตอัปสำหรับเฝ้าติดตามสถานะโดเมนเพื่อป้องกันภัยคุกคามด้านความปลอดภัย

• เป็นปัญหาของบริการที่ไม่ใช้ฟิลด์ sub โดยควรใช้ฟิลด์ sub สำหรับระบุตัวผู้ใช้

  • สามารถส่งรายงานช่องโหว่ให้บริการที่ไม่ใช้ฟิลด์ sub เพื่อสร้างรายได้ได้

• มีข้อเสนอให้ Google OpenID Connect ใช้ตัวระบุถาวร 2 ตัว

  • claim sub และ Workspace ID เฉพาะที่ผูกกับโดเมน

• กรณีที่ claim sub เปลี่ยนใน Google OAuth นั้นเกิดขึ้นไม่บ่อย และอาจเป็นปัญหาจากการติดตั้งใช้งานของบริการเอง

• มีการแชร์กรณีการเข้าถึงอีเมลหลังเข้าซื้อโดเมน

  • แก้ปัญหาได้ผ่านการเชื่อมต่อภายในกับ Google

• คำกล่าวที่ว่า "บัญชีนับล้าน" ตั้งอยู่บนสมมติฐานว่าสตาร์ตอัปที่ล้มเหลวไม่ได้ปิดการใช้งานบัญชี SAAS