رفع آسیب‌پذیری افشای داده‌ها در کانتینرهای کلودفلر

در تاریخ ۴ سپتامبر ۲۰۲۶، اورن یومتوف (Oren Yomtov)، محقق امنیتی شرکت آکامپلیش (Accomplish)، یک آسیب‌پذیری را که بر کانتینرهای کلودفلر (Cloudflare Containers) و سندباکس‌های کلودفلر (Cloudflare Sandboxes) (ساخته شده روی کانتینرها) تأثیر می‌گذارد، از طریق برنامه باگ‌بانتی کلودفلر (bug bounty program) به صورت مسئولانه گزارش کرد. کلودفلر این آسیب‌پذیری را به طور کامل برطرف کرده است و هیچ مدرکی مبنی بر به خطر افتادن داده‌های مشتریان وجود ندارد.

این مقاله با همکاری اورن یومتوف و تیم تحقیقات امنیتی آکامپلیش تهیه شده است که گزارش دقیق و آزمایش‌های کنترل‌شده آن‌ها به ما کمک کرد تا مسئله را تأیید کرده و به سرعت پاسخ دهیم.

کانتینرهای کلودفلر (Cloudflare Containers) بارهای کاری را روی زیرساخت‌های چندمشتری (multi-tenant) اجرا می‌کنند و به طور خودکار آن‌ها را به سرورهای واجد شرایط اختصاص می‌دهند؛ مشتریان نمی‌توانند میزبان زیرین را انتخاب کنند. محققان نشان دادند که یک مشتری دارای حساب Workers Paid می‌تواند بلوک‌های دیسک باقیمانده‌ای را که قبلاً توسط کانتینرها روی همان میزبان استفاده شده بود، بازیابی کند. این تکنیک نمی‌تواند مشتری، بار کاری، میزبان یا داده خاصی را هدف قرار دهد و تضمینی وجود نداشت که داده‌های باقیمانده حضور داشته باشند.

کلودفلر اصلاحیه‌ای را در سراسر ناوگان کانتینرها اعمال کرد و نیازی به تغییرات پیکربندی از سوی مشتری نبود. در تله‌متری تاریخی I/O دیسک که در دسترس ما بود، هیچ مدرکی مبنی بر بهره‌برداری مخرب پیدا نکردیم. فعالیتی که توانستیم به تکنیک گزارش‌شده نسبت دهیم، از سوی محققان و مهندسین کلودفلر (Cloudflare) بود که اعتبارسنجی مجاز را انجام می‌دادند.

در اینجا، رفتار ذخیره‌سازی زیرین، تأثیر بالقوه آن، بررسی خود و اقداماتی را که در واکنش به آن انجام دادیم، توضیح می‌دهیم.

نحوه عملکرد تخصیص ذخیره‌سازی کانتینر

کانتینرهای کلودفلر (Cloudflare Containers) از سیستم نگاشت نازک دیوایس مپر لینوکس (dm-thin) برای ارائه یک دیسک ریشه قابل نوشتن به هر کانتینر استفاده می‌کنند. هر کانتینر در یک ماشین مجازی اختصاصی که توسط مانیتور ماشین مجازی فایرکراکر (Firecracker) پشتیبانی می‌شود، زندگی می‌کند. فایرکراکر این دیسک را به عنوان /dev/vdc به ماشین مجازی ارائه می‌دهد.

تخصیص نازک (Thin provisioning) فضای ذخیره‌سازی فیزیکی را تنها زمانی تخصیص می‌دهد که یک دیسک مجازی در یک ناحیه نگاشت‌نشده قبلی بنویسد. استخرهای ذخیره‌سازی آسیب‌دیده از اندازه بلوک نازک ۶۴ کیلوبایتی استفاده می‌کردند. هنگامی که حجم نازک پشتیبان دیسک ریشه یک کانتینر حذف شد، بلوک‌های فیزیکی آن به استخری بازگردانده شدند که به بارهای کاری متعلق به چندین حساب کاربری مشتری خدمت می‌کرد.

پیکربندی استخر آسیب‌دیده شامل گزینه زیر بود:

skip_block_zeroing

با پیکربندی این گزینه، dm-thin از صفر کردن بلوک‌های تازه تخصیص‌یافته قبل از قابل دسترس کردن آن‌ها صرف‌نظر می‌کند. در نتیجه، هنگامی که یک بلوک ۶۴ کیلوبایتی که قبلاً استفاده شده بود دوباره اختصاص داده شد، یک نوشتن تمام بلوک جایگزین محتویات قبلی خود شد، اما یک نوشتن کوچک‌تر تنها بخش نوشته‌شده را تغییر داد. بقیه می‌توانستند داده‌ها را از مالک قبلی بلوک حفظ کنند.

