สรุปสั้น
นักวิจัยด้านความปลอดภัยเปิดเผยเทคนิคการโจมตีที่เก็บข้อมูลบนคลาวด์รูปแบบใหม่ที่ตั้งชื่อว่า “bucket hijacking” ซึ่งเป็นวิธีที่เปิดให้ผู้โจมตีสามารถเปลี่ยนเส้นทางสตรีมข้อมูลที่กำลังทำงานขององค์กร รวมถึง audit log และ telemetry ไปยัง storage bucket ที่ผู้โจมตีควบคุมจากภายนอกได้อย่างเงียบ ๆ บนแพลตฟอร์มคลาวด์รายใหญ่ โดยเทคนิคนี้ได้รับการยืนยันว่ากระทบทั้ง Google Cloud, Amazon Web Services (AWS) และ Microsoft Azure ซึ่งทั้งสามผู้ให้บริการได้รับแจ้งผ่านกระบวนการ responsible disclosure แล้ว แม้ปัจจุบันยังไม่มีการพบผู้โจมตีในโลกจริงใช้เทคนิคนี้ แต่นักวิจัยเตือนว่าเมื่อถูกนำไปใช้แล้วจะตรวจจับได้ยากมาก
การโจมตีอาศัยช่องโหว่เชิงสถาปัตยกรรมพื้นฐานที่ฝังรากอยู่ในความเป็นเอกลักษณ์ระดับโลกของชื่อ storage bucket เนื่องจากไม่มีผู้ใช้สองรายสามารถจดทะเบียนชื่อ bucket ที่เหมือนกันภายใน namespace ของผู้ให้บริการรายเดียวกันได้ ตัวตนของ bucket ปลายทางจึงผูกอยู่กับชื่อเพียงอย่างเดียว ไม่ได้ผูกกับเจ้าของบัญชีรายใดรายหนึ่ง ผู้โจมตีที่เจาะเข้าสภาพแวดล้อมคลาวด์และได้สิทธิ์ลบ bucket จึงสามารถลบ bucket ที่กำลังทำงานขององค์กรเป้าหมาย แล้วสร้าง bucket ใหม่ด้วยชื่อเดียวกันในบัญชีที่ตนควบคุมได้ทันที ทำให้สตรีมข้อมูลเดิมยังคงทำงานต่อไปและเริ่มเขียนข้อมูลตรงเข้าสู่ bucket ของผู้โจมตี
รายละเอียดข่าว
เว็บไซต์ Cyber Security News รายงานเมื่อวันที่ 27 มิถุนายน พ.ศ. 2569 ว่า ทีมนักวิจัยจาก Unit 42 ได้เปิดเผยเทคนิคการโจมตีคลาวด์ระดับวิกฤตชื่อ bucket hijacking ที่เปิดให้ผู้โจมตีเปลี่ยนเส้นทางสตรีมข้อมูลขององค์กรไปยังที่เก็บข้อมูลภายนอกที่ตนควบคุมได้อย่างเงียบ ๆ
สิ่งที่ทำให้การโจมตีนี้อันตรายเป็นพิเศษคือการที่มันสามารถดำรงตัวเองได้ (self-sustaining) เมื่อการ hijack เสร็จสมบูรณ์ การตั้งค่า sink หรือ replication เดิมจะยังคงปรากฏว่าถูกต้องเมื่อตรวจสอบ ไม่ก่อให้เกิดสถานะ error ที่ชัดเจน และไม่กระตุ้นการแจ้งเตือนใด ๆ ของระบบ ส่งผลให้ log, metric และ telemetry ที่อ่อนไหวไหลเข้าสู่สภาพแวดล้อมของผู้โจมตีอย่างต่อเนื่องไม่มีกำหนด
นาย Unit 42 ทดสอบจำลองการโจมตี bucket hijacking สำเร็จในหลายบริการบนผู้ให้บริการแต่ละราย โดยบน Google Cloud ยืนยันได้กับ Cloud Logging sink, Pub/Sub subscription ที่มีปลายทางเป็น Cloud Storage และ Storage Transfer Service job ซึ่งต้องการสิทธิ์ storage.buckets.delete และ storage.objects.delete ส่วนบน AWS ยืนยันได้กับ S3 bucket replication และ Amazon Data Firehose pipeline ที่ส่งไปยังปลายทาง S3 ขณะที่บน Azure สาธิตเป็นการโจมตีข้าม subscription ผ่าน Azure Monitor diagnostic setting แต่จำกัดอยู่ในขอบเขต tenant เดียวกันเนื่องจากแพลตฟอร์มบังคับให้มีดีเลย์ในการนำชื่อกลับมาใช้ใหม่
วิธีการโจมตี
ผู้โจมตีที่เจาะเข้าสภาพแวดล้อมคลาวด์และได้สิทธิ์ลบ bucket สามารถดำเนินการโจมตีตามลำดับที่ตรงไปตรงมา คือ ลบ storage bucket ที่กำลังทำงานขององค์กรเป้าหมาย จากนั้นสร้าง bucket ใหม่ด้วยชื่อที่เหมือนกันทุกประการในบัญชีที่ผู้โจมตีควบคุมทันที สตรีมข้อมูลเดิม ไม่ว่าจะเป็น Google Cloud logging sink, AWS S3 replication rule หรือ Azure Monitor diagnostic export จะยังคงทำงานต่อไปโดยอัตโนมัติและเริ่มเขียนข้อมูลตรงเข้าสู่ bucket ของผู้โจมตี
นักวิจัยเน้นว่าบทบาทการบริหารจัดการ storage แบบกว้างที่มักถูกมอบหมายในองค์กรยิ่งเพิ่มความเสี่ยงอย่างมาก ใน Google Cloud บทบาทมาตรฐาน Storage Admin จะให้สิทธิ์ storage.buckets.delete โดยค่าเริ่มต้น ซึ่งข้ามผ่านสิทธิ์ logging.sinks.update ที่เข้มงวดกว่าและจำเป็นสำหรับการปรับตั้งค่าสตรีมข้อมูลอย่างถูกต้อง ทำให้ผู้โจมตีสามารถเปลี่ยนเส้นทางสตรีมข้อมูลได้โดยไม่ต้องแตะการตั้งค่าสตรีมโดยตรงเลย นอกจากนี้ Unit 42 ยังเน้นว่าเทคนิคนี้ไม่ได้จำกัดอยู่แค่สามผู้ให้บริการที่ทดสอบ แพลตฟอร์มคลาวด์ใดก็ตามที่อาศัยทรัพยากร storage ที่มีชื่อตายตัวและไม่ซ้ำกันทั่วโลกในการกำหนดเส้นทางสตรีมข้อมูล ล้วนมีความเสี่ยงต่อวิธีการเดียวกัน สะท้อนว่าปรัชญาการออกแบบที่ใช้ร่วมกันข้ามผู้ให้บริการ ทำให้ข้อบกพร่องที่พบในระบบนิเวศหนึ่งกลายเป็นพิมพ์เขียวสำหรับโจมตีอีกระบบได้โดยตรง
ผลกระทบต่อไทย
องค์กรไทยที่ใช้บริการคลาวด์รายใหญ่ทั้ง AWS, Azure และ Google Cloud โดยเฉพาะธนาคาร ฟินเทค โทรคมนาคม และหน่วยงานรัฐที่ย้ายระบบขึ้นคลาวด์ ล้วนอยู่ในกลุ่มที่อาจได้รับผลกระทบหากผู้โจมตีนำเทคนิค bucket hijacking มาใช้ ความน่ากังวลคือเทคนิคนี้มุ่งเป้าไปที่ audit log และ telemetry ซึ่งเป็นข้อมูลที่ทีมความปลอดภัยใช้ตรวจจับเหตุการณ์ หากถูกเปลี่ยนเส้นทางไปยังผู้โจมตี องค์กรอาจสูญเสียทั้งข้อมูลอ่อนไหวและความสามารถในการมองเห็นเหตุการณ์ภายในระบบของตนเองพร้อมกัน อีกทั้งการโจมตียังตรวจจับได้ยากเพราะการตั้งค่าเดิมยังดูปกติ องค์กรไทยที่มอบบทบาท Storage Admin แบบกว้างให้ทีมงานจำนวนมากจึงควรทบทวนสิทธิ์อย่างเร่งด่วน
คำแนะนำ
Unit 42 แนะนำกลยุทธ์การป้องกันสองแนวทางควบคู่กัน คือการควบคุมการเข้าถึงแบบ least-privilege และการเฝ้าระวังเชิงรุก โดยควรจำกัดสิทธิ์การลบ bucket (storage.buckets.delete, DeleteBucket, Microsoft.Storage/storageAccounts/delete) ให้เหลือเฉพาะบทบาทผู้ดูแลที่จำเป็นที่สุด บังคับใช้การควบคุม data perimeter เช่น AWS Service Control Policies (SCPs) หรือ Google Cloud VPC Service Controls เพื่อบล็อกการเขียนข้อมูลไปยัง bucket ที่อยู่นอกขอบเขตองค์กรที่เชื่อถือได้ เปิดใช้ AWS account-regional S3 namespace เพื่อจำกัดชื่อ bucket ให้ผูกกับบัญชีและภูมิภาคที่เฉพาะเจาะจง ซึ่งจะกำจัดช่องทางการ hijack ได้โดยตรง และสุดท้ายควรตั้งการแจ้งเตือนระดับความสำคัญสูงสำหรับการเรียก API ลบ storage bucket โดยเฉพาะกับ bucket ที่เก็บข้อมูลอ่อนไหวหรือข้อมูลที่อยู่ภายใต้การกำกับดูแล