2 คะแนน โดย GN⁺ 2024-01-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • นักวิจัยด้านความปลอดภัยกำลังไล่ตรวจไซต์ TLD .ai และ JS bundles เพื่อหา ตัวแปรเริ่มต้นของ Firebase แล้วพบการตั้งค่าที่ Chattr.ai เปิดเผยไว้
  • Chattr.ai เป็นระบบสรรหาบุคลากรด้วย AI ที่โฆษณาว่าช่วย ลดเวลาการจ้างงานได้ 88% และถูกใช้งานโดยบริษัทฟาสต์ฟู้ดและผู้จ้างงานรายชั่วโมงหลายราย เช่น Applebees, Arbys, Chickfila, Dunkin, IHOP, KFC, Subway, Tacobell, Target, Wendys เป็นต้น
  • แม้การเข้าถึงจะถูกบล็อกหากมีเพียงการตั้งค่า Firebase จาก JS bundle แต่เมื่อสร้างผู้ใช้ใหม่ผ่าน ฟังก์ชันลงทะเบียน ของ Firebase สิทธิ์อ่าน/เขียน DB ก็เปิดออก
  • ข้อมูลที่ถูกเปิดเผยมีทั้งชื่อ หมายเลขโทรศัพท์ อีเมล รหัสผ่านแบบข้อความธรรมดา ของบางบัญชี ตำแหน่งสาขา ข้อความลับ และข้อมูลกะการทำงาน โดยส่งผลกระทบต่อพนักงาน Chattr, ผู้จัดการแฟรนไชส์ และผู้สมัครงาน
  • ช่องโหว่ถูกพบเมื่อ 01/06, รายงานเมื่อ 01/09, แพตช์เมื่อ 01/10 และทิกเก็ตซัพพอร์ตถูกปิดเมื่อ 01/11 แต่ไม่มีคำขอบคุณหรือการติดต่อเพิ่มเติมแม้จะร้องขอไว้อย่างชัดเจน

จากการสแกน Firebase สู่ Chattr.ai

  • นักวิจัยเพิ่งรันสคริปต์เพื่อหา ข้อมูลรับรอง Firebase ที่ถูกเปิดเผย ในสตาร์ทอัพ AI หลายร้อยแห่ง
    • ใช้รายชื่อไซต์ TLD .ai ที่เผยแพร่ต่อสาธารณะ
    • แยกวิเคราะห์ข้อมูลไซต์และ .js bundles ที่ถูกอ้างอิง เพื่อค้นหาการอ้างอิงตัวแปรเริ่มต้นของ Firebase
  • เขาต้องการดูว่าระหว่างการเร่งปล่อยผลิตภัณฑ์ อาจมีใครไม่ได้ติดตั้ง กฎความปลอดภัย อย่างเหมาะสมหรือไม่ และในความเป็นจริงก็พบปัญหาที่ร้ายแรงกว่า
  • Chattr.ai เป็นระบบสรรหาบุคลากรด้วย AI ที่โฆษณาว่าช่วย ลดเวลาการจ้างงานใหม่ได้ 88%
    • คำกล่าวอ้างเรื่องการลดเวลาจ้างงาน: {p:88}
  • ตัวอย่างแบรนด์ที่ระบุว่าใช้บริการมีดังนี้
    • Applebees
    • Arbys
    • Chickfila
    • Dunkin
    • IHOP
    • KFC
    • Shoneys
    • Subway
    • Tacobell
    • Target
    • Wendys

วิธีเพิ่มสิทธิ์และข้อมูลที่ถูกเปิดเผย

  • เมื่อนำการตั้งค่า Firebase จาก JS bundle ไปใส่ใน Firepwn ตอนแรกจะเริ่มต้นในสถานะที่ไม่มีสิทธิ์
  • หลังจากนั้น เมื่อสร้างผู้ใช้ใหม่ผ่านฟังก์ชันลงทะเบียนของ Firebase แม้จะสมัครบนไซต์ Chattr.ai ไม่ได้ แต่กลับได้ สิทธิ์อ่าน/เขียนทั้งหมด ใน Firebase DB
  • ข้อมูลที่ถูกเปิดเผยมีดังนี้
    • ชื่อ
    • หมายเลขโทรศัพท์
    • อีเมล
    • รหัสผ่านแบบข้อความธรรมดา ของบางบัญชี
    • ตำแหน่งสาขา
    • ข้อความลับ
    • ข้อมูลกะการทำงาน
  • กลุ่มที่ได้รับผลกระทบคือพนักงาน Chattr, ผู้จัดการแฟรนไชส์ และผู้สมัครงาน