نحوه کارکرد اکسپلویت

خواندن یک ناحیه نگاشت‌نشده از یک دیسک نازک جدید، داده‌های باقیمانده را آشکار نکرد. برای یک ناحیه نگاشت‌نشده از دستگاه نازک، dm-thin صفرها را بدون تخصیص یک بلوک فیزیکی برمی‌گرداند.

اثبات مفهومی (Proof of concept) نواحی منطبق بر ۶۴ کیلوبایت مربوط به فضای خالی در سیستم فایل ext4 مهمان را شناسایی کرد و یک بلوک ۴ کیلوبایتی هم‌راستا را در هر ناحیه نوشت.

هنگامی که چنین نوشتن به یک بلوک نازک نگاشت‌نشده رسید، dm-thin یک بلوک فیزیکی ۶۴ کیلوبایتی را از استخر مشترک تخصیص داد. نوشتن ۴ کیلوبایتی تنها آن بخش از بلوک را جایگزین کرد و به دلیل غیرفعال بودن صفر کردن بلوک، ۶۰ کیلوبایت باقی‌مانده می‌تواند داده‌های یک کانتینر قبلی را حفظ کند.

بنابراین، خواندن بعدی دستگاه خام می‌تواند بایت‌هایی را مشاهده کند که کانتینر جدید هرگز ننوشته بود.

اثبات مفهوم مراحل زیر را انجام داد:

1. یک کانتینر با استفاده از حساب Workers Paid ایجاد کنید.
2. دیسک ریشه قابل نوشتن را در /dev/vdc باز کنید.
3. دیسک را بخوانید و یک خط پایه ثبت کنید.
4. یک بلوک ۴ کیلوبایتی را در هر ناحیه ۶۴ کیلوبایتی انتخاب‌شده مربوط به فضای خالی ext4 بنویسید.
5. بلوک‌های حاصل را دوباره بخوانید.
6. فقط بخش‌هایی را که توسط کانتینر جدید بازنویسی نشده‌اند بررسی کنید.

ارسال شامل تعداد، افست‌های بلوک، اندازه‌ها، نتایج چک‌سام و پیشوندهای هش ناقص بود. اگرچه محققان بلوک‌های خام را برای تأیید مسئله بازیابی کردند، اما مطالب ارائه‌شده به کلودفلر (Cloudflare) شامل هیچ‌گونه نام فایل شخص ثالث، شناسه‌ها، اعتبارنامه‌ها، نام‌های میزبان، آدرس‌ها یا مقادیر محتوای بازیابی‌شده نبود. همان‌طور که در زیر شرح داده شده است، محققان همچنین تأیید کرده‌اند که داده‌های بازیابی‌شده را به صورت امن حذف کرده‌اند.

نحوه اعتبارسنجی آسیب‌پذیری

محققان از چک‌سام‌های بلوک دایرکتوری ext4 برای تمایز دادن بلوک‌های متعلق به سیستم فایل آزمایشی خود ایجاد شده برای اثبات مفهوم از بلوک‌های نشأت گرفته از سیستم فایل‌های دیگر استفاده کردند.

هنگامی که ext4 از ویژگی metadata_csum استفاده می‌کند، چک‌سام‌های بلوک دایرکتوری مقادیر مرتبط با سیستم فایل و inode را ترکیب می‌کنند.

در سراسر شش استقرار تولید، محققان گزارش دادند:

• تمام ۵۶۱۴ بلوک دایرکتوری قابل آزمایش.
• صفر از آن بلوک‌ها به سیستم فایل محققان نسبت داده شد.
• ۲۷۰۰ inode دایرکتوری خارجی متمایز شناسایی شده از طریق تجزیه و تحلیل چک‌سام.

برای اعتبارسنجی روش، محققان آن را در برابر بلوک‌هایی که عمداً در سیستم فایل آزمایشی کنترل‌شده استفاده شده برای اثبات مفهوم ایجاد و حذف کرده بودند، آزمایش کردند. این روش تمام ۱۶۲ بلوک را به درست به آن سیستم فایل نسبت داد.

