พบช่องโหว่ใน AWS Systems Manager Agent ทำให้ผู้โจมตีสามารถ Bypass ข้อจำกัดของการทำ Port Forwarding ได้

พบช่องโหว่ใน AWS Systems Manager Agent ทำให้ผู้โจมตีสามารถ Bypass ข้อจำกัดของการทำ Port Forwarding ได้

ช่องโหว่ระดับ Critical ใน AWS Systems Manager Agent อาจทำให้ผู้โจมตีที่ผ่านการยืนยันตัวตนแล้ว สามารถ Bypass ข้อจำกัดของการทำ Port Forwarding ไปยัง Remote Host และเข้าถึงบริการแบบ Link-local ที่มีความสำคัญได้ ซึ่งรวมถึง Amazon EC2 Instance Metadata Service ด้วย

ช่องโหว่นี้มีหมายเลข CVE-2026-89049 ซึ่งส่งผลกระทบต่อ Amazon SSM Agent เวอร์ชันก่อนหน้า 3.3.4851.0 และได้รับการแก้ไขแล้วในเวอร์ชัน 3.3.4851.0

โดย AWS Systems Manager Agent ทำงานอยู่บน Amazon EC2 Instance, เซิร์ฟเวอร์แบบ On-premise และ Virtual machine เพื่อเปิดใช้งานความสามารถในการบริหารจัดการจากระยะไกล เช่น Run Command และ Session Manager

นอกจากนี้ Session Manager ยังรองรับการทำ Port Forwarding ซึ่งทำให้ผู้ใช้งานที่ได้รับอนุญาต สามารถสร้าง Tunnel ที่ปลอดภัยจาก Instance ที่อยู่ภายใต้การบริหารจัดการ ไปยังปลายทางภายนอกได้ โดยไม่ต้องเปิดพอร์ตเครือข่ายขาเข้า

ปัญหาดังกล่าวอยู่ในฟีเจอร์ Port Forwarding ไปยัง Remote Host ที่ถูกเรียกใช้งานผ่าน SSM Document ที่ชื่อว่า AWS-StartPortForwardingSessionToRemoteHost

รายละเอียดช่องโหว่ใน AWS Systems Manager Agent

ประกาศแจ้งเตือนบน GitHub ระบุว่า การป้องกันด้วย Denylist สำหรับ Link-local Address ของ Agent นั้นสามารถถูก Bypass ได้ เนื่องจากไม่มีการตรวจสอบรูปแบบการเขียน address ที่มีความหมายเทียบเท่ากันอย่างถูกต้อง

โดยปกติแล้ว Link-local IP Address จะถูกบล็อกไว้ เนื่องจากอาจเปิดเผยบริการภายในของระบบคลาวด์ที่ไม่ควรเข้าถึงได้ผ่าน Tunnel ที่ผู้ใช้เป็นผู้ควบคุม ซึ่งเป้าหมายหลักคือ EC2 Instance Metadata Service ที่โดยทั่วไปจะเข้าถึงได้ที่ 169.254.169.254

บริการดังกล่าวสามารถให้ข้อมูลยืนยันตัวตนชั่วคราวที่เชื่อมโยงกับ IAM Role ที่ผูกอยู่กับ EC2 Instance ได้ ทั้งนี้ผู้โจมตีจะต้องมีสิทธิ์เข้าถึง AWS ที่ผ่านการยืนยันตัวตนแล้ว และมีสิทธิ์ในการเริ่มต้น Session สำหรับการทำ Port Forwarding ไปยัง Remote Host อยู่ก่อนแล้ว

อย่างไรก็ตาม การโจมตีที่สำเร็จอาจทำให้ผู้ใช้รายนั้นสามารถส่งการเชื่อมต่อไปยัง Link-local Endpoint ที่ถูกจำกัดไว้ได้ ด้วยการใช้รูปแบบการเขียน address ปลายทางที่ถูกบล็อกในอีกรูปแบบหนึ่ง โดยช่องโหว่นี้ถูกจัดอยู่ในประเภท Server-Side Request Forgery (SSRF) และ Improper Validation of Unsafe Equivalent Input

