สรุปสั้น

นาย Tamir Ishay Sharbat ผู้อำนวยการฝ่ายวิจัยความปลอดภัยของบริษัท Zenity Labs เปิดเผยบนเวที SecTor 2026 ที่โตรอนโตถึงจุดอ่อนที่ทีมตั้งชื่อว่า “AgentCorruption” ใน Amazon Bedrock AgentCore แพลตฟอร์มแบบ managed ของบริษัท Amazon Web Services (AWS) สำหรับ deploy และรันเอเจนต์ AI โดยเอเจนต์ที่รันบน AgentCore สามารถส่งคำขอ HTTP ไปยัง Instance Metadata Service (IMDS) ภายในอินสแตนซ์ของตัวเองได้ ผู้โจมตีที่มีแค่สิทธิ์แชตกับเอเจนต์ที่เปิดให้คนภายนอกใช้ เช่น แชตบอตฝ่ายบริการลูกค้า จึงสั่งด้วย prompt เดียวให้เอเจนต์ไปขอ credential ชั่วคราวของ execution role มาให้ได้ และเอเจนต์ก็ทำตาม

ปัญหาไม่ได้จบที่เอเจนต์ตัวเดียว เพราะ role เริ่มต้นของ AgentCore ได้สิทธิ์ครอบคลุมทรัพยากร AgentCore ทั้งหมดใน region เดียวกัน ไม่ได้จำกัดเฉพาะเอเจนต์ตัวนั้น นักวิจัยจึงใช้ credential ที่ได้เรียกเอเจนต์ตัวอื่น อ่านบทสนทนาส่วนตัวของผู้ใช้ ฝังความจำพิษ (memory poisoning) ให้เอเจนต์ และอ่านค่าใน AWS Secrets Manager ได้ ซึ่ง Zenity สรุปว่าเท่ากับยึด AgentCore ได้ทั้ง region ของบัญชีนั้นด้วย prompt เดียว

AWS ปรับ AgentCore ให้ใช้ IMDSv2 อย่างเดียวตั้งแต่ 14 กุมภาพันธ์ 2569 และตัดสิทธิ์สำคัญออกจาก role เริ่มต้น ซึ่ง Zenity ตรวจพบเมื่อ 29 กันยายน 2569 แต่ AWS ยืนยันว่าสิ่งที่รายงานเป็น “พฤติกรรมที่คาดไว้และระบุในเอกสาร” ไม่ใช่ช่องโหว่ จึงไม่มี CVE และ Zenity ระบุว่ายังไม่พบหลักฐานว่ามีการใช้โจมตีจริงก่อนการแก้ไข

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

เว็บไซต์ Dark Reading รายงานเมื่อวันที่ 7 ตุลาคม 2569 ว่านาย Sharbat นำเสนองานวิจัยนี้ที่งาน SecTor 2026 ในวันพุธ โดยเปิดด้วยมุมมองว่าตลอดปีที่ผ่านมา AI กับคลาวด์คอมพิวติง “เข้ากันไม่ได้” เหมือนไฟกับน้ำแข็ง Bedrock AgentCore เปิดตัวเมื่อปีก่อนในฐานะแพลตฟอร์มของ AWS สำหรับ deploy และดูแลเอเจนต์ AI ขณะที่ Zenity ทดสอบแพลตฟอร์มแล้วพบว่าเอเจนต์เข้าถึง IMDS ซึ่งเก็บข้อมูลอ่อนไหว เช่น credential ชั่วคราว รหัสอินสแตนซ์ และค่าตั้งค่า

นาย Sharbat โยงกรณีนี้กับเหตุข้อมูลรั่วของ Capital One เมื่อปี 2562 ที่ผู้โจมตีใช้ช่องโหว่ SSRF เข้าถึงอินสแตนซ์ EC2 แล้วยิงคำขอไปที่ IMDS เพื่อดึง credential ออกมา ซึ่งเขามองว่าเกิดเพราะไม่ใช้หลักสิทธิ์น้อยที่สุด (least privilege) กับ metadata service ส่วน AgentCorruption ใช้หลักเดียวกัน ต่างกันแค่ผู้โจมตีไม่ต้องหาช่องโหว่ SSRF เอง แต่หลอกเอเจนต์ที่เปิดสู่สาธารณะให้ทำงานแทน เขาบรรยายบนเวทีว่าขั้นตอนนี้ “ง่ายจนน่าตกใจ”