محققان در نهایت مطالب باقیمانده را در ۱۸ مورد از ۲۴ استقرار و ۲۰ مورد از ۲۲ گره زیرین در چهار قاره مشاهده کردند. انواع بلوک‌های بازیابی‌شده شامل ساختارهای دایرکتوری، صفحات پایگاه داده و پایگاه‌های داده SQLite کامل از نظر ساختاری بود. محققان گزارش دادند که از اسکریپت‌هایی استفاده کرده‌اند که فقط تعداد کل و بررسی‌های قالب را خروجی می‌دهند، نه محتوای فایل بازیابی‌شده. مطالب ارسال‌شده به کلودفلر (Cloudflare) شامل هیچ مقدار محتوای بازیابی‌شده یا شناسه‌های شخص ثالث نبود. محققان متعاقباً تأیید کردند که داده‌های بازیابی‌شده تحت کنترل آن‌ها محرمانه باقی مانده و پس از ارسال، مطابق با خط‌مشی افشای HackerOne کلودفلر، به طور ایمن حذف شده است.

تأثیر

این آسیب‌پذیری به‌طور بالقوه به مشتری دارای حساب Workers Paid اجازه می‌دهد تا داده‌های باقیمانده را از بلوک‌های ذخیره‌سازی که قبلاً توسط کانتینرهای سایر مشتریان روی همان میزبان زیرین استفاده شده بود، بازیابی کند.

یک بهره‌برداری موفقیت‌آمیز از مرز جداسازی مشتری عبور می‌کرد و می‌تواند ابرداده‌های سیستم فایل، ساختارهای دایرکتوری، صفحات پایگاه داده و داده‌های برنامه را فاش کند.

با این حال، یک مهاجم نمی‌تواند یک قربانی خاص را انتخاب کند یا به یک دیسک فعال متصل دسترسی داشته باشد. قرار گرفتن در معرض به قرار دادن بار کاری کلودفلر و اینکه کدام بلوک‌های آزاد شده قبلی توسط dm-thin مجدداً اختصاص داده شده‌اند، بستگی دارد. علاوه بر این، محققان تغییر داده‌های فعال مشتری دیگر یا تأثیر بر در دسترس بودن بار کاری را نشان ندادند.

چگونه آسیب‌پذیری را کاهش دادیم

اولین کاهش ما حذف skip_block_zeroing از پیکربندی استخر dm-thin در سراسر ناوگان بود. این امر رفتار پیش‌فرض dm-thin را برای پاک کردن بلوک‌های تازه تخصیص‌یافته قبل از قرار دادن آن‌ها در معرض یک کانتینر بازگرداند. این کار تکنیک گزارش‌شده را متوقف کرد که در آن یک نوشتن کوچک باعث تخصیص و خواندن بزرگ‌تر داده‌های باقیمانده از بقیه بلوک شد. محققان به طور مستقل تأیید کردند که اثبات مفهوم آن‌ها پس از این تغییر دیگر کار نمی‌کند.

صفر کردن تخصیص‌های جدید، بلوک‌های از قبل نگاشت‌شده در دستگاه‌های نازک موجود را ضدعفونی نکرد. این نگاشت‌ها در دیسک‌های کانتینر در حال اجرا و در کش هر میزبان از اسنپ‌شات‌های dm-thin آماده‌شده برای لایه‌های تصویر OCI وجود داشتند. یک کانتینر جدید می‌تواند نگاشت‌ها را از یک لایه کش‌شده بدون تخصیص مجدد آن بلوک‌ها به ارث ببرد و به بایت‌های باقیمانده در نواحی استفاده‌نشده، از جمله فضای خالی ext4، اجازه دهد از طریق خواندن خام /dev/vdc قابل خواندن باقی بمانند.

بنابراین ما همچنین تمام دیسک‌های کانتینر در حال اجرا را بازنشسته کردیم و اسنپ‌شات‌های تصویر کش‌شده ایجاد شده قبل از کاهش را حذف کردیم. ما میزبان‌ها را در ساعات کم‌مصرف تخلیه کردیم، ماشین‌های مجازی را روی هر میزبان راه‌اندازی مجدد کردیم و کش تصویر هر میزبان را پاک کردیم تا دیسک‌ها و لایه‌های کش‌شده با استفاده از تخصیص‌های صفر شده دوباره ایجاد شوند. ما این پاکسازی را در سراسر ناوگان کانتینرها به اتمام رساندیم.

هیچ مدرکی دال بر بهره‌برداری وجود ندارد

به عنوان بخشی از پاسخ خود، بررسی کردیم که آیا بارهای کاری دیگر فعالیتی مطابق با تکنیک بهره‌برداری گزارش‌شده نشان می‌دهند یا خیر. ما تله‌متری تاریخی I/O دیسک حفظ‌شده خود را از زیرساخت کانتینر خود بررسی کردیم و از اثبات مفهوم محققان و باز تولید داخلی خود به عنوان فعالیت مرجع استفاده کردیم.

