สรุปสั้น

Gitee คือ แพลตฟอร์มฝากโค้ดที่ใหญ่ที่สุดของจีน และถูกกระทรวงอุตสาหกรรมและเทคโนโลยีสารสนเทศของจีนเลือกเป็นฐานของแพลตฟอร์มโค้ดโอเพนซอร์สระดับชาติตั้งแต่ปี 2563 นาย Ben Zimmermann นักวิจัยอิสระที่ทำงานร่วมกับทีม Kingfisher ของบริษัท MongoDB รายงานเมื่อ 28 ตุลาคม 2569 ว่าสแกน repo สาธารณะบน Gitee 7.25 ล้าน repo แล้วพบคีย์และรหัสยืนยันตัวตน (credential) ที่ยังใช้งานได้จริงตอนทดสอบ 26,400 ชุด ส่วนใหญ่เป็นคีย์บริการคลาวด์และ AI นำโดยคีย์ Alibaba Cloud 9,473 คู่ ใครก็ตามที่คัดลอกคีย์จากโค้ดเหล่านี้ไปก็ใช้ได้ทันที

ประเด็นที่ทำให้เรื่องนี้น่ากังวล คือ เครื่องมือไล่อ่านประวัติ commit ทั้งหมด คีย์ที่นักพัฒนาลบออกจากโค้ดไปแล้วจึงยังถูกพบ และนาย Zimmermann แจ้งผู้ให้บริการที่มีคีย์รั่วมากที่สุด แต่ไม่ได้แจ้งนักพัฒนาเจ้าของคีย์ ตอนเผยแพร่เขายังยืนยันไม่ได้ว่ามีคีย์ใดถูกเพิกถอนแล้ว ใครเคย push คีย์ขึ้น repo สาธารณะบน Gitee จึงควรถือว่าคีย์รั่วแล้วและเพิกถอนที่ผู้ให้บริการทันที การลบออกจากโค้ดไม่พอ

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 29 ตุลาคม 2569 ว่า นาย Zimmermann ใช้เครื่องมือสแกนความลับ 2 ตัว คือ TruffleHog และ Kingfisher กับทุก repo โดยทั้งสองตัวลองใช้คีย์แต่ละชุดกับบริการที่ออกคีย์นั้นจริง และเก็บเฉพาะคีย์ที่ใช้ได้ ตัวเลข 26,400 นับคีย์แต่ละชุดครั้งเดียวแม้จะปรากฏหลาย repo เมื่อแยกตามวันที่ commit พบว่า 12,242 ชุดหรือเกือบครึ่งมาจากปี 2568 และบางชุดเก่าถึงปลายทศวรรษ 2000 หลังคีย์ Alibaba Cloud กลุ่มใหญ่ถัดมา คือ คีย์ YouTube API 3,805 ชุด DeepSeek 3,170 ชุด Zhipu BigModel 1,489 ชุด และ OpenAI 1,348 ชุด ส่วนที่เหลือเป็นคีย์ GitHub, AWS, Google Cloud และ Gemini ในจำนวนน้อยกว่า หนึ่งในนั้นเป็น “credential ผู้ดูแลระดับองค์กรที่ยังใช้งานได้ของแพลตฟอร์ม AI ระดับองค์กรรายใหญ่” แต่เขาไม่ระบุชื่อแพลตฟอร์มหรือขอบเขตสิทธิ์

ผลของเครื่องมือสองตัวต่างกันมาก TruffleHog พบคีย์ที่ใช้ได้ 12,737 ชุด Kingfisher พบ 14,664 ชุด แต่พบตรงกันเพียง 1,001 ชุด แต่ละตัวจึงเจอราวครึ่งเดียวของทั้งหมด TruffleHog เจอคีย์ Alibaba Cloud เกือบทั้งหมด ขณะที่ Kingfisher เจอคีย์ BigModel ทั้ง 1,489 ชุดเพราะ TruffleHog ไม่มีตัวตรวจคีย์ของ Zhipu ด้านอัตราการรั่ว Gitee มีคีย์ที่ใช้ได้ 3.64 ชุดต่อ 1,000 repo สูงกว่าผลสแกน GitLab (3.11) และ Bitbucket (2.39) ก่อนหน้า แต่ผลเก่าใช้แค่ TruffleHog ถ้านับเฉพาะ TruffleHog อัตราของ Gitee จะเหลือ 1.76 ตัวเลขชุดนี้จึงบอกไม่ได้ว่าแพลตฟอร์มไหนรั่วมากกว่ากัน

Valid cloud and AI API keys found exposed in public Gitee code repositories

ข้อจำกัดของหลักฐาน คือ การสแกนใช้เวลาราวหนึ่งเดือนแต่ไม่ระบุช่วงวันที่ จึงไม่ชัดว่าคีย์ถูกทดสอบเมื่อนานแค่ไหน นาย Zimmermann ไม่ได้บอกว่ามีคนอื่นนำคีย์ไปใช้แล้วหรือไม่ และยังไม่ยืนยันว่าผู้ให้บริการเพิกถอนคีย์ที่แจ้งไปแล้ว นอกจากนี้ API สาธารณะของ Gitee มีข้อจำกัด ความพยายามศึกษาคีย์รั่วบน Gitee เมื่อปี 2564 ก็เคยล้มเลิกไปเพราะเหตุนี้

วิธีการโจมตี

