‏بردارهای حمله به کانتینرها: از فرار از کانتینر تا حمله‌ی زنجیره تأمین

زیرساخت‌های مدرن به‌شدت به کانتینری‌سازی وابسته شدن و Docker و Kubernetes استاندارد سازمانی‌ان. ولی هرچی محبوبیت کانتینرها بیشتر شده، علاقه‌ی مهاجم‌ها هم بیشتر شده. این پژوهش کسپرسکی مهم‌ترین بردارهای حمله‌ای رو بررسی می‌کنه که امروز فعالانه استفاده می‌شن. نکته‌ی پایه‌ای اینه که کانتینر برخلاف ماشین مجازی، kernel میزبان رو به‌اشتراک می‌ذاره و ایزولاسیونش روی قابلیت‌های کرنل لینوکس مثل namespaceها، cgroupها، capabilityها و seccomp ساخته شده؛ پس به‌خطر افتادن کانتینر می‌تونه به خودِ میزبان هم برسه.

بردار اول، سوءاستفاده از آسیب‌پذیری‌های میزبان و runtimeـه. چون کانتینر سیستم‌عامل ایزوله‌ی خودش رو نداره، باگ‌های کرنل یا اجزای runtime همچنان بحرانی‌ان. مقاله چند CVE شاخص رو نام می‌بره: CVE-2019-5736 که به‌خاطر مدیریت نادرست runC از مکانیزم /proc/self/exe، اجازه می‌داد فایل اجراییِ runC بازنویسی بشه و کد روی میزبان با دسترسی root اجرا بشه؛ CVE-2022-0492 که با اعتبارسنجی نادرست در مکانیزم release_agent مربوط به cgroups، فرار از کانتینر می‌داد؛ و CVE-2024-21626 که به‌خاطر مدیریت نادرست file descriptorها و دایرکتوری کاری، دسترسی به فایل‌سیستم میزبان رو ممکن می‌کرد.

بردار دوم، اقدامات مخرب داخل خودِ کانتینرـه. گاهی مهاجم لازم نیست فرار کنه، چون خود کانتینر پر از داده‌ی باارزشه: اعتبارنامه‌ها، کلیدهای API، توکن‌های دسترسی، کلیدهای SSH، متغیرهای محیطی حاوی secret، و به‌خصوص توکن‌های ServiceAccount کوبرنتیز که مستقیماً راه تعامل با Kubernetes API رو باز می‌کنن. حتی یه کانتینرِ کاملاً ایزوله هم اگه داده‌ی حساس داشته باشه، می‌تونه نقطه‌ی شروع یه نفوذ باشه.

بردار سوم و خطرناک‌ترین، فرار از کانتینر (container escape) ـه؛ یعنی دور‌زدن ایزولاسیون و تعامل مستقیم با میزبان. مقاله می‌گه در عمل، پیکربندی‌های غلط خیلی بیشتر از آسیب‌پذیری‌های پیچیده عامل فرار هستن. خطرناک‌ترین حالت، اجرای کانتینر با فلگ --privilegedـه که همه‌ی capabilityها و دسترسی به دستگاه‌های میزبان رو می‌ده و کانتینر عملاً دیگه ایزوله نیست. بعد به چند capability پرخطر می‌پردازه: CAP_SYS_ADMIN که به سازوکارهایی مثل mount فایل‌سیستم و cgroups دسترسی می‌ده و در ترکیب با hostPath اجازه‌ی mount دایرکتوری‌های میزبان رو می‌ده؛ CAP_SYS_MODULE که امکان بارگذاری ماژول کرنل و در نتیجه اجرای کد در فضای کرنل رو می‌ده و تقریباً همه‌جا ممنوعه؛ CAP_SYS_PTRACE که با اشتراک namespace فرایندها (hostPID: true) امکان تزریق کد به فرایندهای میزبان رو می‌ده؛ و CAP_NET_ADMIN که با دستکاری جدول مسیریابی و iptables، حملات MitM و رهگیری ترافیک رو ممکن می‌کنه (به‌خصوص با hostNetwork: true).

بردار چهارم، سوءاستفاده از APIهای ارکستراسیونـه. APIهای مدیریت کانتینر ذاتاً امتیاز ادمین روی کل زیرساخت دارن. نمونه‌ی معروفش یه Docker API باز روی TCP بدون TLS یا احراز هویته که اجازه می‌ده مهاجم از راه دور کل میزبان رو تصاحب کنه. توی کوبرنتیز هم اگه توکن ServiceAccount لو بره یا سیاست‌های RBAC ضعیف باشه یا API server ناخواسته در معرض دید باشه، مهاجم می‌تونه یه pod مخربِ privileged بسازه و بعد یکی از روش‌های فرار رو اجرا کنه. mount‌شدن Docker socket داخل کانتینر هم به مهاجم کنترل کل کانتینرهای میزبان رو می‌ده.

بردار آخر، حمله‌ی زنجیره تأمینـه که اجزا رو قبل از اجرا در runtime آلوده می‌کنه. مهاجم‌ها ایمیج‌های آلوده‌ای منتشر می‌کنن که خودشون رو جای سرویس‌های محبوب جا می‌زنن، و سازمان‌هایی که بدون تأیید مبدأ از Docker Hub استفاده می‌کنن قربانی می‌شن. سیستم‌های CI/CD هم چون امتیاز بالا دارن هدف پرتکراری‌ان؛ مهاجم به‌جای دست‌بردن در سورس‌کد، منطق مخرب رو مستقیم توی مراحل ساخت تزریق می‌کنه، طوری که از بیرون ایمیج کاملاً سالم به نظر می‌رسه. نتیجه‌ی کلی گزارش اینه که امنیت کانتینر، حفاظت از میزبان، کنترل دقیق دسترسی در ارکستراتور، کم‌کردن capabilityها و اعتبارسنجی کامل زنجیره تأمین رو با هم لازم داره.

نکات کلیدی:

• کانتینر کرنل میزبان رو به‌اشتراک می‌ذاره، پس به‌خطر افتادنش میزبان رو هم تهدید می‌کنه
• پیکربندی غلط، خیلی بیشتر از آسیب‌پذیری پیچیده عامل فرار از کانتینره
• فلگ --privileged و capabilityهایی مثل CAP_SYS_ADMIN و CAP_SYS_MODULE خطرناک‌ترن
• Docker API بازِ بدون احراز هویت می‌تونه به تصاحب کامل میزبان منجر بشه
• حمله‌ی زنجیره تأمین و آلوده‌کردن CI/CD، یه ایمیج رو در عین سالم‌به‌نظررسیدن آلوده می‌کنه