นักวิจัยด้านความปลอดภัยพบการโจมตีแบบ Name confusion attack ที่ทำให้บุคคลใดก็ตามสามารถเข้าถึงบัญชี Amazon Web Services (AWS) ได้ เพียงแค่ publishes Amazon Machine Image (AMI) โดยใช้ชื่อเฉพาะ
การโจมตีนี้ถูกตั้งชื่อว่า "whoAMI" และถูกพัฒนาโดยนักวิจัยจาก DataDog ในเดือนสิงหาคม 2024 ซึ่งแสดงให้เห็นว่า ผู้โจมตีสามารถเรียกใช้โค้ดภายในบัญชี AWS ได้ โดยอาศัยช่องโหว่ในการดึงค่า AMI ID ของซอฟต์แวร์โปรเจกต์ต่าง ๆ
Amazon ยืนยันถึงช่องโหว่นี้ และได้ออกแพตช์แก้ไขในเดือนกันยายน 2024 แต่ช่องโหว่จะยังคงมีอยู่ในฝั่งลูกค้า โดยเฉพาะในสภาพแวดล้อมที่องค์กรไม่ได้อัปเดตโค้ดให้เป็นเวอร์ชันที่ปลอดภัย
การดำเนินการโจมตี whoAMI
AMI เป็น Virtual machines ที่ถูก preconfigured ไว้ล่วงหน้าพร้อมซอฟต์แวร์ที่จำเป็น (ระบบปฏิบัติการ และแอปพลิเคชัน) ใช้สำหรับสร้าง virtual servers หรือ EC2 (Elastic Compute Cloud) instances ในระบบของ AWS
มีทั้ง Public AMI และ Private AMI ซึ่งแต่ละรายการมีตัวระบุเฉพาะ ในกรณีของ Public AMI ผู้ใช้สามารถค้นหา AMI ID ที่ต้องการผ่าน AWS Catalog ที่พวกเขาต้องการได้
เพื่อให้แน่ใจว่า AMI นั้นมาจากแหล่งที่เชื่อถือได้ใน AWS Marketplace การค้นหาควรรวมถึง 'owners' attribute มิฉะนั้นจะเพิ่มความเสี่ยงต่อการโจมตีแบบ whoAMI name confusion attack
การโจมตี whoAMI อาจเกิดขึ้นได้เนื่องจากการเลือก AMI ที่กำหนดค่าไม่ถูกต้องใน AWS environments :
- การดึงข้อมูล AMI ผ่าน API ec2:DescribeImages โดยไม่ระบุ owner
- การใช้ Wildcards แทนการระบุ AMI ID เฉพาะเจาะจง
- เครื่องมือ Infrastructure-as-Code เช่น Terraform ที่ใช้ most_recent=true ซึ่งจะส่งผลให้ระบบเลือก AMI ล่าสุดที่ตรงกับเงื่อนไขโดยอัตโนมัติ
เงื่อนไขเหล่านี้เปิดโอกาสให้ผู้โจมตีสามารถแทรก AMI ที่เป็นอันตรายในกระบวนการเลือกใช้งานได้ โดยตั้งชื่อ resource ให้คล้ายกับชื่อที่เชื่อถือได้ โดย AWS แสดงผล AMI ที่ตรงกันทั้งหมด รวมถึง AMI ของผู้โจมตีโดยไม่ระบุ owner
หากตั้งค่าพารามิเตอร์ "most_recent" เป็น "true" ระบบของเหยื่อจะจัดการค้นหา AMI ล่าสุดที่เพิ่มลงใน Market ซึ่งอาจรวมถึง AMI ที่เป็นอันตรายซึ่งมีชื่อคล้ายกับรายการที่ถูกต้อง
โดยพื้นฐานแล้ว สิ่งที่ผู้โจมตีต้องทำคือ publishes AMI ที่มีชื่อสอดคล้องกับรูปแบบที่มี owner ที่เชื่อถือได้ใช้ ทำให้ผู้ใช้งานสามารถเลือก และเปิดใช้งาน EC2 instance ได้ง่าย
การโจมตีแบบ whoAMI ไม่จำเป็นต้องเจาะเข้าสู่บัญชี AWS ของเป้าหมาย ผู้โจมตีเพียงแค่ต้องมีบัญชี AWS เพื่อ publishes AMI ที่มีการฝังช่องโหว่ของตนไปยัง Community AMI catalog แบบสาธารณะ และเลือกใช้ชื่อที่เลียนแบบ AMI ของเป้าหมายอย่างแนบเนียน
Datadog ระบุว่า ตามข้อมูล Telemetry ของพวกเขา ประมาณ 1% ขององค์กรที่บริษัทเฝ้าติดตามมีความเสี่ยงต่อการโจมตีแบบ whoAMI แต่ "ช่องโหว่นี้อาจส่งผลกระทบต่อบัญชี AWS หลายพันบัญชีที่แตกต่างกัน"
การตอบสนอง และมาตรการป้องกันของ Amazon
นักวิจัยจาก Datadog ได้แจ้ง Amazon เกี่ยวกับช่องโหว่นี้ และทางบริษัทฯ ได้ยืนยันว่าระบบภายในที่ไม่ใช่ระบบโปรดักชันอาจมีความเสี่ยงต่อการโจมตีแบบ whoAMI ลักษณะนี้
โดยช่องโหว่นี้ได้รับการแก้ไขไปแล้วเมื่อวันที่ 19 กันยายนปีที่แล้ว และในวันที่ 1 ธันวาคม AWS ได้เปิดตัวมาตรการรักษาความปลอดภัยใหม่ที่ชื่อว่า 'Allowed AMIs' ซึ่งช่วยให้ลูกค้าสามารถสร้างรายชื่อผู้ให้บริการ AMI ที่เชื่อถือได้
AWS ระบุว่า ช่องโหว่นี้ไม่ได้ถูกนำไปใช้ในการโจมตีจริงนอกเหนือจากการทดสอบของนักวิจัยด้านความปลอดภัย ดังนั้น ไม่มีข้อมูลของลูกค้าถูกละเมิดจากการโจมตีแบบ whoAMI
Amazon แนะนำให้ลูกค้าระบุ AMI owner เสมอเมื่อใช้ API "ec2:DescribeImages" และเปิดใช้งานคุณสมบัติ 'Allowed AMIs' เพื่อเพิ่มการป้องกันเพิ่มเติม
คุณสมบัติใหม่นี้สามารถเปิดใช้งานได้ผ่าน AWS Console → EC2 → Account Attributes → Allowed AMIs
ตั้งแต่เดือนพฤศจิกายนปีที่แล้ว Terraform 5.77 เริ่มแสดงคำเตือนแก่ผู้ใช้เมื่อมีการใช้ "most_recent = true" โดยไม่มีตัวกรอง owner และมีแผนจะบังคับใช้มาตรการที่เข้มงวดขึ้นในเวอร์ชันอนาคต (6.0)
ผู้ดูแลระบบต้องตรวจสอบการกำหนดค่า และอัปเดตโค้ดที่เกี่ยวข้องกับแหล่งที่มาของ AMI (Terraform, AWS CLI, Python Boto3 และ Go AWS SDK) เพื่อให้แน่ใจว่ามีการดึงข้อมูล AMI อย่างปลอดภัย
หากต้องการตรวจสอบว่า AMI ที่ไม่น่าเชื่อถือกำลังถูกใช้งานอยู่หรือไม่ สามารถเปิดใช้งาน AWS Audit Mode ผ่าน 'Allowed AMIs' และเปลี่ยนเป็น 'Enforcement Mode' เพื่อบล็อก AMI ที่ไม่น่าเชื่อถือ
DataDog ยังได้เปิดตัวเครื่องมือสแกนเพื่อตรวจสอบบัญชี AWS สำหรับอินสแตนซ์ที่สร้างจาก AMI ที่ไม่น่าเชื่อถือ ซึ่งสามารถเข้าถึงได้ใน GitHub repository
ที่มา : bleepingcomputer
You must be logged in to post a comment.