คีย์ยังอยู่ในประวัติ แม้ลบจากโค้ดแล้ว — Git เก็บทุกเวอร์ชันของไฟล์ไว้ใน commit history การลบคีย์ใน commit ใหม่จึงไม่ทำให้คีย์หายไป ใครโคลน repo ก็ย้อนอ่านได้ เครื่องมืออย่าง TruffleHog และ Kingfisher ไล่อ่านประวัติทั้งหมดอัตโนมัติ ผู้โจมตีจึงใช้วิธีเดียวกันเก็บคีย์ได้ในวงกว้าง บริษัท Truffle Security ผู้พัฒนา TruffleHog ย้ำว่าแม้เขียนประวัติ repo ใหม่ก็ไม่ได้เพิกถอนคีย์

คีย์ที่ได้ไปทำอะไรได้บ้าง — ขึ้นกับบริการ OpenAI ระบุว่าคีย์ที่รั่วทำให้คนอื่นใช้โควตาของบัญชีได้โดยเจ้าของไม่ยินยอม ซึ่งอาจทำให้ข้อมูลสูญหาย เกิดค่าใช้จ่ายไม่คาดคิด โควตาหมด และ API ใช้งานไม่ได้ ส่วนคีย์ YouTube API เป็นคีย์ Google Cloud ที่ระบุโปรเจกต์ ถ้าไม่ได้จำกัด API ไว้ คีย์นี้ใช้กับทุก API ที่รับคีย์ Google Cloud ได้ สำหรับคีย์ Alibaba Cloud แบบ AccessKey ผู้ถือคีย์สร้างหรือลบทรัพยากรคลาวด์ได้ตามสิทธิ์ของบัญชี

เครื่องมือเดียวไม่พอ — การที่สองเครื่องมือเจอตรงกันแค่ 1,001 ชุด ชี้ว่าแต่ละตัวมีตัวตรวจ (detector) ครอบคลุมบริการต่างกัน ทีมที่พึ่งเครื่องมือตัวเดียวจึงอาจพลาดคีย์ของบริการที่เครื่องมือไม่รู้จัก โดยเฉพาะบริการ AI ของจีน

ผลกระทบ

กลุ่มที่โดนโดยตรง คือ นักพัฒนาและบริษัทที่เคย push โค้ดขึ้น repo สาธารณะบน Gitee ซึ่งส่วนใหญ่อยู่ในจีน แต่รวมถึงบริษัทต่างชาติที่มีทีมพัฒนาหรือผู้รับจ้างในจีนด้วย ขนาดของปัญหา คือ คีย์ที่ใช้ได้จริง 26,400 ชุด เกือบครึ่งมาจากปีที่แล้ว ความเสี่ยงหลักมี 2 เรื่อง เรื่องแรก คือ ค่าใช้จ่าย เมื่อคนอื่นใช้โควตา AI หรือสร้างทรัพยากรคลาวด์ด้วยบัญชีของเหยื่อ เรื่องที่สอง คือ การเข้าถึงข้อมูลและระบบ โดยเฉพาะคีย์ระดับผู้ดูแลองค์กรที่พบอย่างน้อย 1 ชุด

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

คำแนะนำ

  • เพิกถอนคีย์ทันที ไม่ใช่แค่ลบ — คีย์ใดที่เคยอยู่ใน repo สาธารณะบน Gitee ให้ถือว่ารั่วแล้ว และเพิกถอนที่ผู้ให้บริการ เพราะการลบจากโค้ดหรือเขียนประวัติใหม่ไม่ได้เพิกถอนคีย์
  • Alibaba Cloud — สร้าง AccessKey คู่ใหม่ เปลี่ยนแอปให้ใช้คู่ใหม่ แล้วปิดและลบคู่เก่า ตามแผนรับมือคีย์รั่วของ Alibaba Cloud
  • Google และ YouTube API — หมุนคีย์ (rotate) ซึ่งจะสร้างคีย์ใหม่ที่มีข้อจำกัดเดิม อัปเดตแอป แล้วลบคีย์เก่า และเพิ่มข้อจำกัดให้คีย์ใช้ได้เฉพาะ API ที่จำเป็น
  • OpenAI — หมุนคีย์จากหน้า API Keys ทันที และตั้งขีดจำกัดการใช้จ่ายเพื่อจำกัดความเสียหายจากคีย์ที่รั่ว
  • ตรวจว่าถูกใช้ไปแล้วหรือยัง — สำหรับ Alibaba Cloud ดูการเรียก API ของคีย์ใน ActionTrail ย้อนหลัง 90 วัน และตรวจล็อกของบริการข้อมูล เช่น OSS และ SLS แยก รวมถึงไล่ดูค่าใช้จ่ายและทรัพยากรที่ไม่ได้สร้างเอง
  • สแกนด้วยมากกว่าหนึ่งเครื่องมือ — ใช้ทั้ง TruffleHog และ Kingfisher หรือเครื่องมืออื่น และตรวจว่าตัวตรวจครอบคลุมบริการที่องค์กรใช้จริง โดยเฉพาะผู้ให้บริการ AI รายใหม่
  • กันคีย์ไม่ให้เข้าโค้ดตั้งแต่ต้น — ติดตั้ง pre-commit hook สแกนความลับ และย้ายคีย์ไปเก็บใน secret manager แทนไฟล์คอนฟิก

แหล่งอ้างอิง