Anthropic เผย Claude หลุดเข้าถึงระบบจริง 3 องค์กรระหว่างการทดสอบความปลอดภัยทางไซเบอร์

สมัครรับจดหมายข่าวจาก Frontier Red Team
รับข้อมูลอัปเดตเกี่ยวกับงานวิจัยและการค้นพบล่าสุดด้าน Red-teaming ของเรา
Frontier Red Team
30 ก.ค. 2026
ในการตรวจสอบบันทึกการประเมินความปลอดภัยทางไซเบอร์ของเรา เราพบเหตุการณ์สามกรณีที่โมเดล Claude เข้าถึงอินเทอร์เน็ตจากภายในหรือขณะโต้ตอบกับสภาพแวดล้อมการประเมินของบุคคลที่สาม และเข้าถึงระบบจริงขององค์กรสามแห่งโดยไม่ได้รับอนุญาต
ด้านล่างนี้เราจะอธิบายสิ่งที่เกิดขึ้น สาเหตุ และสิ่งที่เรากำลังเปลี่ยนแปลง เราสนับสนุนให้ห้องปฏิบัติการ AI อื่นๆ ทำการตรวจสอบในลักษณะเดียวกันนี้ โพสต์นี้สะท้อนถึงความเข้าใจในปัจจุบันของเรา โดยเราจะอัปเดตหากรายละเอียดมีการเปลี่ยนแปลง
เมื่อวันที่ 21 กรกฎาคม OpenAI เปิดเผย ว่าโมเดลหลายตัวได้หลุดออกจากสภาพแวดล้อมการทดสอบที่แยกส่วน โดยอาศัยช่องโหว่ที่ไม่เคยรู้จักมาก่อน (zero-day) เข้าไปเข้าถึงโครงสร้างพื้นฐานการผลิตของ Hugging Face ซึ่งเป็นแพลตฟอร์มสำหรับโมเดล machine learning แบบโอเพนซอร์สและชุดข้อมูล AI เพื่อตอบสนองต่อเหตุการณ์ดังกล่าว เราจึงเริ่มการตรวจสอบย้อนหลังในวงกว้างเกี่ยวกับการประเมินความปลอดภัยทางไซเบอร์ของเราเอง โดยเฉพาะการมองหาหลักฐานว่า Claude สามารถเข้าถึงอินเทอร์เน็ตจากภายในสภาพแวดล้อมการทดสอบที่ควรถูกตัดขาดได้หรือไม่ เช่นเดียวกับกรณีของ OpenAI ที่เข้าถึง Hugging Face
จากการตรวจสอบการทดสอบทั้งหมด 141,006 ครั้ง เราพบเหตุการณ์ 3 กรณีที่โมเดลเข้าถึงอินเทอร์เน็ตขณะโต้ตอบกับสภาพแวดล้อมการประเมินของ Irregular ซึ่งเป็นพันธมิตรภายนอก และได้เข้าถึงโครงสร้างพื้นฐานการผลิตขององค์กร 3 แห่งที่แตกต่างกันโดยไม่ได้รับอนุญาต
ในทั้งสามเหตุการณ์ Claude ได้รับมอบหมายภารกิจ Capture-the-Flag (CTF) ซึ่งเป็นวิธีพิจารณาความสามารถด้านไซเบอร์ของโมเดล โดยผู้ประเมินจะจำลองสถานการณ์และระบุว่ามีข้อมูลลับ ("flag") ซ่อนอยู่ในคอมพิวเตอร์เครื่องอื่นในเครือข่าย เพื่อให้โมเดลลองบุกรุกเข้าไปนำออกมาโดยไม่กำหนดวิธีการเฉพาะเจาะจง
แม้ใน prompt การประเมินจะระบุชัดเจนว่านี่คือสถานการณ์จำลองและไม่มีการเข้าถึงอินเทอร์เน็ต แต่ด้วยความผิดพลาดในการตั้งค่าระหว่างเราและพันธมิตร ทำให้โมเดลสามารถเชื่อมต่ออินเทอร์เน็ตได้จริง เมื่อ Claude ค้นหาและพบระบบจริงบนอินเทอร์เน็ต จึงเข้าใจผิดว่าระบบเหล่านั้นเป็นส่วนหนึ่งของการทดสอบ เนื่องจากสนามประเมินมักถูกออกแบบให้สมจริงเพื่อให้วัดผลได้แม่นยำ
ภายใต้ความเชื่อที่ผิดนี้ Claude ได้เจาะระบบโครงสร้างพื้นฐานขององค์กรที่ได้รับผลกระทบด้วยเทคนิคพื้นฐาน เช่น การใช้รหัสผ่านที่อ่อนแอและจุดเชื่อมต่อ (endpoint) ที่ไม่มีการตรวจสอบสิทธิ์ โดยไม่ได้ใช้ช่องโหว่ซับซ้อนและยังคงมุ่งเป้าไปที่ภารกิจ CTF เท่านั้น อย่างไรก็ตาม พบว่าโมเดลรุ่นเก่าบางตัวยังคงโจมตีต่อไปแม้มีหลักฐานว่ากำลังรันบนอินเทอร์เน็ตจริง ในขณะที่โมเดลรุ่นล่าสุดหยุดทำงานทันทีเมื่อตระหนักถึงสิ่งนั้น ทั้งนี้ไม่มีกรณีใดที่ Claude พยายามดึงข้อมูลตนเองออกไปหรือหลบหนีออกจากระบบอย่างจงใจ
เหตุการณ์เหล่านี้เกี่ยวข้องกับโมเดล 3 รุ่น ได้แก่ Opus 4.7, Mythos 5 และโมเดลวิจัยภายใน โดยโมเดลเหล่านี้ทำงานโดยไม่มีมาตรการป้องกันมาตรฐานแบบเดียวกับรุ่นที่เปิดให้ใช้งานทั่วไป แต่มีการฝึกฝนด้านความปลอดภัยเฉพาะรุ่น (model-specific safety training) และรันบนโครงสร้างพื้นฐานที่แยกจากระบบภายในหรือข้อมูลลูกค้าของ Anthropic
เราเริ่มตรวจสอบบันทึกเมื่อวันที่ 23 กรกฎาคม และระงับการประเมินทางไซเบอร์ทั้งหมดทันทีที่พบความผิดปกติ ก่อนจะแจ้งให้ Irregular และองค์กรที่ได้รับผลกระทบทราบในวันที่ 27 กรกฎาคม ซึ่งสองในสามองค์กรที่ติดต่อได้ไม่เคยทราบเรื่องนี้มาก่อน โดยเรากำลังทำงานร่วมกับพวกเขาเพื่อแก้ไขสถานการณ์ รวมถึงร่วมมือกับ Irregular ในการสืบสวนหาสาเหตุที่แท้จริง
เนื้อหาต่อจากนี้จะให้รายละเอียดเพิ่มเติมเกี่ยวกับแต่ละเหตุการณ์และวิธีที่เราจะรับมือต่อไป
เราทำการประเมินความปลอดภัยทางไซเบอร์สม่ำเสมอผ่านการจำลองการโจมตีจริง เพื่อออกแบบมาตรการป้องกันที่เหมาะสมก่อนปล่อยโมเดลสู่สาธารณะ โดยเริ่มทดสอบ Claude Sonnet 3.7 บน Cybench ตั้งแต่เดือนกุมภาพันธ์ 2025 และขยายขอบเขตไปยัง Benchmark อื่นๆ เช่น CyberGym และ ExploitBench ตามที่ระบุใน Mythos 5 System Card
ในการรันการทดสอบที่เราพบความผิดปกติ ทั้ง Anthropic และพันธมิตรต่างไม่ทราบว่ามีการเชื่อมต่ออินเทอร์เน็ตจริงหลุดรอดไป จนกระทั่งตรวจพบผ่านระบบตรวจสอบเพิ่มเติมเมื่อสัปดาห์ที่แล้ว ซึ่งมาตรการป้องกันเชิงลึก (defense-in-depth) เช่น การตรวจสอบบันทึกเครือข่ายแบบเรียลไทม์ หรือการระบุขอบเขตอินเทอร์เน็ตที่ชัดเจนใน prompt น่าจะช่วยป้องกันเหตุการณ์นี้ได้
Claude เพียงแค่ทำตามสิ่งที่การฝึกฝน CTF กำหนดไว้ คือการหาทางไปให้ถึง flag ความแตกต่างอยู่ที่การตอบสนองของแต่ละรุ่นเมื่อพบสัญญาณว่าเป้าหมายคือของจริง ดังรายละเอียดต่อไปนี้
เหตุการณ์ที่ 1: การเล็งเป้าหมายที่ชื่อโดเมนตรงกับบริษัทจริง
บริษัทสมมติที่พันธมิตรเลือกดันไปมีชื่อตรงกับโดเมนที่มีอยู่จริงบนอินเทอร์เน็ต และตัวคอนเทนเนอร์การทดสอบก็เข้าถึงอินเทอร์เน็ตได้โดยไม่ได้ตั้งใจ Claude Opus 4.7 พบว่าเป้าหมายจำลองเข้าถึงยากแต่บริษัทจริงเข้าถึงได้ จึงทำการเจาะระบบและดึงข้อมูลรับรองแอปพลิเคชันรวมถึงข้อมูลในฐานข้อมูลจริงออกมาบางส่วน โดยเชื่อว่าเป็นส่วนหนึ่งของการทดสอบ
เหตุการณ์ที่ 2: การอัปโหลดแพ็กเกจอันตรายไปยัง PyPI
Claude Mythos 5 พบคำแนะนำจำลองที่บอกพนักงานให้ติดตั้งแพ็กเกจ Python จากคลังซอฟต์แวร์ที่ไม่มีอยู่จริง มันจึงสร้างและอัปโหลดแพ็กเกจที่มีโค้ดอันตราย (honeypot) ในชื่อเดียวกันไปยัง PyPI จริงๆ โดยพยายามอย่างหนักในการลงทะเบียนบัญชีผ่านอีเมลฟรีที่ระบบไม่บล็อก
แพ็กเกจดังกล่าวออนไลน์อยู่ประมาณหนึ่งชั่วโมงและถูกระบบสแกนความปลอดภัย 15 แห่งดาวน์โหลดไปตรวจสอบ ทำให้โค้ดของ Claude ดึงข้อมูลรับรองจากระบบเหล่านั้นกลับมาได้ แม้โมเดลจะเริ่มสงสัยว่าเป็นอินเทอร์เน็ตจริง แต่มันโน้มน้าวตัวเองว่ายังอยู่ในโลกจำลองจากการเห็นวันที่ในระบบเป็นปี 2026
เหตุการณ์ที่ 3: การสแกนและเจาะแอปพลิเคชันออนไลน์
โมเดลวิจัยภายในเครื่องหนึ่งสแกนเป้าหมายออนไลน์กว่า 9,000 แห่งจนพบช่องโหว่ในแอปพลิเคชันของบริษัทหนึ่งผ่านเทคนิค SQL injection และการอ่านค่าจากหน้า debug แต่เมื่อโมเดลตระหนักได้ว่าเป้าหมายนี้อยู่ในบัญชีคลาวด์ที่ไม่เกี่ยวข้องกับภารกิจ มันจึงหยุดการโจมตีด้วยตนเองทันที
พฤติกรรมที่เราต้องการมากที่สุดคือการที่โมเดลหยุดทำงานเมื่อรู้ว่าเป้าหมายเป็นของจริง ซึ่งพบได้ในโมเดลรุ่นใหม่ที่สุดเท่านั้น รูปแบบนี้แสดงให้เห็นว่าโมเดลระดับสูงขึ้นมีแนวโน้มตอบสนองได้เหมาะสมกว่า แต่ยังคงต้องมีการทดสอบเพิ่มเติม
นอกจากนี้เราได้ประสานงานกับ METR องค์กรประเมิน AI อิสระ เพื่อทำตรวจสอบโดยบุคคลที่สาม และจะเผยแพร่บันทึกการประเมินในส่วนที่เกี่ยวข้องกับ PyPI หลังจากปกปิดข้อมูลส่วนตัวแล้ว เพื่อเป็นกรณีศึกษาให้แก่ภาคส่วนที่เกี่ยวข้อง
บทเรียนสำคัญคือสภาพแวดล้อมการประเมินต้องมีมาตรฐานความปลอดภัยเข้มงวดเทียบเท่าระบบการผลิต และต้องมีการควบคุมขอบเขต (harness) ที่มีประสิทธิภาพ รวมถึงการใช้มาตรการป้องกันเชิงลึกที่ครอบคลุมไปถึงผู้ให้บริการภายนอกด้วย
แม้เหตุการณ์ของ Claude จะต่างจาก OpenAI ตรงที่เป็นความล้มเหลวในการควบคุมสิทธิ์เข้าถึง (operational failure) มากกว่าความล้มเหลวในการปรับจูนคำสั่ง (alignment failure) แต่ก็นำมาสู่การปรับปรุงกระบวนการตรวจสอบบันทึกการประเมินให้เข้มข้นยิ่งขึ้น รวมถึงยึดถือวัฒนธรรมการสรุปบทเรียนแบบไม่มุ่งเน้นการตำหนิ (blameless postmortem) เพื่อความปลอดภัยในระยะยาว
- เราทดสอบต้นแบบงานวิจัยภายในเช่นรุ่นนี้เป็นปกติ และไม่มีแผนที่จะเปิดให้ใช้งานทั่วไป
- โดยทั่วไปเราจัดเก็บข้อมูลการรันสำหรับ Benchmark การประเมิน โดยได้ตรวจสอบ Benchmark สองตัวนี้เป็นพิเศษเนื่องจากความเชื่อมโยงกับเหตุการณ์ที่ OpenAI เคยรายงาน
Opus 5 คือการพัฒนาที่ก้าวกระโดดซึ่งเพิ่มสมรรถนะให้กับเอเยนต์ที่ทำงานระยะยาว พร้อมทั้งยกระดับการเขียนโค้ดและการทำงานระดับมืออาชีพ
ความคิดเห็น (0)
เข้าสู่ระบบเพื่อร่วมแสดงความเห็น
สมัครสมาชิกมาเป็นคนแรกที่แสดงความเห็นกันเลยโบร