ตามไทม์ไลน์ของ Zenity ทีมรายงานเรื่องการเข้าถึง IMDS ให้ AWS ครั้งแรกเมื่อ 25 ธันวาคม 2568 และรายงานเพิ่มเรื่อง role เริ่มต้นที่มีสิทธิ์เกินจำเป็นและรัศมีความเสียหายเมื่อ 12 มกราคม 2569 AWS ปรับ AgentCore เป็น IMDSv2 อย่างเดียวเมื่อ 14 กุมภาพันธ์ ก่อนปิดรายงานฉบับแรกว่าเป็นเพียง “informative” เมื่อ 12 เมษายน ส่วนรายงานฉบับที่สอง AWS แจ้งเมื่อ 25 กุมภาพันธ์ว่ากำลังแก้ต้นเหตุ แต่เมื่อ Zenity ตรวจซ้ำวันที่ 22 มิถุนายน role ยังไม่เปลี่ยน จนวันที่ 29 กันยายนจึงพบว่า AWS ตัดสิทธิ์เรียกเอเจนต์ข้ามตัว อ่านบทสนทนาส่วนตัว และเข้าถึง Secrets Manager ออกแล้ว Zenity เผยแพร่รายงานเมื่อ 8 ตุลาคม

โฆษกของ AWS ให้แถลงการณ์กับ Dark Reading ว่างานวิจัยนี้ “วาดภาพพฤติกรรมที่คาดไว้และระบุในเอกสารให้ดูเหมือนช่องโหว่อย่างไม่ถูกต้อง” และระบุว่าเอเจนต์จะเข้าถึงทรัพยากรในบัญชี AWS อื่นได้ก็ต่อเมื่อนักพัฒนาให้สิทธิ์ไว้ทั้งที่ execution role และทรัพยากรปลายทาง พร้อมแนะนำให้ลูกค้าให้สิทธิ์ execution role เท่าที่เอเจนต์ต้องใช้เท่านั้น ข้อสังเกตคือคำชี้แจงนี้พูดถึงการเข้าถึง “ข้ามบัญชี” ขณะที่งานวิจัยของ Zenity แสดงการขยายผลภายในบัญชีและ region เดียวกันโดยใช้ role ค่าเริ่มต้นของแพลตฟอร์มเอง

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

ต้นเหตุตามที่ Zenity อธิบายคือเอเจนต์บน AgentCore รันอยู่ใน Firecracker MicroVM ที่ไม่มีการแยกเครือข่ายเพียงพอ เครื่องมือใดของเอเจนต์ที่ส่งคำขอ HTTP ได้จึงกลายเป็น SSRF primitive ไปโดยปริยาย ลำดับการโจมตีที่นักวิจัยสาธิตมีดังนี้

  1. Prompt injection — ส่ง prompt ให้เอเจนต์ที่เปิดสู่สาธารณะยิงคำขอ HTTP ไปที่ที่อยู่ link-local ของ IMDS คือ 169.254.169.254
  2. ดึง credential — เพราะคำขอมาจากภายในอินสแตนซ์ IMDS จึงคืน credential ชั่วคราวของ execution role ให้
  3. สำรวจ — ใช้สิทธิ์ DescribeLogGroups ไล่หาเอเจนต์และ ID ของเอเจนต์ทั้งหมดใน region และดึง container image จาก ECR ได้ เพราะชื่อ repository ตรงกับ ID ของเอเจนต์
  4. ขยายผล — ใช้ bedrock-agentcore:InvokeAgentRuntime เรียกเอเจนต์ตัวใดก็ได้ใน region และใช้ bedrock-agentcore:ListEvents อ่านเซสชัน ประวัติบทสนทนา และรายชื่อผู้ใช้
  5. คงอยู่ผ่านความจำ — ใช้ bedrock-agentcore:CreateEvent เขียนความจำลงเอเจนต์ที่เปิด long-term memory ข้ามผู้ใช้ได้ ความจำพิษจะติดไปทุกเซสชันถัดไป ผู้ใช้ยังคุยกับเอเจนต์ที่ดูเป็นของบริษัทจริง แต่เอเจนต์ทำตามคำสั่งของผู้โจมตี
  6. ขโมยความลับ — ใช้ bedrock-agentcore:GetResourceApiKey และ secretsmanager:GetSecretValue ดึง API key ของเครื่องมือที่เชื่อมกับเอเจนต์และค่าใน Secrets Manager

