على الرغم من عدم رصد أي مهاجم حقيقي يستغل هذا الأسلوب حتى الآن، يحذر الباحثون من صعوبة اكتشافه بمجرد تنفيذه. ويستغل الهجوم ثغرة هيكلية أساسية تتمثل في التفرّد العالمي لأسماء "السطلات" التخزينية السحابية. ونظراً لعدم إمكانية تسجيل نفس اسم السطل من قبل مستخدمين مختلفين داخل مساحة اسم مقدم الخدمة، فإن هوية السطل الوجهة ترتبط باسمه فقط وليس بمالك حساب محدد.
كيف يتم تنفيذ الهجوم؟
يمكن للمهاجم الذي يخترق بيئة سحابية ويحصل على صلاحيات حذف السطلات تنفيذ الهجوم عبر تسلسل مباشر:
- حذف السطل التخزيني النشط التابع للمنظمة المستهدفة.
- إعادة إنشاء سطل جديد بنفس الاسم داخل حساب خاضع لسيطرة المهاجم.
- استمرار تدفق البيانات الأصلي (مثل مصارف السجلات في جوجل كلاود، أو قواعد نسخ S3 في AWS، أو تصدير التشخيصات في أزور) في العمل بشكل مستقل، مما يؤدي إلى كتابة البيانات مباشرة في سطل المهاجم.
ويعد الهجوم خطيراً بشكل خاص لأنه ذاتي الاستدامة. بمجرد اكتمال عملية السرقة، يبدو إعداد المصب أو النسخ الشرعي سليمًا عند الفحص، ولا يولد أي حالات خطأ واضحة ولا ينبه أي نظام أصلي. تتدفق السجلات والمقاييس والبيانات الحساسة إلى بيئة المهاجم بشكل صامت ودون توقف.
تجارب ناجحة عبر منصات رئيسية
نجح فريق أبحاث يونيت 42 في محاكاة هجوم سرقة السطل عبر خدمات متعددة على كل من المنصات الرئيسية:
جوجل كلاود
- تم تأكيد الهجوم على مصارف السجلات السحابية (Cloud Logging sinks).
- اشتراكات Pub/Sub مع وجهات تخزين سحابية.
- مهام خدمة نقل التخزين (Storage Transfer Service jobs).
- المتطلبات: صلاحيات storage.buckets.delete وstorage.objects.delete.
أمازون ويب سيرفيسز (AWS)
- تم تأكيد الهجوم على نسخ سطل S3.
- أنابيب بيانات Firehose المستهدفة إلى وجهات S3.
مايكروسوفت أزور
- تم توضيح الهجوم كهجوم عبر اشتراكات متعددة عبر إعدادات التشخيص في أزور مونيتور.
- مقيد بنطاق نفس المستأجر بسبب تأخيرات إعادة استخدام الأسماء المفروضة من المنصة.
أسباب زيادة التعرض
أشار الباحثون إلى أن الأدوار الإدارية واسعة النطاق لتخزين البيانات، والتي تُخصص بشكل شائع في بيئات المؤسسات، تزيد من خطر التعرض بشكل كبير. ففي جوجل كلاود، يمنح دور "Storage Admin" القياسي صلاحية storage.buckets.delete افتراضياً، متجاوزاً صلاحية logging.sinks.update الأكثر تقييداً، والتي تتطلبها إعادة تكوين تدفق البيانات بشكل شرعي. وهذا يسمح للمهاجمين بإعادة توجيه تدفقات البيانات دون المساس بإعدادات التدفق مباشرة.
استراتيجيات الدفاع الموصى بها
يقدم فريق يونيت 42 استراتيجية دفاع ثنائية الأبعاد تجمع بين التحكم في الامتيازات الأقل وتدابير المراقبة الاستباقية:
- تقييد صلاحيات الحذف (storage.buckets.delete، DeleteBucket، Microsoft.Storage/storageAccounts/delete) إلى أقل الأدوار الإدارية المطلوبة.
- فرض ضوابط محيط البيانات — سياسات التحكم في الخدمة (SCPs) في AWS أو ضوابط خدمة VPC السحابية في جوجل كلاود — لمنع الكتابة إلى السطلات خارج الحدود التنظيمية الموثوقة.
- تمكين مساحات أسماء S3 الإقليمية في الحساب في AWS لتحديد أسماء السطلات إلى حسابات ومناطق محددة، مما يلغي متجه الهجوم مباشرة.
- نشر تنبيهات مراقبة ذات أولوية عالية لنداءات واجهة برمجة التطبيقات لحذف السطلات، خاصة على السطلات التي تحتوي على بيانات حساسة أو خاضعة للتنظيم.
نطاق الهجوم خارج المنصات الثلاث
أكد الباحثون أن هذه التقنية لا تقتصر على المنصات الثلاث التي تم اختبارها. أي منصة سحابية تعتمد على موارد تخزين ذات أسماء فريدة عالمياً وثابتة لتوجيه تدفقات البيانات قد تكون عرضة لنفس الأسلوب. وتعزز الأبحاث أن فلسفة التصميم المشتركة عبر مقدمي الخدمات السحابية تعني أن الثغرة المكتشفة في نظام بيئي واحد يمكن أن تكون بمثابة خريطة مباشرة لاستغلال نظام آخر، وهو تذكير حاسم لفريق الأمن الذي يدير بيئات متعددة السحابة.