اثبات مفهوم رابطه مشخصی بین نوشتن و خواندن ایجاد کرد. هنگامی که یک نوشتن ۴ کیلوبایتی به یک ناحیه نگاشت‌نشده قبلی رسید، می‌تواند باعث تخصیص یک بلوک ذخیره‌سازی ۶۴ کیلوبایتی استفاده مجدد شود. با غیرفعال بودن صفر کردن، ۶۰ کیلوبایت باقی‌مانده می‌تواند داده‌های یک کانتینر قبلی را حفظ کند. خواندن‌های بعدی بنابراین می‌توانند داده‌های بسیار بیشتری را نسبت به آنچه کانتینر جدید بازنویسی کرده بود، بازیابی کنند.

با استفاده از این ویژگی‌ها، امشاهای شناسایی را توسعه دادیم و آن‌ها را روی تله‌متری تاریخی موجود در دسترس خود اعمال کردیم. ما فعالیت قابل انتساب به محققان و مهندسین کلودفلر (Cloudflare) را که اعتبار سنجی مجاز را انجام می‌دادند شناسایی کردیم و فعالیت دیگری مطابق با تکنیک گزارش‌شده شناسایی نکردیم.

ما هیچ مدرکی ندیدیم که این بردار حمله خاص توسط شخص دیگری مورد سوءاستفاده قرار گرفته باشد.

مشتریان کلودفلر محافظت می‌شوند

همان‌طور که در بالا اشاره کردیم، کلودفلر این آسیب‌پذیری را وصله کرده است و اصلاح نیازی به اقدام بیشتر توسط مشتریان کلودفلر (Cloudflare) ندارد. علاوه بر این، ما هیچ مدرکی دال بر سواستفاده هیچ بازیگر مخربی از این آسیب‌پذیری پیدا نکردیم.

حرکت سریع با شفافیت

ما از اورن یومتوف و تیم تحقیقات امنیتی آکامپلیش به خاطر تحقیقات دقیق، افشای مسئولانه و همکاری در این پست تشکر می‌کنیم. ما جامعه کلودفلر (Cloudflare) را تشویق می‌کنیم تا هرگونه آسیب‌پذیری شناسایی‌شده را برای کمک به ما در بهبود مداوم وضعیت امنیتی محصولات و پلتفرم خود ارسال کنند.

ما همچنین می‌دانیم که اعتمادی که به ما می‌کنید برای موفقیت زیرساخت شما در کلودفلر از اهمیت بالایی برخوردار است. ما این آسیب‌پذیری‌ها را بسیار جدی می‌گیریم و به انجام هر کاری در توان خود برای کاهش تأثیر ادامه خواهیم داد. ما عمیقاً از حمایت و اعتماد مستمر شما به پلتفرم خود قدردانی می‌کنیم و متعهد می‌مانیم که نه تنها امنیت را در تمام کارهایی که انجام می‌دهیم در اولویت قرار دهیم، بلکه هر زمان که مسئله‌ای ایجاد می‌شود به سرعت و شفاف عمل کنیم.

جدول زمانی

• ۴ سپتامبر، ۱۵:۲۶ UTC: اورن یومتوف از آکامپلیش (Accomplish) این مسئله را از طریق هکریک (HackerOne) گزارش کرد.
• ۴ سپتامبر، ۱۸:۴۵ UTC: کلودفلر یک حادثه امنیتی را باز کرد و راه‌اندازی تولید را که باعث ایجاد نقص شده بود تأیید کرد.
• ۴ سپتامبر، ۲۱:۲۷ UTC: کلودفلر اصلاحیه زمان اجرا و تست استفاده مجدد آن را ادغام کرد.
• ۴ سپتامبر، ۲۲:۰۳ UTC: کلودفلر تغییرات را برای استخرهای جدید و زنده ادغام کرد.
• ۴ سپتامبر، ۲۳:۱۵ UTC: کلودفلر شروع به انتشار تغییرات کرد.
• ۷ سپتامبر، ۰۶:۱۳ UTC: کلودفلر انتشار تغییرات را کامل کرد و پاکسازی داده‌های استخر قدیمی را آغاز کرد.
• ۱۴ سپتامبر، ۱۰:۵۰ UTC: محققان گزارش دادند که اثبات مفهوم آن‌ها از کار افتاده است.
• ۱۴ سپتامبر، ۱۲:۵۲ UTC: کلودفلر یک جایزه به محقق اهدا کرد.
• ۱۹ سپتامبر، ۱۵:۰۳ UTC: کلودفلر پاکسازی تمام اسنپ‌شات‌های کش‌شده قبل از کاهش را در سراسر ناوگان آسیب‌دیده تکمیل کرد.

منبع: blog.cloudflare.com