สรุปสั้น
องค์กร METR ซึ่งย่อมาจาก Model Evaluation and Threat Research และเป็นองค์กรวิจัยไม่แสวงหากำไรที่ประเมินความสามารถของโมเดล AI ระดับแนวหน้าในการทำงานแบบเอเจนต์ที่กินเวลายาว เปิดเผยว่าตัวเองเผชิญเหตุการณ์ด้านความปลอดภัยที่น่าสังเกตสองครั้ง ซึ่งผู้กระทำจากภายนอกพยายามเข้าถึงระบบขององค์กรโดยไม่ได้รับอนุญาต โดยองค์กรเชื่อว่าไม่มีข้อมูลอ่อนไหวถูกเข้าถึง และได้แบ่งปันผลการตรวจสอบฉบับหนึ่งให้บริษัท AI ที่ทำงานด้วยกันก่อนเปิดเผยต่อสาธารณะ
เหตุการณ์แรกเกิดขึ้นในเดือนมีนาคม 2569 ผู้โจมตีขโมยกุญแจ API สำหรับเรียกใช้การอนุมานบนโมเดลสาธารณะ แล้วเผาเครดิตไปเป็นจำนวนมากตลอดสามสัปดาห์ ซึ่ง METR ระบุว่าหากไม่ได้รับเครดิตฟรีจากผู้ให้บริการโมเดล มูลค่าที่ต้องจ่ายจะอยู่ที่ราว 600,000 ดอลลาร์สหรัฐฯ เหตุการณ์ที่สองเกิดขึ้นในเดือนพฤษภาคม 2569 เป็นการที่ผู้โจมตีสำรวจโครงสร้างพื้นฐานที่เปิดสู่สาธารณะอย่างเป็นระบบ รวมถึงความพยายามที่ไม่สำเร็จในการเข้าถึงข้อมูลภายในผ่านจุดปลายทางที่เปิดออกไปโดยไม่ตั้งใจ
จุดที่ควรสังเกตคือ METR ระบุชัดว่าการโจมตีทั้งสองครั้งยังไม่ถูกเชื่อมโยงกับผู้คุกคามหรือกลุ่มใดที่รู้จัก และไม่ได้เกี่ยวข้องกับกรณีที่เอเจนต์ AI เจาะเข้าไปในการประเมินขององค์กร ซึ่งเป็นการแยกประเด็นให้ชัดว่านี่คือการถูกโจมตีจากภายนอกแบบปกติ ไม่ใช่กรณีเอเจนต์หลุดกรอบแบบที่เป็นข่าวก่อนหน้านี้
รายละเอียดข่าว
เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 1 กันยายน 2569 ว่า METR เผยแพร่รายงานอัปเดตด้านความปลอดภัยที่อธิบายเหตุการณ์ทั้งสองครั้งด้วยตัวเอง โดยเหตุการณ์แรกในเดือนมีนาคม 2569 มีจุดเริ่มต้นจากนักวิจัยคนหนึ่งขององค์กรที่ไม่มีสิทธิ์เข้าถึงข้อมูลอ่อนไหว ใช้เอเจนต์ที่รันอยู่บนอินสแตนซ์ EC2 ส่วนตัว ซึ่งตั้งใจเปิดให้เข้าถึงได้จากสาธารณะโดยมีการยืนยันตัวตนของ Google คั่นไว้ และในอินสแตนซ์นั้นมีกุญแจ API ของบัญชีสำหรับเข้าถึงทั่วไปของ METR ซึ่งใช้กับโมเดลสาธารณะเก็บอยู่
ปัญหาคือแอปที่ METR เรียกว่า “vibe-coded app” หรือแอปที่เขียนขึ้นโดยพึ่งพา AI ช่วยเขียนโค้ด มีช่องโหว่ประเภทล้มแบบเปิด (fail-open) ที่ปิดการยืนยันตัวตนไปอย่างเงียบ ๆ ทำให้แดชบอร์ดควบคุมการทำงานของเอเจนต์เปิดออกสู่อินเทอร์เน็ตสาธารณะอยู่หลายวัน
METR อธิบายสมมติฐานของตัวเองว่า จากการวิเคราะห์แล้วสงสัยว่าผู้โจมตีพบอินสแตนซ์นี้ด้วยการไล่ดูเว็บไซต์ที่เพิ่งจดทะเบียนใหม่ เช่นในรายการ certificate transparency เพื่อหาเว็บไซต์ที่เขียนขึ้นด้วย AI และมีคำสำคัญที่ส่งสัญญาณชัดเจนเกี่ยวกับโมเดลภาษาขนาดใหญ่หรือเอเจนต์ โดยมีจุดประสงค์เพื่อเก็บเกี่ยวกุญแจ API ของผู้ให้บริการโมเดลที่อาจเปิดทิ้งไว้
เมื่อระบุระบบเป้าหมายได้แล้ว ผู้คุกคามก็สั่งเอเจนต์โดยตรงให้เปิดเผยกุญแจ API ของผู้ให้บริการโมเดลออกมา จากนั้นเพิ่มกุญแจ SSH เข้าไปเพื่อคงการเข้าถึงไว้ แล้วใช้ข้อมูลรับรองที่ขโมยมาเผาเครดิต API บนโมเดลที่เปิดให้ใช้งานทั่วไปเป็นจำนวนมากตลอดระยะเวลาสามสัปดาห์
สิ่งที่ทำให้การใช้งานผิดปกตินี้ไม่ถูกจับได้ทันทีมีสองอย่างประกอบกัน อย่างแรกคือ METR รันการประเมินและการทดลองขนาดใหญ่ซึ่งปกติก็กินโทเคนจำนวนมากอยู่แล้ว ทำให้ยอดใช้งานที่พุ่งขึ้นไม่โดดออกมาจากพฤติกรรมปกติ อย่างที่สองคือไม่มีการตั้งเพดานการใช้จ่ายโทเคนไว้เลย หลังเหตุการณ์ METR ระบุว่าได้ปรับนโยบายความปลอดภัยเรื่องการนำข้อมูลรับรองหรือข้อมูลขององค์กรไปไว้บนโครงสร้างพื้นฐานหรืออุปกรณ์ที่ไม่ใช่ขององค์กร ปรับปรุงการเฝ้าระวัง และเพิ่มการแจ้งเตือนการใช้จ่ายให้กับกุญแจเท่าที่ทำได้แล้ว
วิธีการโจมตี
เหตุการณ์ที่สองในเดือนพฤษภาคม 2569 ถูก METR อธิบายว่าเป็นแคมเปญโจมตีจากภายนอกที่ดำเนินการต่อเนื่อง โดยผู้คุกคามที่มีแนวโน้มว่ามีแรงจูงใจทางการเงินและต้องการเข้าถึงโมเดล AI ระดับแนวหน้าโดยมิชอบ
รูปแบบการโจมตีคือการสำรวจโครงสร้างพื้นฐานที่เปิดสู่สาธารณะขององค์กรอย่างเป็นระบบ โดยใช้เอเจนต์ช่วยทำงานค้นหาช่องโหว่แบบอัตโนมัติอย่างหนัก ซึ่งครอบคลุมทั้งการยัดข้อมูลรับรองใส่ผู้ให้บริการยืนยันตัวตน การพยายามขอโทเคน OAuth การสแกนบริการที่เพิ่งถูกนำขึ้นใช้งาน และการพยายามฟิชชิงพนักงาน
ในช่วงเวลาไล่เลี่ยกัน METR ระบุว่าตัวเองเปิดกลไกคิวรี SQL แบบอ่านอย่างเดียวที่ฝังอยู่ในตัวแสดงบันทึกการสนทนาสาธารณะออกไปโดยไม่ตั้งใจ แม้คิวรีจะถูกจำกัดขอบเขตให้อยู่กับข้อมูลสาธารณะตามค่าเริ่มต้น แต่จุดบกพร่องในองค์ประกอบดังกล่าวอาจถูกใช้ประโยชน์เพื่อเข้าถึงข้อมูลการประเมินที่ยังไม่เผยแพร่ได้ ซ้ำร้ายฐานข้อมูลนั้นยังมีข้อมูลของโมเดลที่อ่อนไหวปนเข้ามาโดยอุบัติเหตุ ทั้งที่ตามการออกแบบควรมีเฉพาะข้อมูลของโมเดลที่ไม่อ่อนไหวเท่านั้น
METR ระบุว่าองค์กรรู้ตัวเรื่องนี้ก็ต่อเมื่อมีนักวิจัยความปลอดภัยอิสระค้นพบและแจ้งเข้ามา จึงนำ API ดังกล่าวออกจากระบบ โดยผู้โจมตีเคยสำรวจจุดปลายทางนี้ผ่าน ๆ ในระหว่างแคมเปญที่กว้างกว่า แต่หลักฐานไม่มีสิ่งบ่งชี้ว่าพวกเขาค้นพบวิธีใช้ประโยชน์หรือเข้าถึงข้อมูลที่ไม่ใช่ข้อมูลสาธารณะได้
ผลกระทบ
บทเรียนที่ตรงที่สุดจากเหตุการณ์แรกไม่ใช่เรื่องของตัวเลข 600,000 ดอลลาร์สหรัฐฯ แต่เป็นเส้นทางที่นำไปสู่ตัวเลขนั้น กล่าวคือกุญแจ API ขององค์กรถูกวางไว้บนโครงสร้างพื้นฐานส่วนตัวของพนักงาน แล้วอาศัยการยืนยันตัวตนของแอปที่ไม่ได้ผ่านการทบทวนความปลอดภัยเป็นด่านเดียว เมื่อด่านนั้นล้มแบบเปิดโดยไม่มีใครรู้ กุญแจก็เปิดโล่งอยู่บนอินเทอร์เน็ตหลายวัน
พฤติกรรมการล่าเป้าหมายที่ METR อธิบายมีความหมายกว้างกว่าเคสของตัวเอง เพราะการที่ผู้โจมตีไล่ดูรายการ certificate transparency เพื่อหาเว็บไซต์ที่เพิ่งขึ้นใหม่และมีคำสำคัญเกี่ยวกับโมเดลภาษาหรือเอเจนต์ แปลว่าโครงการทดลองส่วนตัวที่ถูกนำขึ้นออนไลน์ชั่วคราวก็อยู่ในเรดาร์ตั้งแต่วันแรกที่ออกใบรับรอง ไม่ได้ปลอดภัยเพราะไม่มีใครรู้จัก
การตรวจไม่พบเป็นเวลาสามสัปดาห์ก็เป็นประเด็นที่นำไปใช้ได้ทั่วไป องค์กรที่มีการใช้งาน API ของโมเดลในปริมาณสูงและผันผวนตามธรรมชาติของงาน จะสูญเสียความสามารถในการใช้ยอดการใช้งานเป็นสัญญาณเตือน หากไม่มีเพดานการใช้จ่ายและการแจ้งเตือนที่ผูกกับกุญแจแต่ละใบแยกกัน
ส่วนเหตุการณ์ที่สองสะท้อนอีกประเด็นหนึ่ง คือการที่ผู้โจมตีใช้เอเจนต์ทำงานค้นหาช่องโหว่แบบอัตโนมัติ ทำให้การสำรวจพื้นผิวการโจมตีเกิดขึ้นในวงกว้างและต่อเนื่องด้วยต้นทุนที่ต่ำลง องค์กรจึงต้องสมมติว่าบริการที่เพิ่งนำขึ้นใช้งานจะถูกสแกนแทบจะทันที และการที่ช่องโหว่ของตัวแสดงบันทึกถูกพบโดยนักวิจัยอิสระก่อนผู้โจมตี เป็นเรื่องของลำดับเวลามากกว่าการป้องกัน
คำแนะนำ
- ห้ามนำกุญแจ API หรือข้อมูลขององค์กรไปวางบนโครงสร้างพื้นฐานหรืออุปกรณ์ส่วนตัวของพนักงาน และกำหนดนโยบายนี้ให้ชัดเจนพร้อมช่องทางที่ถูกต้องสำหรับงานทดลอง
- ตั้งเพดานการใช้จ่ายและการแจ้งเตือนแยกตามกุญแจแต่ละใบ โดยเฉพาะในองค์กรที่ปริมาณการใช้งานปกติสูงจนกลบความผิดปกติ
- ออกกุญแจแบบมีอายุจำกัดและมีขอบเขตสิทธิ์แคบที่สุดเท่าที่งานต้องการ พร้อมหมุนกุญแจเป็นระยะ
- ทดสอบเส้นทางความล้มเหลวของกลไกยืนยันตัวตนอย่างชัดเจนว่าต้องล้มแบบปิด ไม่ใช่ล้มแบบเปิด โดยเฉพาะในแอปที่เขียนขึ้นอย่างรวดเร็วด้วยความช่วยเหลือของ AI
- ทำบัญชีบริการที่เปิดสู่อินเทอร์เน็ตให้ครบ รวมถึงเครื่องมือภายในและโครงการทดลอง และเฝ้าระวังใบรับรองที่ออกใหม่ในโดเมนขององค์กรเพื่อจับบริการที่ถูกนำขึ้นโดยไม่ผ่านกระบวนการ
- ทบทวนจุดปลายทางที่ให้ผู้ใช้ส่งคิวรีไปยังฐานข้อมูล แม้จะเป็นแบบอ่านอย่างเดียว โดยตรวจทั้งขอบเขตของคิวรีและเนื้อหาที่อยู่ในฐานข้อมูลจริงว่าตรงกับที่ออกแบบไว้หรือไม่
- จัดให้มีช่องทางรับรายงานช่องโหว่จากนักวิจัยภายนอกที่ชัดเจนและตอบสนองเร็ว เพราะในกรณีนี้เป็นช่องทางที่ทำให้องค์กรรู้ตัว