นาย Sharbat ระบุว่าไม่พบหลักฐานการโจมตีจริงก่อน AWS แก้ไข ส่วนหนึ่งเพราะมี “security through obscurity” คือภายนอกบอกได้ยากว่าองค์กรไหน deploy เอเจนต์อะไรไว้บน AgentCore แต่เขาก็บอกว่า “มั่นใจ 100% ว่ามีวิธีหา” ทั้งนี้ข้อมูลที่ว่าการเปลี่ยนเป็น IMDSv2 มีผลกับเอเจนต์ที่ deploy ใหม่ หมายความว่าเอเจนต์ที่ deploy ไว้ก่อนหน้าอาจยังต้องตรวจสอบเอง

ผลกระทบ

กรณีนี้ชี้ให้เห็นว่าเมื่อเอเจนต์ AI ที่มีเครื่องมือส่งคำขอเครือข่ายได้ถูกวางในคลาวด์ prompt injection ก็ทำหน้าที่เดียวกับ SSRF แบบคลาสสิก โดยไม่ต้องมีบั๊กในโค้ดเลย และรัศมีความเสียหายถูกกำหนดด้วยสิทธิ์ของ IAM role ไม่ใช่ด้วยตัวเอเจนต์ องค์กรที่ใช้ role ค่าเริ่มต้นของ AgentCore ในช่วงก่อนการแก้ไขจึงเสี่ยงที่แชตบอตตัวเดียวที่เปิดสู่ลูกค้าจะกลายเป็นทางเข้าไปยังเอเจนต์ภายใน บทสนทนาของผู้ใช้ทุกคน และ API key ของระบบที่เชื่อมต่ออยู่

ความเสี่ยงที่น่ากังวลเป็นพิเศษคือ memory poisoning เพราะหลังผู้โจมตีออกไปแล้ว พฤติกรรมผิดปกติยังค้างอยู่ในเอเจนต์ที่ผู้ใช้เชื่อถือ และตรวจพบได้ยากกว่าการขโมย credential ครั้งเดียว ขณะเดียวกันการที่ AWS มองว่าเป็นพฤติกรรมตามเอกสาร หมายความว่าภาระการจำกัดสิทธิ์อยู่ที่ลูกค้า Zenity ระบุว่ากำลังตรวจแพลตฟอร์มคลาวด์รายอื่นอยู่และเชื่อว่าจุดอ่อนเรื่อง IMDS ไม่ได้จำกัดอยู่ที่ AWS

คำแนะนำ

  • ตรวจ execution role ของเอเจนต์บน AgentCore ทุกตัว เลิกใช้ role ค่าเริ่มต้นแบบกว้าง และจำกัดสิทธิ์ให้เหลือเฉพาะทรัพยากรของเอเจนต์ตัวนั้น โดยเฉพาะ InvokeAgentRuntime, ListEvents, CreateEvent, GetResourceApiKey และ secretsmanager:GetSecretValue
  • ยืนยันว่าเอเจนต์ที่ deploy ไว้ก่อนกุมภาพันธ์ 2569 ใช้ IMDSv2 แล้ว และพิจารณา redeploy หากไม่แน่ใจ
  • แยกเอเจนต์ที่เปิดให้ลูกค้าหรือคนภายนอกใช้ออกจากเอเจนต์ภายในคนละบัญชีหรือคนละ role ไม่ให้ใช้สิทธิ์ร่วมกัน
  • จำกัดเครื่องมือ HTTP ของเอเจนต์ด้วย allowlist ปลายทาง และบล็อกที่อยู่ link-local 169.254.169.254 จากเครื่องมือที่รับอินพุตจากผู้ใช้
  • ตรวจ CloudTrail ย้อนหลังหาการเรียก InvokeAgentRuntime, ListEvents, CreateEvent และ GetSecretValue ที่ผิดปกติจาก credential ของเอเจนต์ และตรวจความจำระยะยาวของเอเจนต์ว่ามีรายการที่ไม่ได้สร้างโดยระบบหรือไม่
  • หมุนเวียน secret และ API key ของเครื่องมือที่ role ของเอเจนต์เคยอ่านได้ หากเอเจนต์นั้นเปิดสู่สาธารณะในช่วงก่อนการแก้ไข

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