AWS เผยรากฐานคีย์ Root รั่วจาก GitHub ทำให้ระบบรักษาความปลอดภัยเผชิญความท้าทายใหม่

การตรวจพบรากฐานของคีย์ AWS Root ที่หลุดออกมาจาก GitHub สาธารณะและยังคงทำงานได้ ส่งผลให้ระบบรักษาความปลอดภัยของ AWS ต้องเผชิญกับความท้าทายใหม่ ทั้งในเรื่องการปกป้องข้อมูลลูกค้าและการไม่ทำลายสภาพแวดล้อมที่ใช้งานอยู่

Overview

AWS ยังคงเฝ้าระวังคีย์ที่อาจรั่วไหลโดยใช้ระบบตรวจจับอัตโนมัติ หากพบจะนำไปบังคับใช้ Quarantine Policy เพื่อลดความเสี่ยงจากการใช้คีย์เหล่านั้นต่อไป ตามรายงานของ BleepingComputer ที่อ้างอิงจากการวิจัยของ Truffle Security พบว่ามีร้อยๆ คีย์ระดับ Root ที่ยังคงทำงานอยู่แม้จะถูกตรวจพบแล้วก็ตาม

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

Key Details

หลายกรณีที่คีย์ระดับ Root รั่วไหลมักเกิดจากการใส่ข้อมูลลับลงใน public GitHub repositories ซึ่งเป็นความผิดพลาดทั่วไปของนักพัฒนา แม้ว่าจะมีแนวทางแนะนำให้ใช้ non‑ephemeral credentials derived from OIDC or SSO เพื่อป้องกัน แต่ก็ยังพบกรณีที่ผู้ใช้งานไม่ปฏิบัติตาม

เมื่อระบบตรวจจับของ AWS พบคีย์ที่รั่วไหล จะทำการใส่ Quarantine Policy ลงบนคีย์นั้นโดยอัตโนมัติ นโยบายนี้จะกำหนดรายการพฤติกรรมที่ห้ามทำในรูปแบบกราฟขยายตัวของ principal‑behaviour อย่างไรก็ตาม รายละเอียดของสิทธิ์ที่ยังคงเปิดอยู่หลังจากการบังคับใช้นโยบายไม่ได้ถูกเปิดเผยอย่างชัดเจน

นักวิจัยได้จำลองสถานการณ์โดยใช้คีย์ระดับ Root ที่ถูกกักกันแล้ว พบว่ามีหลายบริการที่ยังคงสามารถทำงานได้ เช่น การเรียก sts:AssumeRole เพื่อสวมบทบาทอื่นในบัญชี, การสร้างหรืออัปเดต Auto Scaling Group, และการเขียนข้อมูลลง S3 แม้ว่าจะมีบางคำสั่งที่ถูกปฏิเสธเช่น cloudtrail:LookupEvents

Policy Mechanics

นโยบายกักกันของ AWS พยายามจำกัดความเสียหายโดยกำหนดสิทธิ์ให้ “ไม่สามารถทำ” (deny) ต่อหลายการกระทำ แต่ไม่ได้ครอบคลุมทุกบริการอย่างสมบูรณ์ รายการที่ยังคงเปิดใช้งานได้รวมถึง

• sts:AssumeRole – สามารถสวมบทบาทอื่นในบัญชีและรับสิทธิ์ของมัน
• autoscaling:CreateAutoScalingGroup / UpdateAutoScalingGroup – สร้างหรืออัปเดตกลุ่ม Auto Scaling ผ่าน service‑linked role
• ssm:SendCommand / ssm:StartSession – รันคำสั่งบน EC2 ด้วยบทบาทของอินสแตนซ์นั้นเอง
• cloudtrail:StopLogging & DeleteTrail – ปิดการบันทึกและลบ Trail ทำให้ไม่มี audit log
• ses:SendEmail – ส่งอีเมลจำนวนมากโดยใช้ SES แม้บางฟังก์ชันถูกปฏิเสธ

