الخبراء يكشفون عن عيوب خطيرة في AWS تؤدي إلى RCE وسرقة البيانات وعمليات الاستحواذ على الخدمة الكاملة
اكتشف باحثو الأمن السيبراني العديد من العيوب الخطيرة في عروض Amazon Web Services (AWS) والتي، إذا تم استغلالها بنجاح، قد تؤدي إلى عواقب وخيمة.
“إن تأثير هذه الثغرات الأمنية يتراوح بين تنفيذ التعليمات البرمجية عن بعد (RCE)، واستيلاء المستخدم على الخدمة الكاملة (والتي قد توفر وصولاً إداريًا قويًا)، والتلاعب بوحدات الذكاء الاصطناعي، وكشف البيانات الحساسة، واستخلاص البيانات ورفض الخدمة،” شركة الأمن السحابي Aqua قال في تقرير مفصل تمت مشاركته مع The Hacker News.
وبعد الكشف المسؤول في فبراير 2024، عالجت أمازون أوجه القصور على مدار عدة أشهر من مارس إلى يونيو. وكانت النتائج المقدمة في بلاك هات الولايات المتحدة الأمريكية 2024.
من أهم هذه المشكلة، والتي يطلق عليها اسم Bucket Monopoly، ناقل هجوم يُشار إليه باسم Shadow Resource، والذي يشير، في هذه الحالة، إلى الإنشاء التلقائي لحاوية AWS S3 عند استخدام خدمات مثل CloudFormation وGlue وEMR وSageMaker وServiceCatalog و كود ستار.
يعد اسم حاوية S3 الذي تم إنشاؤه بهذه الطريقة فريدًا ويتبع اصطلاح تسمية محدد مسبقًا (“cf-templates-{Hash}-{Region}”). يمكن للمهاجم الاستفادة من هذا السلوك لإعداد مجموعات في مناطق AWS غير المستخدمة وانتظار عميل AWS الشرعي لاستخدام إحدى الخدمات الحساسة للحصول على وصول سري إلى محتويات حاوية S3.
استنادًا إلى الأذونات الممنوحة لحاوية S3 التي يتحكم فيها الخصم، يمكن استخدام هذا النهج للتصعيد لتفعيل حالة حجب الخدمة، أو تنفيذ التعليمات البرمجية، أو معالجة البيانات أو سرقتها، وحتى الحصول على التحكم الكامل في حساب الضحية دون علم المستخدم.
لتعظيم فرص نجاحهم، باستخدام Bucket Monopoly، يمكن للمهاجمين إنشاء مجموعات غير مُطالب بها مقدمًا في جميع المناطق المتاحة وتخزين التعليمات البرمجية الضارة في الحاوية. عندما تقوم المؤسسة المستهدفة بتمكين إحدى الخدمات الضعيفة في منطقة جديدة لأول مرة، سيتم تنفيذ التعليمات البرمجية الضارة دون علم، مما قد يؤدي إلى إنشاء مستخدم إداري يمكنه منح التحكم للمهاجمين.
 |
| نظرة عامة على ثغرة CloudFormation |
ومع ذلك، من المهم مراعاة أنه سيتعين على المهاجم الانتظار حتى تقوم الضحية بنشر مكدس CloudFormation جديد في منطقة جديدة لأول مرة لبدء الهجوم بنجاح. يعتمد تعديل ملف قالب CloudFormation في حاوية S3 لإنشاء مستخدم إداري مخادع أيضًا على ما إذا كان حساب الضحية لديه إذن لإدارة أدوار IAM.
 |
| نظرة عامة على ثغرة الغراء |
 |
| نظرة عامة على ثغرة CodeStar |
قالت Aqua إنها عثرت على خمس خدمات AWS أخرى تعتمد على منهجية تسمية مماثلة لحاويات S3 – {Service Prefix} – {AWS Account ID} – {Region} – مما يعرضها لهجمات Shadow Resource ويسمح في النهاية لممثل التهديد بالتصعيد الامتيازات وتنفيذ إجراءات ضارة، بما في ذلك DoS، والكشف عن المعلومات، ومعالجة البيانات، وتنفيذ التعليمات البرمجية التعسفية –
- لصق AWS: aws-glue-assets-{Account-ID}-{Region}
- AWS Elastic MapReduce (EMR): aws-emr-studio -{Account-ID}-{Region}
- AWS SageMaker: sagemaker-{Region}-{Account-ID}
- AWS CodeStar: aws-codestar-{Region}-{Account-ID}
- كتالوج خدمة AWS: cf-templates-{Hash}-{Region}
كما أشارت الشركة إلى أن معرفات حسابات AWS يجب أن تعتبر سرية، على عكس ما تفعله أمازون الدول في وثائقها، حيث يمكن استخدامها لشن هجمات مماثلة.
وقال أكوا: “لا يؤثر ناقل الهجوم هذا على خدمات AWS فحسب، بل يؤثر أيضًا على العديد من المشاريع مفتوحة المصدر التي تستخدمها المؤسسات لنشر الموارد في بيئات AWS الخاصة بها”. “تقوم العديد من المشاريع مفتوحة المصدر بإنشاء حاويات S3 تلقائيًا كجزء من وظائفها أو توجيه مستخدميها لنشر حاويات S3.”
“بدلاً من استخدام معرفات يمكن التنبؤ بها أو ثابتة في اسم الحاوية، يُنصح بإنشاء تجزئة فريدة أو معرف عشوائي لكل منطقة وحساب، ودمج هذه القيمة في اسم حاوية S3. يساعد هذا الأسلوب في الحماية من المهاجمين الذين يطالبون بحاويتك قبل الأوان “.
إرسال التعليق