เปิดเผยเหตุการณ์ข้อมูล Secret รั่วไหลบนแพลตฟอร์ม Hugging Face Spaces

 (huggingface.co)
3 คะแนน โดย GN⁺ 2024-06-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อต้นสัปดาห์นี้ มีการตรวจพบการเข้าถึงที่ไม่ได้รับอนุญาตซึ่งเกี่ยวข้องกับ secrets บนแพลตฟอร์ม Spaces และมีความเป็นไปได้ว่า secrets บางส่วนอาจถูกเข้าถึงจากภายนอก
  • ในการตอบสนองเบื้องต้น HF tokens หลายรายการที่อยู่ใน secrets ถูกเพิกถอน และมีการส่งอีเมลแจ้งไปยังผู้ใช้ที่ได้รับผลกระทบ
  • ขอแนะนำให้ผู้ใช้ออก key และ token ที่เกี่ยวข้องใหม่ และเปลี่ยนไปใช้ fine-grained access tokens ซึ่งกลายเป็นค่าเริ่มต้นแล้ว
  • Hugging Face กำลังสืบสวนเหตุการณ์นี้ร่วมกับผู้เชี่ยวชาญด้านนิติวิทยาศาสตร์ความปลอดภัยไซเบอร์ภายนอก และกำลังทบทวนนโยบายและขั้นตอนด้านความปลอดภัยไปพร้อมกัน
  • มีการนำมาตรการต่าง ๆ มาใช้กับโครงสร้างพื้นฐานของ Spaces ได้แก่ การยกเลิก org tokens, การนำ KMS มาใช้, และการเสริมความสามารถในการตรวจจับและทำให้โทเค็นที่รั่วไหลใช้งานไม่ได้ รวมถึงได้รายงานเหตุการณ์นี้ต่อหน่วยงานที่เกี่ยวข้องแล้ว

การเข้าถึง Spaces secrets โดยไม่ได้รับอนุญาตและการดำเนินการของผู้ใช้

  • Hugging Face ตรวจพบการเข้าถึงที่ไม่ได้รับอนุญาตซึ่งเกี่ยวข้องกับ Spaces secrets บนแพลตฟอร์ม Spaces
  • มีความเป็นไปได้ว่า Spaces secrets บางส่วนถูกเข้าถึงโดยไม่ได้รับอนุญาต
  • ระหว่างกระบวนการกู้คืนเบื้องต้น HF tokens หลายรายการที่อยู่ใน secrets ถูกเพิกถอน
    • ผู้ใช้ที่โทเค็นถูกเพิกถอนจะได้รับอีเมลแจ้งแล้ว
  • ขอแนะนำให้ผู้ใช้ออก key หรือ token ใหม่
  • สำหรับ HF tokens ขอแนะนำให้เปลี่ยนไปใช้ fine-grained access tokens ซึ่งเป็นค่าเริ่มต้นใหม่

