Cloudflare แก้ไขช่องโหว่ Cross-Tenant Data Exposure ระดับวิกฤตในบริการ Cloudflare Containers และ Cloudflare Sandboxes ซึ่งเกิดจากการตั้งค่า skip_block_zeroing บนระบบ Linux dm-thin ทำให้ Storage Block ที่ถูกนำกลับมาใช้งานใหม่อาจยังมีข้อมูลตกค้างจากลูกค้ารายก่อนหน้า ส่งผลให้ Workload อื่นที่ใช้งานอยู่บน Physical Host เดียวกันมีโอกาสอ่านข้อมูลบางส่วนของลูกค้ารายอื่นได้ นักวิจัย Oren Yomtov จาก Accomplish เป็นผู้รายงานช่องโหว่นี้ผ่านโปรแกรม HackerOne ของ Cloudflare เมื่อวันที่ 4 กันยายน 2569
รายละเอียดการโจมตี
สาเหตุของช่องโหว่: การตั้งค่า skip_block_zeroing บน dm-thin
ช่องโหว่นี้ไม่ได้เกิดจากการ Escape ออกจาก Container ตามที่มักพบในช่องโหว่ลักษณะนี้ทั่วไป แต่เกิดขึ้นที่ระดับ Storage Layer โดยสถาปัตยกรรมของ Cloudflare ใช้ Firecracker MicroVM ที่มี Writable Root Disk แสดงเป็น /dev/vdc ซึ่งพึ่งพาระบบ Linux Device Mapper Thin Provisioning (dm-thin) ในการจัดสรร Storage เป็นบล็อกขนาด 64 KiB จุดที่เป็นปัญหาคือ Shared Storage Pool ที่ได้รับผลกระทบมีการเปิดใช้งาน skip_block_zeroing ซึ่งหมายความว่าเมื่อ Container Disk ถูกลบ Physical Block จะถูกส่งกลับไปยัง Pool ที่ใช้ร่วมกันระหว่างหลายบัญชีลูกค้าโดยไม่มีการล้างข้อมูลก่อน ทำให้ Block ที่ถูกจัดสรรใหม่ยังคงมีข้อมูลจากเจ้าของเดิมหลงเหลืออยู่จนกว่าจะถูกเขียนทับ
เทคนิคการใช้ประโยชน์จากช่องโหว่
นักวิจัยสาธิตวิธีการใช้ประโยชน์จากช่องโหว่นี้ด้วยการค้นหาพื้นที่ว่างที่มีการจัดวางตำแหน่งตรงกับขนาด 64 KiB บน Ext4 Filesystem จากนั้นเขียนข้อมูลเพียง 4 KiB ลงในพื้นที่ดังกล่าว เพื่อบังคับให้ dm-thin จัดสรร Block ขนาด 64 KiB ที่นำกลับมาใช้ใหม่ ก่อนอ่านข้อมูลทั้ง Block เพื่อดึงข้อมูลตกค้างอีก 60 KiB ที่ไม่ได้ถูกเขียนทับออกมา จากการทดสอบใน 6 Production Placement นักวิจัยตรวจสอบ Directory Block ที่ทดสอบได้ทั้งหมด 5,614 รายการ และพบ Foreign Directory Inode ที่แตกต่างกันถึง 2,700 รายการ ซึ่งรวมถึงโครงสร้าง Directory, หน้า Database และไฟล์ SQLite Database ที่สมบูรณ์
ข้อกำหนดสำหรับการใช้ประโยชน์และผลกระทบจริง
การใช้ประโยชน์จากช่องโหว่นี้จำเป็นต้องมีบัญชี Workers Paid ก่อน และมีลักษณะเป็นการโจมตีแบบฉวยโอกาส (Opportunistic) มากกว่าการโจมตีแบบมีเป้าหมายเฉพาะเจาะจง เนื่องจากผลลัพธ์ขึ้นอยู่กับรูปแบบการจัดตารางเวลาและการจัดสรร Block ใหม่ ทำให้ผู้โจมตีไม่สามารถเลือกเหยื่อหรือข้อมูลที่ต้องการได้อย่างเฉพาะเจาะจง ทั้งนี้ Cloudflare ยืนยันว่าจากการตรวจสอบ Telemetry ที่เก็บไว้ ไม่พบหลักฐานการโจมตีจริงหรือข้อมูลลูกค้าถูกขโมยแต่อย่างใด โดยกิจกรรมที่ตรวจพบมาจากนักวิจัยที่ได้รับอนุญาตและวิศวกรของ Cloudflave ที่ทำการทดสอบยืนยันเท่านั้น
การแก้ไขของ Cloudflare
Cloudflare ดำเนินการแก้ไขทันทีด้วยการยกเลิกการตั้งค่า skip_block_zeroing ทั่วทั้ง Containers Fleet เพื่อคืนค่าพฤติกรรมการล้าง Block เริ่มต้นของ dm-thin พร้อมทั้งดำเนินการ Sanitization อย่างสมบูรณ์ด้วยการยกเลิก Container Disk ที่มีอยู่ ระบาย Host และรีสตาร์ท Virtual Machine รวมถึงล้าง Image Cache ทั้งหมด นอกจากนี้ยังพัฒนา Signature สำหรับตรวจจับรูปแบบ Disk I/O ที่มีลักษณะเฉพาะของการโจมตีนี้ คือการเขียนข้อมูลขนาดเล็ก 4 KiB ตามด้วยการอ่านข้อมูลขนาดใหญ่กว่ามากจาก Block ที่จัดสรรใหม่ และได้รับการยืนยันจากนักวิจัยอิสระว่า Proof-of-Concept ของพวกเขาไม่สามารถใช้งานได้อีกต่อไปหลังการแก้ไข
ผลกระทบที่อาจเกิดขึ้น
1. การข้ามขอบเขต Tenant Isolation ในโครงสร้างพื้นฐาน Cloud ที่ใช้ร่วมกัน
แม้จะไม่พบหลักฐานการโจมตีจริง แต่ช่องโหว่นี้แสดงให้เห็นว่าขอบเขตการแยก Tenant (Tenant Isolation Boundary) ที่ควรเป็นรากฐานสำคัญของโครงสร้างพื้นฐาน Cloud แบบ Multi-Tenant สามารถถูกข้ามได้ในระดับ Storage Layer ซึ่งเป็นจุดที่มักไม่ถูกให้ความสำคัญเท่ากับการป้องกันการ Escape จาก Container โดยตรง
2. ความเสี่ยงต่อข้อมูลที่มีความอ่อนไหวสูงอย่าง Database และไฟล์ระบบ
จากการทดสอบพบว่าข้อมูลตกค้างที่ดึงออกมาได้รวมถึงหน้า Database และไฟล์ SQLite Database ที่สมบูรณ์ ซึ่งอาจมีข้อมูลที่มีความอ่อนไหวสูงของลูกค้ารายอื่น หากช่องโหว่นี้ถูกใช้ประโยชน์โดยผู้ไม่ประสงค์ดีจริงก่อนที่จะได้รับการแก้ไข
3. ลักษณะการโจมตีแบบฉวยโอกาสที่ยากต่อการควบคุมเป้าหมาย
แม้ผู้โจมตีจะไม่สามารถเลือกเหยื่อหรือข้อมูลที่ต้องการได้อย่างเฉพาะเจาะจง แต่ลักษณะการโจมตีแบบฉวยโอกาสนี้หมายความว่าลูกค้ารายใดก็ตามที่ใช้งานบริการ Containers หรือ Sandboxes บน Physical Host ที่มีการนำ Block กลับมาใช้ใหม่ มีความเสี่ยงที่จะได้รับผลกระทบโดยไม่สามารถคาดการณ์ล่วงหน้าได้
4. ผลกระทบต่อความเชื่อมั่นในบริการ Cloud แบบ Multi-Tenant โดยรวม
เหตุการณ์นี้อาจส่งผลต่อความเชื่อมั่นขององค์กรที่ใช้งานบริการ Cloud แบบ Multi-Tenant โดยเฉพาะบริการที่เกี่ยวข้องกับ Container และ Sandbox ซึ่งมักถูกมองว่ามีการแยก Isolation ที่รัดกุมกว่าบริการ Cloud ทั่วไป
สิ่งที่องค์กรควรทำ
1. ตรวจสอบว่าองค์กรใช้งาน Cloudflare Containers หรือ Sandboxes หรือไม่
องค์กรที่ใช้งาน Cloudflare Containers หรือ Cloudflare Sandboxes ควรตรวจสอบว่าตนเองได้รับผลกระทบจากช่องโหว่นี้หรือไม่ แม้ Cloudflare จะยืนยันว่าการแก้ไขทั่วทั้ง Fleet ไม่ต้องการการเปลี่ยนแปลงการตั้งค่าใดๆ จากฝั่งลูกค้าก็ตาม
2. ประเมินความจำเป็นในการหมุนเวียน Secret ที่เคยประมวลผลบน Workload ที่ได้รับผลกระทบ
องค์กรควรประเมินตามนโยบายความเสี่ยงของตนเองว่ามีความจำเป็นต้องหมุนเวียน (Rotate) Secret หรือข้อมูลสำคัญที่เคยถูกประมวลผลบน Workload ที่อาจอยู่ในขอบเขตของช่องโหว่นี้หรือไม่ แม้ Cloudflare จะไม่พบหลักฐานการถูกขโมยข้อมูลก็ตาม
3. ติดตามประกาศและรายละเอียดเพิ่มเติมจาก Cloudflare
องค์กรควรติดตามประกาศและรายละเอียดเพิ่มเติมที่ Cloudflare อาจเผยแพร่เกี่ยวกับเหตุการณ์นี้ รวมถึงมาตรการป้องกันเพิ่มเติมที่อาจถูกนำมาใช้ในอนาคตสำหรับบริการ Multi-Tenant อื่นๆ
4. ทบทวนความเข้าใจเรื่อง Shared Responsibility Model กับผู้ให้บริการ Cloud
องค์กรควรใช้โอกาสนี้ทบทวนความเข้าใจเกี่ยวกับ Shared Responsibility Model กับผู้ให้บริการ Cloud ของตนเอง โดยเฉพาะในประเด็นการแยก Isolation ระดับ Storage ซึ่งเป็นความรับผิดชอบของผู้ให้บริการ แต่องค์กรควรมีความเข้าใจในความเสี่ยงที่อาจเกิดขึ้นได้
แนวทางลดความเสี่ยงระยะยาว
1. เลือกผู้ให้บริการ Cloud ที่มีกระบวนการเปิดเผยช่องโหว่และแก้ไขที่โปร่งใส
องค์กรควรพิจารณาความโปร่งใสของผู้ให้บริการ Cloud ในการเปิดเผยช่องโหว่และกระบวนการแก้ไข เป็นหนึ่งในปัจจัยการประเมิน โดยกรณีนี้ Cloudflare แสดงให้เห็นกระบวนการตอบสนองที่รวดเร็วและมีการเปิดเผยรายละเอียดทางเทคนิคอย่างครบถ้วนต่อสาธารณะ
2. สนับสนุนโปรแกรม Responsible Disclosure และ Bug Bounty
เหตุการณ์นี้เป็นตัวอย่างที่ดีของประโยชน์จากโปรแกรม Bug Bounty ที่ช่วยให้ช่องโหว่ร้ายแรงถูกค้นพบและแก้ไขก่อนที่จะถูกผู้ไม่ประสงค์ดีนำไปใช้ประโยชน์จริง องค์กรที่พัฒนาซอฟต์แวร์หรือให้บริการ Cloud ควรสนับสนุนและลงทุนในโปรแกรมลักษณะนี้อย่างต่อเนื่อง
3. ทบทวนการตั้งค่า Storage Layer ในโครงสร้างพื้นฐาน Multi-Tenant ของตนเอง
องค์กรที่ดำเนินการโครงสร้างพื้นฐาน Multi-Tenant ของตนเอง ไม่ว่าจะเป็น Private Cloud หรือ On-Premise ควรทบทวนการตั้งค่า Storage Layer ที่คล้ายคลึงกัน เช่น การตั้งค่า Block Zeroing บนระบบ Storage ที่ใช้ Thin Provisioning เพื่อป้องกันปัญหาลักษณะเดียวกัน
4. เพิ่มการตรวจสอบ Tenant Isolation ในการประเมินความปลอดภัยของบริการ Cloud
องค์กรที่ใช้งานบริการ Cloud แบบ Multi-Tenant ควรรวมการประเมิน Tenant Isolation เป็นส่วนหนึ่งของกระบวนการประเมินความปลอดภัยผู้ให้บริการ ไม่ใช่เพียงพิจารณาจากชื่อเสียงหรือการรับรองมาตรฐานทั่วไปเท่านั้น
วิเคราะห์ในมุมมองจาก TXEC
เหตุการณ์นี้เป็นตัวอย่างที่สำคัญของความเสี่ยงที่มักถูกมองข้ามในบริการ Cloud แบบ Multi-Tenant นั่นคือช่องโหว่ที่เกิดขึ้นในระดับ Storage Layer ซึ่งแตกต่างจากช่องโหว่ประเภท Container Escape ที่มักได้รับความสนใจมากกว่า สิ่งที่ TXEC เห็นว่าน่าสนใจเป็นพิเศษคือความเรียบง่ายของเทคนิคการใช้ประโยชน์ ที่เพียงแค่เขียนข้อมูลขนาดเล็กแล้วอ่าน Block ทั้งหมดกลับมา ก็สามารถดึงข้อมูลตกค้างของลูกค้ารายอื่นออกมาได้ โดยไม่จำเป็นต้องอาศัยเทคนิคการโจมตีที่ซับซ้อนแต่อย่างใด
แม้ Cloudflare จะยืนยันว่าไม่พบหลักฐานการโจมตีจริงและตอบสนองต่อช่องโหว่นี้อย่างรวดเร็วและโปร่งใส แต่เหตุการณ์นี้ควรเป็นเครื่องเตือนใจให้องค์กรที่ใช้งานบริการ Cloud แบบ Multi-Tenant ไม่ว่าจะเป็น Container, Sandbox หรือบริการลักษณะอื่น ตระหนักว่าขอบเขตการแยก Tenant ไม่ได้ปลอดภัยอย่างสมบูรณ์เสมอไป และควรมีกระบวนการประเมินความเสี่ยงที่ครอบคลุมทุกระดับของ Stack รวมถึง Storage Layer ที่มักถูกมองข้าม รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: Cyber Security News, Cloudflare ]