การเปิดเผยและกำหนดการแพตช์

  • 01/06: พบช่องโหว่
  • 01/09: ส่งรายงานที่เขียนขึ้นไปยัง Chattr.ai ทางอีเมล
  • 01/10: แพตช์ช่องโหว่
  • 01/11: ปิดทิกเก็ตซัพพอร์ต โดยไม่มีคำขอบคุณหรือการติดต่อเพิ่มเติมแม้จะร้องขอไว้อย่างชัดเจน

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

 
GN⁺ 2024-01-10
ความคิดเห็นบน Hacker News
  • ไม่ชัดเจนว่าผู้เขียนได้รับมอบหมายให้ทำ penetration test นี้หรือไม่ หรือเป็นบุคคลที่สามสายกองโจรที่มีเจตนาดี
    ถ้าเป็นกรณีหลัง ก็สงสัยว่าเขากล้าขนาดนี้ได้อย่างไร chattr.ai มีนโยบาย responsible disclosure ไหม? ผมคิดว่าหากไม่มีเจตนาก่ออันตรายและรายงานสิ่งที่พบ ใครก็ควรมีอิสระในการทำ penetration test ได้ น่าเสียดายที่หลายบริษัทแม้จะเป็นเจตนาดี ก็ยังตื่นกลัวและไปทางดำเนินคดีทางกฎหมาย

    • จากประโยคที่ว่า “ช่วงหลังผมกำลังมองหา Firebase credentials ที่ถูกเปิดเผยในสตาร์ทอัพ AI หลายร้อยแห่ง” ก็ดูค่อนข้างชัดเจน เขารันสคริปต์สแกนสตาร์ทอัพหลายร้อยแห่ง
      แม้จะเป็นบุคคลที่สามที่มีเจตนาดี บริษัทก็ยังอาจดำเนินคดีทางกฎหมายได้ แต่ในกรณีแบบนั้น บ่อยครั้งบริษัทก็จบลงด้วยการถูกทำให้อับอายต่อสาธารณะพอสมควร
    • เว็บไม่ปลอดภัยพออยู่แล้ว ผมแค่อยากทำส่วนของตัวเองเพื่อทำให้มันปลอดภัยขึ้นอีกนิด
    • เหตุการณ์แบบนี้บางครั้งก็เป็นชนวนให้ หน่วยงานกำกับดูแล เข้ามาตรวจสอบบริษัทละเอียดขึ้น
      https://www.ftc.gov/news-events/news/press-releases/2023/11/...
    • สงสัยว่าคิดแบบเดียวกันกับความปลอดภัยทางกายภาพไหม ถ้ามีคนเดินวนรอบอาคาร มองเข้าไปทางหน้าต่าง สะเดาะกลอนประตู หรือแม้แต่เข้าไปเดินข้างในนิดหน่อย แต่ไม่ได้ขโมยอะไร แบบนั้นถือว่าโอเคหรือเปล่า?
    • ถ้าไม่มีการกำกับดูแลที่เหมาะสม มาตรฐานทางวิศวกรรม และค่าปรับที่จริงจัง สุดท้ายประชาธิปไตยเพียงอย่างเดียวที่มีอยู่ก็คือการที่ผู้คนลงมือทำเอง
      บริษัทที่ถูกแฮ็กก็มีเจตนาร้ายมากพออยู่แล้ว ดังนั้นควรไปโฟกัสทางนั้นมากกว่า
  • ในไทม์ไลน์ไม่มี เวลาที่บทความขึ้นออนไลน์

    • ตาม Wayback Machine ปรากฏครั้งแรกเมื่อวันที่ 10 มกราคม 2024
      http://web.archive.org/web/20240000000000*/https://mrbruh.co...
    • ผมโพสต์ไปเมื่อช่วงเช้าวันนี้ (เวลา NZ) ถ้าพวกเขาติดต่อมา ผมจะแก้ส่วนนั้นเป็นข้อความที่อัปเดตแล้ว :)
  • ตอนนี้ถ้าเข้าไปที่ลิงก์ จะได้ Prometheus metrics กลับมาเต็มไปหมด น่าสนใจดี

    • ตอนนี้คงไม่เป็นแบบนั้นแล้ว เป็นช่วงที่ “กำลัง deploy ไป production”
      ทราฟฟิกเข้าเว็บเยอะเลยต้องวิเคราะห์
  • สงสัยว่านี่เข้าข่าย authorized access ตามที่ CFAA พูดถึงหรือเปล่า
    อยากรู้ว่าขอบเขตอยู่ตรงไหน

  • คิดดูอีกที คนที่ตกอยู่ในความเสี่ยงจริง ๆ น่าจะเป็นคนที่น่าสงสารซึ่งพยายามสมัครงานกับบริษัทแบบนี้ด้วย ค่าแรงรายชั่วโมงน้อยนิด
    ผมไม่ค่อยเข้าใจว่านี่เป็นการ “p0wn” บริษัทเองอย่างไร

  • ถ้าดูหน้านี้ใน Safari มันดูเหมือนเอกสารข้อความธรรมดา

    • รูปภาพใช้ รูปแบบ AVIF เพื่อให้ได้ข้อดีด้านการบีบอัดมากกว่า PNG 2 เท่า ขณะยังรักษาคุณภาพได้สูงกว่า JPG
      ถ้าไม่เห็นรูปภาพ ก็น่าจะใช้เบราว์เซอร์เก่าอยู่ เท่าที่ผมรู้ เบราว์เซอร์เวอร์ชันปัจจุบันทั้งหมดรองรับแล้ว ยกเว้น Internet Explorer และถ้ายังใช้ Internet Explorer อยู่ ก็ขอให้พระเจ้าคุ้มครอง
      [0] https://caniuse.com/avif
    • บน Safari 16.1 ของ mac ไม่ได้แสดงแบบนั้น
    • ในเมื่อเป็นบทความเกี่ยวกับความปลอดภัย นี่คือการเตือนประจำวันนี้ว่า ถ้าอยากปลอดภัยบนอินเทอร์เน็ตก็ควรอัปเดตเบราว์เซอร์
      Safari เวอร์ชันล่าสุดรองรับภาพ AVIF และเมื่อปีที่แล้วก็มีการแก้ ช่องโหว่ remote code execution หลายรายการใน Safari ที่มี exploit จริงถูกเปิดเผยแล้ว