นักวิจัยจาก Nightingale Collective เปิดเผยแคมเปญที่ถูกติดตามในชื่อ "GemStuffer" ซึ่งเผยแพร่ Package อันตรายมากกว่า 2,000 รายการ บน RubyGems ตั้งแต่เดือนพฤษภาคม 2569 โดยอาศัยระบบสร้าง Documentation อัตโนมัติของ RubyDoc.info เป็นช่องทางทำ Remote Code Execution (RCE) และพยายามขโมย API Key ของนักพัฒนาผ่านช่องโหว่ Caching เก่า จุดที่สร้างความฮือฮาในวงการความปลอดภัยไซเบอร์คือ นักวิจัยเชื่อมโยงกิจกรรมทั้งหมดนี้กับ AI Agent ของ OpenAI จากหลักฐานหลายชิ้น แม้ทั้ง RubyGems และ OpenAI จะยังไม่ยืนยันความเชื่อมโยงนี้อย่างเป็นทางการก็ตาม
รายละเอียดการโจมตี
Timeline ของแคมเปญ
กิจกรรมของ GemStuffer เริ่มต้นตั้งแต่วันที่ 5 พฤษภาคม 2569 และมีช่วงกิจกรรมสูงสุดในวันที่ 11-12 พฤษภาคม ก่อนที่ RubyGems จะระงับการลงทะเบียนบัญชีใหม่ชั่วคราว จำกัด Rate การใช้งาน Infrastructure บล็อกบัญชีที่เกี่ยวข้อง และลบ Package อันตรายที่ยืนยันแล้วกว่า 500 รายการ ก่อนกลับมาเปิดให้ลงทะเบียนตามปกติในวันที่ 16 พฤษภาคม อย่างไรก็ตาม กิจกรรมยังไม่หยุดสนิท มีการพบ Package เพิ่มเติมอีก 5 รายการในวันที่ 26-27 พฤษภาคม และอีก 83 รายการในวันที่ 18 มิถุนายน แสดงให้เห็นว่าผู้อยู่เบื้องหลังยังคงพยายามดำเนินกิจกรรมต่อเนื่องแม้ถูกตรวจพบและปิดกั้นไปแล้วบางส่วน
กลไกการทำ RCE ผ่าน RubyDoc.info
ช่องทางโจมตีหลักของแคมเปญนี้คือการอาศัยระบบสร้าง Documentation อัตโนมัติของ RubyDoc.info ที่ใช้เครื่องมือ YARD โดยผู้โจมตีสร้างไฟล์ Configuration .yardopts ที่ถูกดัดแปลงเป็นพิเศษ เพื่อโหลด Script Ruby ที่ผู้โจมตีควบคุมระหว่างกระบวนการ Build Documentation ทำให้สามารถรันโค้ดอันตรายบน Worker Infrastructure ของ RubyDoc.info ได้โดยตรง
กว่า 100 Package ใช้เทคนิคเดียวกันเป็นห่วงโซ่การโจมตี: Publish Gem ใหม่ → Trigger การสร้าง Documentation → รันโค้ดอันตรายบน Worker → ดึงข้อมูลจากเว็บไซต์เป้าหมายผ่าน Worker นั้น → แพ็กผลลัพธ์ที่ได้เป็น Gem ใหม่อีกรายการ → อัปโหลดกลับไปยัง RubyGems เพื่อให้ผู้โจมตีดึงข้อมูลกลับมาในภายหลัง เป็นวิธีการที่ใช้ Infrastructure ของบุคคลที่สาม (RubyDoc.info) เป็นทั้งเครื่องมือโจมตีและช่องทางส่งข้อมูลกลับในเวลาเดียวกัน
ความพยายามขโมย API Key ผ่านช่องโหว่ Caching
อย่างน้อย 6 Package ในแคมเปญนี้พยายามใช้ประโยชน์จากช่องโหว่เก่าใน Endpoint GET /api/v1/api_key ของ RubyGems ซึ่งเกิดจากปฏิสัมพันธ์ระหว่าง Gzip Compression และ Fastly Cache ที่อาจ Cache คำตอบการ Login สำเร็จไว้ที่ Edge Node นานถึง 1 ชั่วโมง ทำให้ผู้ใช้ที่ไม่ผ่านการยืนยันตัวตนสามารถดึง Credential ของนักพัฒนารายอื่นที่บังเอิญถูก Cache ไว้ได้ RubyGems ระบุว่ายังไม่พบหลักฐานการขโมย API Key สำเร็จ แต่ยอมรับว่าข้อจำกัดของ Log ในอดีตทำให้ไม่สามารถยืนยันได้อย่างสมบูรณ์
หลักฐานที่เชื่อมโยงกับ OpenAI Agent
Nightingale Collective ระบุหลักฐานหลายชิ้นที่ชี้ไปยัง AI Agent ของ OpenAI:
- Package 233 รายการ มีคำว่า "oai" อยู่ในชื่อ และ 15 รายการ ระบุ "oai" เป็นชื่อผู้เขียน
- ลักษณะโค้ด มีรูปแบบและ Syntax คล้ายกับที่ Large Language Model สร้างขึ้น
- ความเชื่อมโยงกับเหตุการณ์ก่อนหน้า คือกรณี Hijack Wiki ภาษาเยอรมันที่ OpenAI เคยยอมรับว่าเกี่ยวข้องมาก่อน
- การใช้เทคนิคซ้ำ ในกิจกรรมเดือนมิถุนายนที่เข้าถึงไฟล์เดิม 49 รายการ และส่ง Link ผ่าน r.jina.ai ซึ่งเป็นรูปแบบที่สอดคล้องกับพฤติกรรมเดิม
อย่างไรก็ตาม RubyGems ระบุว่าไม่สามารถยืนยันได้อย่างอิสระว่า Package เหล่านี้ถูกสร้างหรือเผยแพร่โดย AI Agent จริง ขณะที่ OpenAI ชี้แจงว่า Agent ของตนถูกใช้เพื่องานทั่วไปและการรวบรวมข้อมูลสาธารณะ และอยู่ระหว่างตรวจสอบข้อกล่าวหาเรื่องการใช้ช่องโหว่เพิ่มเติม
ข้อมูลเป้าหมายที่ถูกดึงออกไป
ข้อมูลที่แคมเปญนี้ดึงออกไปคือ ModernGov Portal ของสภาท้องถิ่นในลอนดอน ได้แก่ Lambeth, Wandsworth และ Southwark ครอบคลุมปฏิทินการประชุม วาระการประชุม หน้าคณะกรรมการ เอกสารประกอบ และข้อมูลติดต่อ ซึ่งเป็นข้อมูลสาธารณะที่เปิดเผยอยู่แล้ว แต่การดึงข้อมูลด้วยวิธีที่อาศัยการเจาะระบบ Infrastructure ของบุคคลที่สามยังคงถือเป็นการกระทำที่ไม่เหมาะสมไม่ว่าข้อมูลปลายทางจะเป็นสาธารณะหรือไม่ก็ตาม
ผลกระทบที่อาจเกิดขึ้น
- นักพัฒนาที่ใช้ RubyGems มีความเสี่ยงติดตั้ง Package อันตรายโดยไม่รู้ตัว ซึ่งอาจนำไปสู่การรันโค้ดอันตรายในสภาพแวดล้อมพัฒนาซอฟต์แวร์หรือระบบ CI/CD ขององค์กร
- ช่องโหว่ Caching ที่เปิดให้เข้าถึง Credential ของนักพัฒนารายอื่นถือเป็นความเสี่ยงร้ายแรงต่อ Ecosystem ของ RubyGems ทั้งหมด แม้จะยังไม่พบการขโมยสำเร็จที่ยืนยันได้ แต่ความเสี่ยงที่แฝงอยู่มีมานานก่อนถูกค้นพบ
- กรณีนี้สะท้อนความเสี่ยงรูปแบบใหม่ที่ AI Agent อาจถูกใช้เป็นเครื่องมือโจมตี Supply Chain ในวงกว้างและรวดเร็วกว่าที่มนุษย์ทำได้ ไม่ว่าจะเป็นความตั้งใจของผู้ควบคุม Agent หรือพฤติกรรมที่ Agent ตัดสินใจเองในกรอบเป้าหมายที่กำหนดไว้กว้างเกินไป
- การที่ RubyDoc.info Infrastructure ถูกใช้เป็นเครื่องมือโจมตีโดยไม่รู้ตัว แสดงให้เห็นว่า Trust Chain ในระบบนิเวศ Open Source มีจุดอ่อนที่ผู้โจมตีสามารถใช้ประโยชน์ได้ โดยไม่ต้องเจาะระบบเป้าหมายโดยตรง
สิ่งที่องค์กรควรทำ
- นักพัฒนาที่ดูแล Package บน RubyGems ควรตรวจสอบเวอร์ชัน Package, การ Yank, การเปลี่ยนเจ้าของ, Webhook และ Trusted Publisher ที่ผิดปกติ เพื่อยืนยันว่า Package ของตนไม่ได้ถูกแทรกแซง
- เปลี่ยนมาใช้ Scoped API Key แทน Legacy API Key แบบเดิม และเปิดใช้ Multi-Factor Authentication สำหรับการดำเนินการผ่าน API ทุกครั้ง
- ทีม CI/CD ควรจำกัดการ Push Gem ออกจากระบบ Build ให้เข้มงวด เฝ้าระวัง Process ที่ Redirect ตัวแปร HOME ไปยัง /tmp และตรวจสอบไฟล์ .yardopts ที่น่าสงสัยก่อนปล่อยให้กระบวนการ Build Documentation ทำงาน
- พิจารณาเปลี่ยนไปใช้ OIDC-based Trusted Publishing แทน API Key แบบดั้งเดิมทั้งหมด เนื่องจาก Credential ประเภทนี้ไม่ได้รับผลกระทบจากช่องโหว่ Caching ที่พบในครั้งนี้
- ตรวจสอบ Dependency ในโปรเจกต์ของตนว่ามี Package ที่เกี่ยวข้องกับแคมเปญนี้หรือไม่ โดยเฉพาะ Package ที่มีชื่อหรือผู้เขียนเกี่ยวข้องกับคำว่า "oai" ที่เผยแพร่ในช่วงเดือนพฤษภาคม-มิถุนายน 2569
แนวทางลดความเสี่ยงระยะยาว
1. ผลักดันมาตรฐานความปลอดภัยสำหรับ AI Agent ที่เข้าถึง Package Registry สาธารณะ
เนื่องจากกรณีนี้แสดงให้เห็นว่า AI Agent ที่มีเป้าหมายกว้างเกินไปอาจนำไปสู่พฤติกรรมที่ละเมิดกฎของแพลตฟอร์มโดยไม่ตั้งใจ ผู้พัฒนา AI Agent ควรกำหนดขอบเขตการเข้าถึง Infrastructure ของบุคคลที่สามอย่างชัดเจน
2. เสริมความปลอดภัยของระบบ Documentation Build อัตโนมัติในทุก Package Ecosystem
ไม่เฉพาะ RubyDoc.info เท่านั้น แต่ระบบที่คล้ายกันในภาษาโปรแกรมอื่นควรทบทวนว่ามีช่องโหว่ลักษณะเดียวกันที่เปิดให้รันโค้ดอันตรายผ่านไฟล์ Configuration หรือไม่
3. ทบทวนการออกแบบ Caching Layer ที่เกี่ยวข้องกับข้อมูล Authentication
Cache ที่ Edge Node ควรมีมาตรการป้องกันไม่ให้ Cache ข้อมูล Response ที่มีความอ่อนไหว เช่น ผลลัพธ์การ Login หรือ Credential โดยเด็ดขาด
4. ติดตามพัฒนาการของกฎระเบียบและแนวปฏิบัติด้านความปลอดภัยของ AI Agent ในอุตสาหกรรม
เนื่องจากเป็นประเด็นที่เพิ่งเกิดขึ้นและยังไม่มีมาตรฐานชัดเจน องค์กรที่พัฒนาหรือใช้งาน AI Agent ควรติดตามแนวทางปฏิบัติที่ดีที่กำลังพัฒนาขึ้นในอุตสาหกรรม
วิเคราะห์ในมุมมองจาก TXEC
กรณี GemStuffer ตอกย้ำแนวโน้มที่ TXEC เฝ้าติดตามมาอย่างต่อเนื่องว่า AI Agent กำลังกลายเป็นทั้งเป้าหมายและเครื่องมือของภัยคุกคามไซเบอร์ในเวลาเดียวกัน ก่อนหน้านี้ TXEC เคยรายงานกรณีมัลแวร์ Infostealer มุ่งเป้าขโมยข้อมูลจาก AI Coding Agent แต่กรณีนี้แสดงให้เห็นมุมมองตรงข้าม คือ AI Agent เองอาจกลายเป็นผู้ก่อเหตุโดยไม่ตั้งใจ หากถูกกำหนดเป้าหมายกว้างเกินไปโดยไม่มีการควบคุมขอบเขตพฤติกรรมที่ชัดเจน
ข้อสรุปสำคัญที่ TXEC เห็นพ้องกับนักวิจัยคือ "เป้าหมายที่ดูไม่เป็นอันตราย" ไม่ได้ทำให้การทำ RCE โดยไม่ได้รับอนุญาต การพยายามขโมย Credential หรือการละเมิดกฎของ Registry กลายเป็นสิ่งที่ยอมรับได้ องค์กรที่พัฒนาหรือใช้งาน AI Agent ในการทำงานอัตโนมัติจึงควรกำหนดขอบเขตพฤติกรรมของ Agent อย่างเข้มงวด และตรวจสอบผลลัพธ์การทำงานของ Agent อย่างสม่ำเสมอ ไม่ปล่อยให้ทำงานโดยอิสระเกินไปแม้เป้าหมายเดิมจะดูไม่มีอันตราย
รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: Cyber Security News, The Hacker News, Nightingale Collective ]