การเสริมความปลอดภัยให้โครงสร้างพื้นฐานของ Spaces และการตอบสนองต่อเนื่อง

  • Hugging Face กำลังสืบสวนเหตุการณ์นี้ร่วมกับผู้เชี่ยวชาญด้านนิติวิทยาศาสตร์ความปลอดภัยไซเบอร์ภายนอก และกำลังทบทวนนโยบายและขั้นตอนด้านความปลอดภัย
  • ในช่วงไม่กี่วันที่ผ่านมา มีการเสริมความปลอดภัยให้โครงสร้างพื้นฐานของ Spaces
    • ยกเลิก org tokens ทั้งหมดเพื่อเพิ่มความสามารถในการติดตามและการตรวจสอบ
    • นำ บริการจัดการกุญแจ (KMS) มาใช้กับ Spaces secrets
    • เสริมและขยายความสามารถของระบบในการระบุโทเค็นที่รั่วไหลและทำให้ใช้งานไม่ได้ล่วงหน้า
    • ปรับปรุงความปลอดภัยโดยรวม
  • เมื่อ fine-grained access tokens มีความสามารถเทียบเท่ากันครบถ้วนแล้ว มีแผนจะยกเลิก “classic” read/write tokens ทั้งหมดในอนาคตอันใกล้
  • การสืบสวนเกี่ยวกับเหตุการณ์ที่อาจเกี่ยวข้องยังคงดำเนินต่อไป
  • Hugging Face ได้รายงานเหตุการณ์นี้ต่อหน่วยงานบังคับใช้กฎหมายและหน่วยงานคุ้มครองข้อมูลด้วย
  • สามารถติดต่อสอบถามได้ที่ security@huggingface.co

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

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

 
GN⁺ 2024-06-03
ความคิดเห็นจาก Hacker News
  • เมื่อสองวันก่อนผมไล่ดูสไลด์งานประชุมด้านความปลอดภัย แล้วเห็นว่า Jossef Harush Kadouri แสดงให้เห็นว่าถ้าใช้โมเดลจากที่อย่าง Hugging Face ผู้เขียนโมเดลสามารถรันโค้ดตามอำเภอใจบนเครื่องของผมได้
    ไม่แน่ใจว่าสไลด์ถูกอัปโหลดไว้ที่อื่นหรือเปล่า แต่ไฟล์ที่ผมได้รับอยู่ที่นี่: https://dro.pm/c.pdf (45MB) สไลด์หมายเลข 188
    ตอนนั้นผมยังไม่ทันตระหนักว่านั่นหมายความว่า ไม่ใช่แค่ผู้เขียนโมเดลเท่านั้น แต่ถ้า Hugging Face ถูกศาลสั่งหรือถูกแฮ็ก ก็สามารถทำแบบเดียวกันได้เช่นกัน โดยเฉพาะถ้าไม่รู้ตัวอยู่พักหนึ่งว่าถูกเจาะ¹
    ผมไม่ได้อยู่วงการ AI เลยไม่เคยรันโมเดลแบบนี้เอง แต่ก็น่าแปลกใจที่อุตสาหกรรมนี้ทำมาตรฐานรูปแบบกันได้เร็วขนาดนี้ ผมคิดว่าไฟล์โมเดลน่าจะเป็นแค่เมทริกซ์ตัวเลขก้อนใหญ่กับเมทาดาทาเล็กน้อย แต่พอดูสไลด์ 186 และ 195 แล้ว ดูเหมือนว่าโมเดลจริง ๆ แล้วเป็น สคริปต์ Python ที่ทำอะไรก็ได้แทบทั้งหมด เลยเข้าใจได้ว่าทำไมถึงมาตรฐานกันได้ง่าย ถ้าปล่อยให้แต่ละคนทำตามใจ ปัญหาบางอย่างก็เลี่ยงได้ แต่ก็มีต้นทุนตามมา
    ¹ ตาม https://www.verizon.com/business/resources/articles/s/how-to... ระบุว่า 20% ใช้เวลาหลายเดือนกว่าจะรู้ว่าถูกเจาะ แน่นอนว่าก็ขึ้นอยู่กับสถานการณ์และพฤติกรรมของผู้โจมตี
    • สำหรับประโยคที่ว่า “ผมคิดว่าไฟล์โมเดลน่าจะเป็นเมทริกซ์ตัวเลขก้อนใหญ่กับเมทาดาทาเล็กน้อย” นั้น ONNX[1] ก็ใกล้เคียงกับรูปแบบนั้นอยู่มาก
      แต่ปัญหาที่จะเจอทันทีคือ custom layer/operator และตรรกะการทำ inference ของมัน ต้องพยายามทำให้ได้ด้วย operator ที่รองรับเท่านั้น ซึ่งในโลกจริงอาจยากหรือเป็นไปไม่ได้ หรือไม่ก็ต้องส่ง implementation ของ operator มาให้ตอนรันไทม์ ซึ่งสุดท้ายก็วนกลับมาที่จุดเดิม
      [1] https://onnx.ai/
    • ก็เลยมีฟอร์แมต .safetensors ที่ไม่สามารถรันโค้ดบนโฮสต์ได้ไม่ใช่หรือ?
    • อย่างที่คนอื่นชี้ไว้ เรื่องนี้ขึ้นอยู่กับฟอร์แมต ในบรรดาฟอร์แมตที่ยังไม่มีใครพูดถึงในเธรดนี้ในฝั่งที่ปลอดภัยกว่า มี GGUF ที่ llama.cpp และโปรเจกต์ลูกใช้กัน
      มันเกือบจะเป็นฟอร์แมตแบบ “เมทริกซ์ตัวเลขก้อนใหญ่กับเมทาดาทาเล็กน้อย” จริง ๆ และเคยมีการค้นพบช่องโหว่บางอย่างซึ่งถูกแพตช์แล้ว
      [1] https://www.databricks.com/blog/ggml-gguf-file-format-vulner...
    • เท่าที่ผมรู้ ปัญหานี้จะเกิดขึ้นเฉพาะตอนที่โมเดลถูก serialize/deserialize ด้วย pickle เท่านั้น[0]
      [0]: https://huggingface.co/docs/hub/en/security-pickle
    • ลิงก์ dro.pm กำลังจะหมดอายุเร็ว ๆ นี้ มันเป็นลิงก์ชั่วคราวเลยอายุสั้น อาจควรใช้บริการที่ถาวรกว่านี้
      สำหรับคนที่จะมาอ่านทีหลัง ผมหาวิดีโองานบรรยายเจอแล้ว: https://m.youtube.com/watch?v=8XysLIq-e3s
  • การขึ้นต้นด้วยคำว่า “พวกเขาสงสัยว่า” เป็นถ้อยคำที่ เผื่อทางหนีทีไล่ไว้มากเกินไป ดูไม่เหมาะจะใช้ในข้อความสื่อสารประเภทนี้
    • ผมกลับมองว่าค่อนข้างโอเคเลย ปกติประกาศเหตุข้อมูลรั่วแบบนี้มักจะพูดทำนองว่า “ไม่สามารถทราบได้” ว่าแฮ็กเกอร์เข้ามาแล้วทำอะไรไปบ้าง เช่น “ไม่มีหลักฐานว่าเข้าถึง secret ได้”
      อย่างน้อย Hugging Face ก็พูดประมาณว่า “น่าจะ มีโอกาสเข้าถึง secret ได้ แต่ยืนยันไม่ได้” ซึ่งดูตรงไปตรงมากว่า
  • เขาบอกว่า “ในช่วงไม่กี่วันที่ผ่านมา เราได้ปรับปรุงความปลอดภัยของโครงสร้างพื้นฐาน Spaces อย่างมีนัยสำคัญ” พร้อมทั้งเอา organizational token ออกทั้งหมด เพิ่มความสามารถด้าน traceability และ audit, นำ KMS มาใช้กับ secret ของ Spaces, เพิ่มการระบุ token ที่รั่วและการเพิกถอนเชิงรุก รวมถึงปรับปรุงความปลอดภัยโดยรวม แต่ทั้งหมดนี้ดูเป็นงานปริมาณมากเกินกว่าจะทำเสร็จใน “ไม่กี่วัน”
    งานแบบนี้ไม่ควรจะต้องมีขั้นตอนที่ใช้เวลามากกว่า เช่น security audit หรือ penetration test ก่อนนำขึ้นใช้งานจริงหรือ?
    • หวังว่านี่จะเป็นงานที่ทำค้างมาก่อนหน้านี้มาสักพักแล้ว และเพราะความเสียหายเกิดขึ้นไปแล้ว เลยมีเหตุให้ต้องรีบปล่อยตอนนี้
    • นั่นจริงถ้าเป็นองค์กรที่ใหญ่กว่านี้และมีแผนก SRE พร้อมทีมความปลอดภัยโดยเฉพาะ แต่จากภาพที่ผมมี Hugging Face น่าจะยังไม่ได้มีโครงสร้างระดับนั้น
  • คีย์ Anthropic ของผมรั่ว แล้วมีคนเอาไปสร้างค่าใช้จ่ายถึง 10,000 ดอลลาร์ Hugging Face จะชดเชยเรื่องนี้ไหม?
    • คีย์ OpenAI ของผมก็รั่วเหมือนกัน และผมเห็นว่ามีคนเอาไปใช้ โชคดีที่ความเสียหายน้อยกว่ามาก แค่ค่า GPT-4 ไม่กี่ดอลลาร์ และตอนนั้นแอปของผมก็ไม่ได้ใช้โมเดลนั้นด้วยซ้ำ
      ผมค่อนข้างมั่นใจว่าแทบจะแน่นอนว่ามันรั่วผ่าน secret ของ HF Space ผมได้รับข้อความเตือนเมื่อไม่กี่วันก่อนว่า Spaces บางตัวของผมได้รับผลกระทบ
    • แน่ใจหรือว่าคีย์นั้นถูกเก็บไว้เฉพาะใน secret ของ Space จริง ๆ? ตัวแปรนั้นเป็นข้อมูลสาธารณะ และถ้าเก็บไว้ในไฟล์ .env ก็เป็นสาธารณะเช่นกัน
    • ผมนึกว่าแพลตฟอร์มผู้ให้บริการคลาวด์ปกติจะตั้ง วงเงินใช้จ่ายสูงสุด ได้
  • เมื่อไม่กี่สัปดาห์ก่อน ผมสังเกตว่ามี คีย์ OpenAI ของผมบางอันถูกขโมยไป และคีย์เหล่านั้นถูกเปิดใช้งานอยู่แค่ใน secret ของ Hugging Face Space เท่านั้น
    แล้วเมื่อไม่กี่วันก่อนผมก็ได้รับอีเมลว่า Spaces เหล่านั้นถูกเจาะ ดังนั้นปัญหานี้น่าจะดำเนินมาอย่างน้อยหลายสัปดาห์แล้ว
  • ไม่มีการพูดถึงเลยว่าจะจัดการกับค่าใช้จ่ายที่เกิดขึ้นอย่างไม่เหมาะสมอย่างไร ถ้ามีการเข้าถึง secret ได้ ก็น่าจะสามารถเรียก API แล้วสะสมค่าใช้จ่ายได้ไม่ใช่หรือ?
    หรือเรื่องนี้เป็นปัญหาเฉพาะการขโมยข้อมูล/โค้ดเท่านั้น?
    • เป็นได้ทั้งสองแบบ ในกรณีของผม คีย์ถูกนำไปใช้เรียก OpenAI และผมแทบจะแน่ใจว่ารั่วมาจาก secret ของ Spaces
  • ‘Space’ คืออะไร?
    • เป็นชื่อเรียกย่อของ Spaces ของ Hugging Face
      https://huggingface.co/docs/hub/en/spaces-overview
      มันดูเป็นฝั่งฟรอนต์เอนด์/พอร์ทัล และน่าจะเขียนด้วย Python อาจเป็น Django หรืออะไรทำนองนั้น
    • เป็น เครื่องเสมือน ที่รันโค้ดของผู้ใช้
  • ทำไม HF ต้องเก็บ “secret” ด้วย?
    เก็บแค่ public key แล้วให้ผู้ใช้ถือ secret key เองแล้วเซ็นคำขอไม่ได้หรือ?
    • คุณสามารถสร้างแอปที่โฮสต์บน HF และเข้าถึง API ภายนอก อย่าง OpenAI หรือ Anthropic ได้ ในกรณีนั้น API key จะถูกเก็บไว้ใน secret ของ HF
    • โดยทั่วไปถ้าจะให้มันทำงานได้จริงภายใน browser session ก็มักต้องมี token บางรูปแบบอยู่ดี ดูเหมือนว่ากรณีนี้เกี่ยวข้องกับ token ที่ต้องถูกเพิกถอน ซึ่งคล้ายรหัสผ่าน แต่ก็ไม่เหมือนกันเสียทีเดียว