900 เว็บไซต์, 125 ล้านบัญชี, 1 ช่องโหว่

 (env.fail)
3 คะแนน โดย GN⁺ 2024-03-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ความพยายามครั้งแรก

  • สแกนเนอร์พื้นฐานที่เขียนด้วย Python ตรวจสอบตัวแปรคอนฟิก Firebase
  • หยุดทำงานภายในหนึ่งชั่วโมงเนื่องจากปัญหาการใช้หน่วยความจำ

ความพยายามครั้งที่สอง

  • สแกนเนอร์ที่เขียนใหม่ด้วยภาษา Go ไม่มีปัญหา memory leak
  • ใช้เวลานานกว่าที่คาดในการสแกนโดเมนมากกว่า 5 ล้านโดเมน

ตรวจสอบทุกโดเมนด้วยตนเอง

  • ตรวจสอบแต่ละรายการในไฟล์ข้อความ 550,000 บรรทัดด้วยตนเอง
  • ยืนยันได้ 136 เว็บไซต์และ 6.2 ล้านระเบียน แต่ตระหนักว่าจำเป็นต้องมีวิธีอัตโนมัติ

ตัวเร่ง

  • ตรวจสอบรายชื่อเว็บไซต์ที่อาจได้รับผลกระทบด้วยสแกนเนอร์เสริมชื่อ Catalyst
  • ตรวจสอบการเข้าถึงแบบอ่านไปยังคอลเลกชัน Firebase ทั่วไปโดยอัตโนมัติจากเว็บไซต์หรือ .js bundle
  • เก็บตัวอย่างระเบียน 100 รายการเพื่อตรวจสอบประเภทข้อมูลและประเมินผลกระทบของข้อมูล
  • เลือกใช้ Supabase (คู่แข่งโอเพนซอร์สของ Firebase) เพื่อจัดเก็บผลลัพธ์

ตัวเลข

  • ระเบียนทั้งหมด: 124,605,664
  • ชื่อ: 84,221,169
  • อีเมล: 106,260,766
  • หมายเลขโทรศัพท์: 33,559,863
  • รหัสผ่าน: 20,185,831
  • ข้อมูลการชำระเงิน: 27,487,924
  • โปรดทราบว่าตัวเลขเหล่านี้อาจสูงกว่าความเป็นจริง

รายชื่อเว็บไซต์ที่ได้รับผลกระทบ

1. Silid LMS

  • ระบบบริหารจัดการการเรียนรู้สำหรับนักเรียนและครู
  • มีการเปิดเผยระเบียนผู้ใช้มากที่สุด กระทบผู้ใช้ 27 ล้านราย

2. เครือข่ายพนันออนไลน์

  • ประกอบด้วย 9 เว็บไซต์ ซึ่งทั้งหมดมีดีไซน์แตกต่างกัน
  • เกมบางเกมถูกปรับแต่งให้อัตราชนะเป็น 0%
  • เมื่อพยายามรายงานปัญหา ฝ่ายบริการลูกค้ากลับพยายามหว่านล้อม
  • มีการเปิดเผยข้อมูลบัญชีธนาคารมากที่สุด 8 ล้านรายการ
  • มีการเปิดเผยรหัสผ่านแบบ plaintext มากที่สุด 10 ล้านรายการ

3. Lead Carrot

  • เครื่องมือสร้างลีดออนไลน์สำหรับการโทรหาลูกค้าแบบ cold calling
  • เป็นหนึ่งใน 3 เว็บไซต์ที่มีการเปิดเผยข้อมูลผู้ใช้มากที่สุด กระทบ 22 ล้านราย

4. MyChefTool

  • แอปบริหารธุรกิจและแอปพลิเคชัน point of service สำหรับร้านอาหาร
  • มีการเปิดเผยชื่อมากที่สุดและอีเมลมากเป็นอันดับสอง ที่ 14 ล้านและ 13 ล้านตามลำดับ