หากผู้โจมตีสามารถดึงข้อมูลยืนยันตัวตนของ Instance Profile ออกมาจาก Metadata Service ได้ ก็จะสามารถนำข้อมูลดังกล่าวไปใช้เรียก AWS API จากภายนอก EC2 Instance ที่ถูกโจมตีได้ ซึ่งผลกระทบที่เกิดขึ้นจริงจะขึ้นอยู่กับ Permissions ที่ถูกกำหนดให้กับ IAM Role ของ Instance นั้น

โดย Role ที่ได้รับสิทธิ์มากเกินความจำเป็นอาจเปิดทางให้เข้าถึงทรัพยากรดังต่อไปนี้

  • S3 Bucket
  • Secrets ใน Secrets Manager
  • ฐานข้อมูล
  • Lambda Function
  • ทรัพยากรอื่น ๆ บนคลาวด์

ประกาศแจ้งเตือนได้จัดให้ช่องโหว่นี้มีความรุนแรงระดับ Critical โดยมี CVSS v3.1 vector เป็น AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H ซึ่งบ่งชี้ว่า

  • สามารถโจมตีได้ผ่านเครือข่าย
  • ใช้ Attack Complexity ในระดับต่ำ
  • ต้องการสิทธิ์ในระดับต่ำ
  • ไม่ต้องอาศัยการโต้ตอบจากผู้ใช้
  • ส่งผลกระทบได้ทั้งต่อ confidentiality, integrity และ availability ของข้อมูล

องค์กรควรอัปเดตระบบที่ได้รับผลกระทบเป็น SSM Agent เวอร์ชัน 3.3.4851.0 หรือใหม่กว่าโดยเร็วที่สุด นอกจากนี้ AWS ยังแนะนำให้ตรวจสอบ Build ของ Agent ที่ถูก Fork หรือดัดแปลงไป เพื่อให้แน่ใจว่าได้รวมการแก้ไขในส่วนของการตรวจสอบความถูกต้องเข้าไปแล้ว

ในระหว่างที่การติดตั้งแพตช์ยังไม่เสร็จสมบูรณ์ ผู้ดูแลระบบควรจำกัดการเข้าถึง SSM Document ที่ชื่อว่า AWS-StartPortForwardingSessionToRemoteHost และควรกำหนดขอบเขตของ IAM Permissions สำหรับ ssm:StartSession เพื่อไม่ให้ผู้ใช้ที่ไม่น่าเชื่อถือ, Identity ที่ใช้สำหรับระบบอัตโนมัติ และ Role ที่ถูกกำหนดสิทธิ์ไว้อย่างกว้างขวาง สามารถสร้าง Session สำหรับการทำ Port Forwarding ไปยัง Remote Host ได้

นอกจากนี้ ทีมความปลอดภัยควรดำเนินการเพิ่มเติมดังนี้

  • ตรวจสอบกิจกรรมการใช้งาน Session Manager
  • ตรวจสอบ IAM Role ที่ผูกอยู่กับ EC2 Instance
  • ใช้มาตรการกำหนดสิทธิ์ขั้นต่ำที่จำเป็น (Least Privilege) กับ Instance Profile

การตั้งค่าของ Amazon SSM Agent มีรายการ Endpoint ของ Metadata และ Link-local ที่ถูกปฏิเสธการเข้าถึงมาให้เป็นค่าเริ่มต้นอยู่แล้ว อย่างไรก็ตาม ช่องโหว่นี้ได้แสดงให้เห็นว่า เหตุใดการตรวจสอบความถูกต้องของ address จึงต้องคำนึงถึงรูปแบบการเขียนในลักษณะอื่น ๆ ด้วย แทนที่จะพึ่งพาเพียงการเทียบสตริงแบบตรงตัวเท่านั้น

ที่มา : Cybersecuritynews