Qubole Supply Chain Attack กระทบองค์กรกว่า 10 แห่ง

นักวิจัยด้านความปลอดภัยทางไซเบอร์ตรวจพบการโจมตีโดยผู้ไม่หวังดีที่ใช้ IAM credentials ของบัญชี AWS ที่เกี่ยวข้องกับ Qubole แพลตฟอร์มบริหารจัดการ big-data ที่ถูกเจาะเข้าถึง เพื่อขโมยข้อมูลจากองค์กรต่างๆ กว่า 10 แห่ง

ข้อมูลประจำตัว (credentials) เหล่านี้ช่วยให้ผู้โจมตีสามารถสวมสิทธิ์ (assume) IAM roles ที่องค์กรลูกค้าตั้งค่าไว้สำหรับบัญชี AWS ของ Qubole ทำให้สามารถเข้าถึงสภาพแวดล้อมระบบ AWS ของเหยื่อได้โดยตรง โดยปกติแล้ว Cross-account IAM roles เป็นกลไกมาตรฐานสำหรับแพลตฟอร์ม SaaS บน AWS ซึ่งในขั้นตอน onboarding ลูกค้าจะสร้าง role ให้ Qubole และระบุ External ID เพื่อให้ผู้ให้บริการสวมสิทธิ์เข้ามาทำงานได้ แต่ credentials ที่รั่วไหลครั้งนี้กลายเป็นช่องทางให้แฮกเกอร์ใช้สวมสิทธิ์แทน

บริษัทด้านความปลอดภัย Sentra notes ระบุว่า ช่องทางที่ผู้โจมตีใช้นั้นเปรียบเสมือน "ประตูเก่า" เนื่องจาก roles ของ Qubole ยังคงค้างอยู่ในระบบแม้ลูกค้าจะเลิกใช้งานไปนานแล้ว ซึ่งสิทธิ์เหล่านั้นสามารถเข้าถึงข้อมูลสำคัญที่ผู้โจมตีต้องการได้เกือบทั้งหมด

แคมเปญการโจมตีนี้เริ่มตั้งแต่วันที่ 14 ตุลาคม ถึง 26 ตุลาคม โดยผู้ไม่หวังดีใช้เพื่อตรวจสอบทรัพยากร (enumerate resources) รวบรวมข้อมูลความลับ การตั้งค่าต่างๆ รวมถึงการเข้าถึงข้อมูลดิบ Sentra พบว่าการโจมตีมาจากเซิร์ฟเวอร์ของ OVH และ Mullvad VPN โดยไม่พบความเคลื่อนไหวจากเครือข่ายของ Qubole เอง

ด้าน Wiz ซึ่งร่วมวิเคราะห์แคมเปญนี้ระบุว่า ผู้โจมตีใช้ชื่อ role session ในรูปแบบที่ชัดเจนคือ quiam- ตามด้วยคำอธิบายกิจกรรม เช่น quiam-enum และ quiam-scope-full หลังจากตรวจสอบทรัพยากรแล้ว แฮกเกอร์จะเก็บเกี่ยวความลับจากจุดเก็บข้อมูล AWS และใช้ TruffleHog เพื่อทดสอบ credentials ก่อนจะขโมยข้อมูลออกจาก S3 buckets

Wiz says เพิ่มเติมว่าพฤติกรรมของผู้ไม่หวังดีเน้นการฉวยโอกาสมากกว่าการเจาะจงเป้าหมาย โดยจะอ่านข้อมูลจากทุก bucket ที่สิทธิ์ของ role นั้นเข้าถึงได้ และในบางกรณีมีการดาวน์โหลดข้อมูลไปทั้ง bucket ภายใน session เดียว

นอกจากนี้ยังมีการตรวจพบไฟล์ ISO ที่ออกแบบมาเพื่อบูตจากระยะไกลบนเครื่องของเหยื่อเพื่อเก็บข้อมูล แต่ยังไม่พบหลักฐานการใช้งานจริงในขณะนี้ ขณะที่ Wiz ยังพบอีกหนึ่งแคมเปญในช่วงวันที่ 8-11 ตุลาคม ที่มีการนำ AWS access keys ของลูกค้าไปทดสอบกับสภาพแวดล้อมของเหยื่อเพื่อใช้ในการเจาะระบบต่อไป

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