بسیاری از کارشناسان بر این باورند که نشت داده‌ها در محیط‌های ابری عمدتاً ناشی از اشتباهات خود مشتریان (مانند پیکربندی نادرست ذخیره‌سازها یا پورت‌های باز) است. با این حال، تحقیقات فنی اخیر نشان می‌دهد که تهدیدات بحرانی می‌توانند مستقیماً از درون زیرساخت خودِ ارائه‌دهنده سرویس ابری نشأت بگیرند. این گزارش به بررسی یک زنجیره پیچیده از آسیب‌پذیری‌ها و خطاهای منطقی می‌پردازد که در نهایت منجر به دور زدن کامل محدودیت‌های جداسازی مشتریان (Tenant Isolation) در یک پلتفرم ابری بزرگ شده است.
۱. دسترسی اولیه از طریق کلاستر مدیریت‌شده Kubernetes
مهاجم با استفاده از یک کلاستر مدیریت‌شده (Managed Kubernetes) شروع به کار می‌کند. اولین گام، فرار از گره‌های کاری (Worker Nodes) بود. در این سناریو، سیاست‌های امنیتی کلاستر مانع از ایجاد Podهای دارای سطح دسترسی بالا (Privileged Pods) با دسترسی به Host Namespaces نمی‌شد. این نقص به مهاجم اجازه داد تا با استفاده از دستوراتی نظیر nsenter، از محیط کانتینر خارج شده و به محیط میزبان (Host Machine) دسترسی کامل Root پیدا کند.
۲. بهره‌برداری از سرویس Konnectivity و دستیابی به RCE
پس از دسترسی به میزبان، سرویس Konnectivity هدف قرار گرفت. این سرویس که وظیفه ایجاد تونل بین Control Plane و Data Plane را دارد، دارای یک آسیب‌پذیری از نوع SSRF (تغییر درخواست سمت سرور) بود. مهاجم با ارسال بسته‌های خاص (DIAL_REQ) به سرویس AgentService، توانست دستورات خود را در سطح Control Plane اجرا کرده و به اجرای کد از راه دور (RCE) دست یابد. همچنین با بهره‌گیری از یک باگ شناخته شده در OverlayFS، توانست سطح دسترسی خود را در سطح سیستم‌عامل میزبان نیز ارتقاء دهد.
۳. حرکت جانبی (Lateral Movement) در شبکه Overlay
پس از تسلط بر Control Plane، شبکه ابری که به صورت یک شبکه تخت (Flat Overlay Network) طراحی شده بود، امکان حرکت جانبی گسترده را فراهم کرد:
- VictoriaMetrics: از طریق این سرویس، متادیتاهای حساس مربوط به سایر مشتریان و لیست میزبان‌های Control Plane استخراج شد.
- Apache Kafka: با بهره‌برداری از سرویس JMX Registry که به اشتباه در شبکه مشترک در دسترس بود، امکان اجرای کد از راه دور (RCE) روی میزبان‌های Kafka فراهم شد.
- Redis: یک آسیب‌پذیری منطقی در سرویس redis-exporter اجازه داد تا اعتبارنامه‌های (Credentials) مربوط به سایر مشتریان از طریق درخواست‌های Scrape سرقت شود.
- PostgreSQL: با دسترسی به سرویس etcd و تغییر پیکربندی Patroni، مهاجم توانست از طریق دستور archive_command به RCE روی کلاسترهای پایگاه داده دست یابد.
۴. تسلط کامل بر زیرساخت مدیریت SaltStack
در مرحله نهایی، تمرکز بر سرویس مدیریت پیکربندی SaltStack قرار گرفت. تحلیل فایل‌های Salt Master نشان داد که یک اسکریپت سفارشی دارای آسیب‌پذیری SQL Injection است. مهاجم با تزریق کد SQL از طریق متادیتای مربوط به Minionها، توانست به پایگاه داده اصلی دسترسی پیدا کند. این دسترسی شامل توکن‌های احراز هویت تمامی Salt Masterها بود که در نهایت امکان اجرای دستورات دلخواه بر روی تمامی منابع ابری (از جمله VDS و S3) را فراهم می‌کرد.