ผลลัพธ์

  • ส่งอีเมล 842 ฉบับในช่วง 13 วัน
  • อีเมลส่งถึง 85%
  • อีเมลตีกลับ 9%
  • เจ้าของเว็บไซต์ 24% แก้ไขการตั้งค่าที่ผิดพลาด
  • เจ้าของเว็บไซต์ 1% ตอบกลับ
  • เจ้าของเว็บไซต์ 0.2% (2 ราย) มอบ bug bounty

ความเห็นของ GN⁺

  • งานวิจัยนี้แสดงให้เห็นว่าการตั้งค่าความปลอดภัยของ Firebase ผิดพลาดเกิดขึ้นได้ง่ายเพียงใด นี่เป็นกรณีสำคัญที่ช่วยเตือนนักพัฒนาให้ตระหนักเรื่องการตั้งค่าความปลอดภัย
  • เมื่อพบปัญหาด้านความปลอดภัย ปฏิกิริยาของเจ้าของเว็บไซต์มีความหลากหลาย ส่วนใหญ่แก้ไขปัญหา แต่บางรายเพิกเฉยหรือไม่ได้ให้รางวัลที่เหมาะสม
  • เครื่องมืออัตโนมัติที่ใช้ค้นหาช่องโหว่ด้านความปลอดภัยเหล่านี้อาจเป็นประโยชน์ต่อ นักวิจัยด้านความปลอดภัยคนอื่นด้วย เครื่องมือที่มีความสามารถคล้ายกัน ได้แก่ OWASP ZAP และ Burp Suite
  • เมื่อใช้บริการคลาวด์อย่าง Firebase สิ่งสำคัญคือต้องเข้าใจและตั้งค่าความปลอดภัยอย่างถูกต้อง การตั้งค่าที่ผิดพลาดอาจนำไปสู่การรั่วไหลของข้อมูลขนาดใหญ่
  • กรณีนี้ยังช่วยในการพิจารณาบริการอื่นรวมถึง Supabase ซึ่งเป็นทางเลือกโอเพนซอร์ส โดยสามารถใช้เปรียบเทียบฟีเจอร์ด้านความปลอดภัยและความง่ายในการใช้งานได้ Supabase ใช้ PostgreSQL เป็นฐานและมีฟีเจอร์คล้าย Firebase แต่เป็นโอเพนซอร์ส

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

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

 
GN⁺ 2024-03-19
ความเห็นจาก Hacker News
  • ผู้ใช้คนหนึ่งที่เคยทำงานกับ Firebase มาเป็นเวลานานกล่าวว่าปัญหาที่เกี่ยวข้องกับกฎความปลอดภัยเป็นสิ่งที่รบกวนผลิตภัณฑ์นี้มาโดยตลอด มีการลองใช้หลายแนวทางแล้วแต่ก็ยังพบว่าฐานข้อมูลจำนวนมากยังคงมีช่องโหว่ด้านความปลอดภัย สาเหตุเป็นเพราะกฎความปลอดภัยของ Firebase เป็นแนวคิดที่ใหม่และซับซ้อน และนักพัฒนามักมีแนวโน้มที่จะไม่แก้ไขกฎความปลอดภัยเมื่อเพิ่มข้อมูลใหม่ลงในข้อมูลเดิม นอกจากนี้ การไม่มีการทำแบ็กเอนด์แบบกำหนดเองยังทำให้การสแกนในวงกว้างทำได้ง่าย และการเขียนกฎความปลอดภัยของ Realtime Database ก็ทำได้ยากและขยายระบบได้ไม่ดี อย่างไรก็ตาม เนื่องจากการสแกนอัตโนมัติมักค้นหาเฉพาะข้อมูลที่เปิดอยู่ ปัญหานี้จึงไม่ได้เกิดขึ้นบ่อยอย่างที่คิด ตัวแนวทางของ Firebase เองไม่มีปัญหาทางเทคนิค แต่เพราะมันเป็นหนึ่งในแบ็กเอนด์ไม่กี่ตัวที่อาศัยข้อมูลที่จัดเก็บไว้และกฎความปลอดภัย จึงเสี่ยงต่อความเข้าใจผิด การใช้งานที่ไม่เหมาะสม และปัญหาแบบนี้
  • ผู้ใช้อีกคนกล่าวว่าสถานการณ์นี้ทำให้นึกถึงกรณีการแฮ็กเครือร้านฟาสต์ฟู้ดในสหรัฐฯ
  • ผู้ใช้อีกคนชี้ว่า ตามย่อหน้าสุดท้ายของโพสต์นี้ เว็บไซต์ 75% ที่มีช่องโหว่ลักษณะนี้ยังคงรอการถูกปล่อย data dump อยู่ ซึ่งถือว่าบ้าคลั่งมาก และเสริมว่าบางครั้งก็รู้สึกว่าน่าจะต้องมีใบอนุญาตถึงจะใช้คอมพิวเตอร์ได้
  • ผู้ใช้คนหนึ่งชี้ว่านี่คือผลลัพธ์ที่หลีกเลี่ยงไม่ได้ของการเลือกของที่ถูกและเร็ว โดยความกังวลของลูกค้า/ผู้ใช้บางส่วนหายไปจากบทสนทนา และข้อมูลส่วนบุคคลของพวกเขากลายเป็นราคาที่ต้องจ่าย พร้อมเตือนว่าควรระวังบริษัทในรายชื่อนี้ที่ยังไม่มีการเปลี่ยนผู้นำ เพราะมีการพิสูจน์ซ้ำแล้วซ้ำเล่าว่าหลายบริษัทไม่ได้ใส่ใจปกป้องลูกค้ามากพอ
  • ผู้ใช้อีกคนตั้งคำถามพื้นฐานว่า แอปส่วนใหญ่ที่กล่าวถึงในโพสต์นี้ถูกสร้างขึ้นด้วย client-side JavaScript ที่โฮสต์แบบสแตติกทั้งหมดหรือไม่ และแบ็กเอนด์เป็น Firebase configuration ที่ Google โฮสต์ให้ 100% ใช่หรือไม่ ถ้าใช่ ก็แปลว่าเขาไม่เคยตระหนักเลยว่าสถาปัตยกรรมแบบนี้พบได้ทั่วไปแค่ไหนในเว็บไซต์ที่มีผู้ใช้หลายล้านคน
  • ผู้ใช้คนหนึ่งเล่นมุกว่า 900 เว็บไซต์, 125 ล้านบัญชี, 1 ช่องโหว่, แฟน 0 คน
  • ผู้ใช้อีกคนบอกว่าจากสถานการณ์แบบนี้ทำให้รู้สึกขอบคุณที่เลือกใช้ตัวจัดการรหัสผ่านและบัตรเสมือนมาตั้งนานแล้ว พร้อมกล่าวว่าอินเทอร์เน็ตดูน่ากลัวขึ้น เพราะคนส่วนใหญ่ไม่รู้เลยว่าเว็บเปราะบางแค่ไหนและตัวเองเปราะบางเพียงใด
  • ผู้ใช้คนหนึ่งบอกว่าพบว่าโปรแกรม Python ที่มีประมาณ 500 threads ใช้หน่วยความจำมากขึ้นเรื่อย ๆ เมื่อเวลาผ่านไป และถามว่ามีข้อมูลเพิ่มเติมหรือวิธีแก้ปัญหานี้หรือไม่ โดยเสริมว่า Python scraper ของตนเองก็มีหลายร้อย threads และดูเหมือนจะใช้หน่วยความจำมากเช่นกัน
  • ผู้ใช้คนหนึ่งชื่นชมว่าเป็นงานที่ดี และอยากรู้ว่าผู้เขียนสรุปได้อย่างไรว่าจำนวนผู้ใช้ที่ได้รับผลกระทบน่าจะมากกว่านี้ โดยสงสัยว่าเว็บไซต์บางแห่งที่ถูกกล่าวถึง (การพนัน, lead carrot) น่าจะเต็มไปด้วยข้อมูลบัญชีปลอม
  • สุดท้าย ผู้ใช้คนหนึ่งกล่าวขอบคุณโดยบอกว่าฝ่ายสนับสนุนลูกค้าทำให้เขาหัวเราะได้