Google ยืนยันว่าโมเดล Gemini สามารถเข้าถึงระบบจริงของบริษัท 3 แห่งโดยไม่ได้ตั้งใจ ระหว่างการประเมินความสามารถด้าน Offensive Cybersecurity ที่ดำเนินการโดย Irregular บริษัทด้าน AI Security Testing ในรูปแบบ Capture the Flag (CTF) ภายในสภาพแวดล้อมจำลอง เหตุการณ์เกิดขึ้นในเดือนพฤษภาคม 2569 และ Irregular แจ้งให้ Google ทราบในช่วงปลายเดือนกรกฎาคม 2569 ก่อนที่รายละเอียดจะถูกเปิดเผยต่อสาธารณะผ่านรายงานของ Wall Street Journal เมื่อวันที่ 19 กันยายน 2569 นับเป็นกรณีแรกที่มีการยืนยันว่าโมเดล AI ของ Google ดำเนินการ Hacking ระบบจริงแบบอัตโนมัติ
รายละเอียดการโจมตี
จุดเริ่มต้นของปัญหา: Scope และ Network Isolation ที่ไม่รัดกุม
ต้นเหตุของเหตุการณ์นี้เกิดจากความผิดพลาด 2 ประการที่เกิดขึ้นพร้อมกัน ประการแรกคือชื่อบริษัทสมมติที่ใช้ในแบบทดสอบ CTF บังเอิญตรงกับชื่อองค์กรจริงที่มีอยู่ ประการที่สองคือการเชื่อมต่ออินเทอร์เน็ตที่ควรถูกปิดใช้งานในสภาพแวดล้อมทดสอบกลับถูกเปิดใช้งานโดยไม่ได้ตั้งใจ (Accidentally Enabled) เมื่อทั้งสองปัจจัยเกิดขึ้นพร้อมกัน ทำให้ Gemini เข้าใจผิดว่า Assets ที่ค้นพบจากอินเทอร์เน็ตจริงเป็นส่วนหนึ่งของเป้าหมายที่ได้รับอนุญาตให้โจมตีภายใต้ขอบเขตการทดสอบ
3 เหตุการณ์ที่ Gemini เข้าถึงระบบจริง
เหตุการณ์แรก Gemini ใช้วิธี Password Guessing ทดลองรหัสผ่านซ้ำๆ จนสามารถเข้าสู่ Protected Service ของบริษัทแรกได้สำเร็จ เหตุการณ์ที่สองและสาม Gemini ใช้วิธีค้นหา Credentials ที่เปิดเผยอยู่ใน Public Code Repositories และนำ Credentials เหล่านั้นไปใช้ Authenticate เข้าสู่ระบบจริงของอีก 2 บริษัทในการทดสอบคนละรอบกัน โดย Google ยืนยันว่าในทั้ง 3 กรณี Gemini หยุดการกระทำทันทีหลังจากรับรู้ว่ากำลังเข้าถึงโครงสร้างพื้นฐานจริง ไม่ใช่เป้าหมายสมมติตามที่ออกแบบไว้ในแบบทดสอบ
จุดยืนของ Google ต่อเหตุการณ์นี้
Heather Adkins รองประธานฝ่าย Security Engineering ของ Google อธิบายว่า Gemini "ใช้ข้อมูลที่เปิดเผยต่อสาธารณะและเดารหัสผ่านเพื่อเข้าถึงเว็บไซต์ที่เชื่อว่าอยู่ในขอบเขตของการประเมิน" และย้ำว่าไม่มีความเสียหายเกิดขึ้นกับทั้ง 3 องค์กร พร้อมทั้งปฏิเสธว่าเหตุการณ์นี้ไม่ใช่กรณี Model Misalignment โดยให้เหตุผลว่าการที่โมเดลหยุดกระทำเองเมื่อรับรู้ว่ากำลังเข้าถึงเป้าหมายจริง สะท้อนว่า Safeguard ของโมเดลทำงานได้ตามที่ออกแบบไว้ Google ระบุว่าได้แจ้งให้ทั้ง 3 องค์กรรับทราบแล้ว และทำงานร่วมกับ Irregular ในการปรับปรุงกระบวนการทดสอบ
เหตุการณ์ในวงกว้างกว่า: กระทบโมเดลจากผู้พัฒนารายอื่นด้วย
รายงานระบุว่าเหตุการณ์ลักษณะเดียวกันไม่ได้จำกัดอยู่แค่ Gemini เท่านั้น แต่ยังกระทบโมเดลจาก OpenAI, Anthropic และ Meta ในการประเมินของ Irregular เช่นกัน โดยผลลัพธ์แตกต่างกันไปในแต่ละกรณี สะท้อนว่าปัญหานี้เป็นความท้าทายเชิงระบบ (Systemic Challenge) ของอุตสาหกรรม AI Red Teaming โดยรวม ไม่ใช่ปัญหาเฉพาะของผู้พัฒนารายใดรายหนึ่ง
ผลกระทบที่อาจเกิดขึ้น
1. "Prompt ไม่ใช่ขอบเขตความปลอดภัย" (Prompts Are Not Security Boundaries)
เหตุการณ์นี้ตอกย้ำหลักการสำคัญว่าการควบคุม AI Agent ด้วย Prompt หรือคำสั่งเพียงอย่างเดียวไม่เพียงพอที่จะป้องกันไม่ให้โมเดลกระทำการนอกขอบเขตที่ตั้งใจไว้ หากสภาพแวดล้อมทางเทคนิคอย่าง Network Isolation ไม่ได้ถูกบังคับใช้อย่างเข้มงวดควบคู่กันไปด้วย
2. ความเสี่ยงจาก AI Agent ที่มีความสามารถ Offensive Security สูงขึ้นเรื่อยๆ
การที่โมเดล AI สามารถทดลองรหัสผ่านและค้นหา Credentials ที่รั่วไหลได้อย่างมีประสิทธิภาพ สะท้อนว่าความสามารถด้าน Offensive Cybersecurity ของ AI Agent กำลังพัฒนาอย่างรวดเร็ว ซึ่งอาจถูกนำไปใช้ในทางที่ไม่หวังดีได้เช่นกันหากขาดการควบคุมที่รัดกุม
3. ความเสี่ยงจากการตั้งชื่อองค์กรสมมติที่ชนกับชื่อจริงในการทดสอบ
เหตุการณ์นี้แสดงให้เห็นว่าความผิดพลาดเล็กน้อยอย่างการตั้งชื่อ Fictional Target ที่บังเอิญตรงกับชื่อองค์กรจริง สามารถนำไปสู่ผลกระทบที่ไม่คาดคิดได้ หากไม่มีการควบคุมทางเทคนิคอื่นมาป้องกันซ้ำอีกชั้นหนึ่ง
4. ผลกระทบต่อความน่าเชื่อถือของกระบวนการ AI Safety Evaluation ในวงกว้าง
เนื่องจากเหตุการณ์ลักษณะเดียวกันเกิดขึ้นกับโมเดลจากผู้พัฒนาหลายรายในการประเมินของ Irregular องค์กรและหน่วยงานกำกับดูแลอาจตั้งคำถามต่อความรัดกุมของกระบวนการทดสอบความปลอดภัย AI ในภาพรวม และเรียกร้องให้มีมาตรฐานการควบคุมที่เข้มงวดขึ้น
สิ่งที่องค์กรควรทำ
1. ทบทวนว่าองค์กรมีความเสี่ยงจากการทดสอบ AI Red Teaming ของผู้อื่นหรือไม่
องค์กรควรตรวจสอบว่ามีการใช้ชื่อองค์กร โดเมน หรือ Asset ที่อาจถูกนำไปใช้เป็น Fictional Target ในการทดสอบ AI Security ของบุคคลภายนอกหรือไม่ และพิจารณาแจ้งเตือนหน่วยงานที่เกี่ยวข้องหากพบสัญญาณผิดปกติที่อาจเชื่อมโยงกับการทดสอบลักษณะนี้
2. เสริมมาตรการ Egress Filtering และการจำกัด Credential Exposure
องค์กรควรตรวจสอบว่ามี Credentials หลุดอยู่ใน Public Code Repositories หรือไม่ เนื่องจากเป็นวิธีที่ Gemini ใช้เข้าถึงระบบจริงถึง 2 ใน 3 เหตุการณ์ ควรมีกระบวนการสแกน Repository อย่างสม่ำเสมอเพื่อค้นหาและเพิกถอน Token หรือ Credentials ที่รั่วไหล
3. ใช้ Multi-Factor Authentication และจำกัดอัตราการ Login ที่ผิดพลาด
เนื่องจากเหตุการณ์หนึ่งเกิดจากการเดารหัสผ่านซ้ำๆ จนสำเร็จ องค์กรควรบังคับใช้ Multi-Factor Authentication กับระบบสำคัญทุกระบบ และตั้งค่า Rate Limiting เพื่อจำกัดจำนวนครั้งของการพยายาม Login ที่ผิดพลาดในช่วงเวลาสั้นๆ
4. หากองค์กรทำหน้าที่เป็นผู้ทดสอบหรือใช้งาน AI Agent ด้าน Security ควรแยก Isolated Test Network อย่างเคร่งครัด
องค์กรที่พัฒนาหรือใช้งาน AI Agent สำหรับงานด้าน Security Testing ควรจัดทำ Isolated Test Network ที่แยกขาดจากอินเทอร์เน็ตจริงอย่างสมบูรณ์ ใช้ชื่อองค์กรสมมติที่ไม่มีโอกาสชนกับชื่อจริง และมีกลไก Real-Time Intervention พร้อม Automatic Shutdown หากตรวจพบพฤติกรรมผิดปกติ
แนวทางลดความเสี่ยงระยะยาว
1. สร้างมาตรฐานการควบคุมสภาพแวดล้อมทดสอบ AI Agent ที่เข้มงวดกว่าเดิม
องค์กรและอุตสาหกรรมควรร่วมกันพัฒนามาตรฐานสำหรับ Isolated Test Environment ของ AI Agent ที่มีความสามารถ Offensive Security รวมถึงการบังคับใช้ Egress Filtering, Allowlisting และ Immutable Audit Logging เพื่อป้องกันเหตุการณ์ลักษณะเดียวกันในอนาคต
2. เพิ่มความเข้มงวดของกระบวนการตรวจสอบ Scope ก่อนเริ่มการทดสอบทุกครั้ง
กระบวนการ Red Teaming หรือ Penetration Testing ที่ใช้ AI Agent ควรมีขั้นตอนตรวจสอบซ้ำก่อนเริ่มการทดสอบทุกครั้งว่า Scope ที่กำหนดไว้ไม่มีความเสี่ยงชนกับ Asset จริง และ Network Isolation ทำงานได้ตามที่ออกแบบไว้จริง ไม่ใช่เพียงอาศัยความเชื่อว่า Configuration ถูกต้อง
3. ติดตามพัฒนาการความสามารถ Offensive Security ของโมเดล AI อย่างใกล้ชิด
องค์กรด้าน Cybersecurity ควรติดตามพัฒนาการของความสามารถ AI Agent ในด้าน Offensive Security อย่างต่อเนื่อง เนื่องจากความสามารถที่เพิ่มขึ้นอย่างรวดเร็วอาจถูกนำไปใช้ทั้งในทางบวกสำหรับงาน Red Teaming ที่ถูกต้องตามกฎหมาย และในทางลบหากตกไปอยู่ในมือผู้ไม่หวังดี
4. เตรียมกระบวนการรับมือกรณีองค์กรตกเป็นเป้าหมายโดยไม่ได้ตั้งใจจากการทดสอบ AI ของผู้อื่น
องค์กรควรมีช่องทางและกระบวนการรับมือหากตรวจพบว่าตนเองตกเป็นเป้าหมายจากการทดสอบ AI Security ของบุคคลภายนอกโดยไม่ได้ตั้งใจ รวมถึงการประสานงานกับผู้พัฒนา AI ที่เกี่ยวข้องเพื่อยืนยันขอบเขตความเสียหายและมาตรการป้องกันในอนาคต
วิเคราะห์ในมุมมองจาก TXEC
เหตุการณ์นี้เป็นสัญญาณสำคัญที่แสดงให้เห็นว่าความสามารถของ AI Agent ในการดำเนินการด้าน Offensive Cybersecurity แบบอัตโนมัติได้พัฒนาไปถึงจุดที่สามารถเดารหัสผ่านและค้นหา Credentials ที่รั่วไหลได้อย่างมีประสิทธิภาพเทียบเท่าผู้โจมตีที่มีทักษะ สิ่งที่ TXEC เห็นว่าน่าสนใจเป็นพิเศษคือแม้ Google จะยืนยันว่า Safeguard ของโมเดลทำงานได้ดีในการหยุดกระทำเองเมื่อรับรู้ว่ากำลังเข้าถึงเป้าหมายจริง แต่ต้นเหตุของปัญหากลับมาจากความผิดพลาดพื้นฐานด้าน Configuration อย่าง Network Isolation ที่ไม่รัดกุม ซึ่งสะท้อนว่าการควบคุมทางเทคนิคที่แข็งแรงยังคงเป็นเกราะป้องกันด่านแรกที่สำคัญกว่าการพึ่งพาพฤติกรรมของโมเดลเพียงอย่างเดียว
สำหรับองค์กรไทยที่กำลังเริ่มนำ AI Agent มาใช้ในงานด้าน Security Testing หรือกำลังประเมินความเสี่ยงจาก AI Agent ของผู้อื่น เหตุการณ์นี้ควรเป็นบทเรียนสำคัญว่าการทดสอบ AI ที่มีความสามารถ Offensive Security จำเป็นต้องมีการควบคุมสภาพแวดล้อมที่รัดกุมในทุกชั้น ตั้งแต่การตั้งชื่อเป้าหมายสมมติไปจนถึงการตัดขาดการเชื่อมต่ออินเทอร์เน็ตอย่างแท้จริง ไม่ใช่เพียงอาศัยคำสั่งหรือ Prompt เป็นขอบเขตความปลอดภัยเพียงอย่างเดียว รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: Cyber Security News, Cybernews, Wall Street Journal ]