ในขณะเดียวกัน คำสั่งที่ถูกห้ามเช่น s3:DeleteObject, cloudtrail:LookupEvents, และ ses:GetSendQuota ถูกระบุไว้ในนโยบาย อย่างไรก็ตาม การอนุญาตให้ทำกิจกรรมอื่น ๆ ที่อาจทำลายหรือทำให้ข้อมูลเสียหายได้อย่างกว้างขวาง ทำให้นโยบายดังกล่าวยังคงมีช่องโหว่สำคัญ

Security Implications

การที่คีย์ระดับ Root ยังคงทำงานได้แม้หลังจากถูกใส่นโยบายกักกัน แสดงให้เห็นว่าการจำกัด “damage” อย่างเดียวอาจไม่เพียงพอ หากผู้โจมตีสามารถใช้สิทธิ์ที่เหลืออยู่ เขาอาจทำการสร้างหรือแก้ไขทรัพยากรสำคัญได้ เช่น

• เติมข้อมูลลง S3 จนเต็มพื้นที่จัดเก็บ ทำให้ค่าใช้จ่ายบิลสูงขึ้นอย่างไม่จำเป็น
• เปิดใช้งาน Object Lock และตั้งค่า retention แบบ COMPLIANCE ที่ถึงปี 2126 ซึ่งไม่สามารถยกเลิกได้โดยผู้ดูแลระบบหรือแม้กระทั่ง AWS Support
• ดึงข้อมูลลับจาก Secrets Manager, SSM Parameter Store, หรือ KMS ทำให้ข้อมูลสำคัญรั่วไหลไปยังโจมตี

ผลกระทบเหล่านี้ไม่เพียงทำให้ลูกค้าต้องเผชิญกับความเสียหายด้านการเงินและข้อมูลเท่านั้น แต่ยังก่อให้เกิดปัญหาในการกู้คืนระบบ เนื่องจากบางการตั้งค่าถูกล็อกไว้โดยถาวร

Industry Response

AWS ยังคงอ้างว่า นโยบายของตนออกแบบมาเพื่อ “ไม่ทำลายสภาพแวดล้อมของลูกค้า” อย่างไรก็ตาม ผู้เชี่ยวชาญด้านความปลอดภัยหลายรายได้เรียกร้องให้ AWS ปรับปรุงการจัดการคีย์ที่รั่วไหลโดยเพิ่มขั้นตอน mandatory rotation และขยายรายการสิทธิ์ที่ต้องห้ามอย่างครอบคลุม

บางองค์กรเริ่มนำแนวทาง “Zero‑Trust” มาใช้ในการเข้าถึง AWS โดยจำกัดการใช้คีย์ระดับ Root อย่างเคร่งครัดและพึ่งพา IAM Roles for Service Accounts (IRSA) หรือการยืนยันตัวตนผ่าน OIDC แทนการใช้คีย์ถาวร นอกจากนี้ การตรวจสอบอัตโนมัติของโค้ดที่อัปโหลดไปยัง GitHub ด้วยเครื่องมือเช่น GitGuardian หรือ TruffleHog** กำลังได้รับความนิยมเพิ่มขึ้น

Impact on Customers

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

สำหรับองค์กรขนาดใหญ่ที่มีหลายพัน EC2 instances, RDS databases, และ S3 buckets ความเสี่ยงจากการถูกโจมตีโดยใช้คีย์ Root ที่ยังทำงานอยู่อาจนำไปสู่การสูญเสียข้อมูลสำคัญและค่าใช้จ่ายที่ไม่คาดคิด นอกจากนี้ การลบหรือปิดใช้งาน audit log ของ CloudTrail ทำให้การสืบสวนเหตุการณ์เป็นเรื่องยากมากขึ้น

Summary

AWS ได้เปิดตัว Quarantine Policy เพื่อจัดการกับคีย์ที่รั่วไหล แต่การออกแบบนโยบายอาจยังไม่ครอบคลุมทุกความเสี่ยงและอาจทำให้ระบบของลูกค้าล่มได้ การปรับเปลี่ยนนโยบายรวมถึงการบังคับใช้การหมุนเวียนคีย์อย่างสม่ำเสมอจะเป็นขั้นตอนสำคัญต่อไปเพื่อปกป้องทรัพยากรบนคลาวด์.