ثلاث هجمات لتصعيد الامتيازات في AWS، مع أدلة CloudTrail والإصلاح

بقلم فريق Pathbreak · 23 أكتوبر 2026 · قراءة 8 دقائق

هجوم تصعيد الامتيازات في AWS هو سلسلة من استدعاءات API تنقل جهة فاعلة من الأذونات التي تملكها إلى أذونات لم تُمنح لها قط. لا يوجد استغلال بالمعنى المعتاد. فالاستدعاءات هي نفسها التي يجريها المسؤولون كل يوم، وهذا ما يجعل ملاحظتها صعبة وتركها مفتوحة سهلاً. وتسرد خريطة تصعيد الامتيازات في AWS كل إذن يمكن استخدامه بهذه الطريقة. تتناول هذه المقالة ثلاثاً من أكثر السلاسل شيوعاً، وتوضح لكل منها كيف تعمل، وما الذي يسجله CloudTrail، والتغيير الذي يكسرها.

السلسلة الأولى: تمرير دور إلى Lambda

الأذونات. iam:PassRole على دور ذي امتيازات، مع lambda:CreateFunction. وعادةً lambda:InvokeFunction أيضاً، مع أنه يمكن تشغيل الدالة كذلك عبر مصدر أحداث.

كيف تعمل. ينشئ المهاجم دالة Lambda جديدة ويمرر الدور ذا الامتيازات بوصفه دور التنفيذ لها. ويقبل AWS التمرير لأن سياسة الثقة للدور تسمح بـ lambda.amazonaws.com. ثم يستدعي المهاجم الدالة، فتعمل أي شيفرة كتبها بأذونات الدور ذي الامتيازات. وإذا كان ذلك الدور مسؤولاً، يصبح الحساب ملكه بعد عملية إنشاء واحدة واستدعاء واحد. والنمط نفسه يعمل مع EC2 وECS وGlue وCloudFormation وCodeBuild وأي خدمة أخرى تقبل دوراً ممرَّراً.

ما يُظهره CloudTrail. حدث إدارة CreateFunction من lambda.amazonaws.com يكون فيه requestParameters.role هو ARN لدور ذي امتيازات. لا يُنتج فحص iam:PassRole حدثاً خاصاً به، فالتمرير يظهر في معاملات استدعاء الإنشاء. أما Invoke اللاحق فهو حدث بيانات في Lambda، لذا لا يظهر إلا إذا كانت أحداث بيانات Lambda مفعّلة في المسار، وهي معطّلة افتراضياً ويستحق تفعيلها لهذا السبب تحديداً. وعند توفر الاثنين تكون الإشارة هي الاقتران: جهة فاعلة لم تنشئ دالة من قبل تنشئ دالة مرفقاً بها دور عالي القيمة، ثم تستدعيها خلال دقائق. ومن دون أحداث البيانات، تكون الإشارة هي استدعاء الإنشاء نفسه ونشاط API الذي يقوم به الدور الممرَّر بعد ذلك.

الإصلاح. حدّد نطاق التمرير. أضف شرط iam:PassedToService إلى منح iam:PassRole بحيث لا يمكن تمرير الدور إلا إلى الخدمة التي تحتاجه، واستبدل أي حرف بدل في ARN المورد بالدور المحدد. وإذا لم تكن الجهة الفاعلة بحاجة إلى تمرير الأدوار أصلاً، فأزل الإذن. الشرح الكامل: تمرير دور إلى Lambda.

السلسلة الثانية: إعادة كتابة سياسة الثقة لدور، ثم تقمّصه

الأذونات. iam:UpdateAssumeRolePolicy على دور ذي امتيازات، إضافة إلى sts:AssumeRole.

كيف تعمل. تحدد سياسة الثقة للدور من يحق له تقمّصه. والجهة الفاعلة القادرة على إعادة كتابة هذا المستند تضيف نفسها جهةً موثوقة، ثم تستدعي sts:AssumeRole وتحصل على بيانات اعتماد مؤقتة للدور. وتفقد علاقة الثقة الأصلية أي أهمية بمجرد الكتابة فوقها، لذا تستولي هذه الخطوة على أي دور في الحساب تستطيع الجهة الفاعلة الوصول إليه باستدعاء التحديث. وتبقى سياسة الثقة المعاد كتابتها قائمة حتى يلاحظها أحد، ما يجعل هذه الخطوة آلية تصعيد واستمرارية في آن واحد.

ما يُظهره CloudTrail. حدث UpdateAssumeRolePolicy من iam.amazonaws.com يحمل مستند السياسة الجديد في requestParameters.policyDocument، يليه حدث AssumeRole من sts.amazonaws.com للدور نفسه، من الجهة الفاعلة التي أضيفت للتو. ونادراً ما تتغير سياسات الثقة في حساب سليم، لذا يستحق أي حدث UpdateAssumeRolePolicy خارج مسار النشر نظرة فاحصة، وأي حدث يضيف جهة فاعلة من داخل الحساب إشارة قوية.

الإصلاح. أزل iam:UpdateAssumeRolePolicy من أي جهة فاعلة ليست مسار إدارة IAM، وضع عليه Deny صريحاً للأدوار ذات الامتيازات في الحساب، مع جعل دور النشر الاستثناء الوحيد. الشرح الكامل: إعادة كتابة ثقة الدور ثم تقمّصه.

السلسلة الثالثة: إنشاء مفتاح وصول لمستخدم آخر

الأذونات. iam:CreateAccessKey على مستخدم غير الجهة المستدعية.

كيف تعمل. يستدعي المهاجم iam:CreateAccessKey باسم مستخدم آخر ويحصل على مفتاح وصول جديد طويل الأمد لذلك المستخدم. ولا يحتاج أبداً إلى كلمة مرور المستخدم أو مفاتيحه الحالية. ومنذ تلك اللحظة يستطيع استدعاء API بصفته ذلك المستخدم، ويصمد المفتاح الجديد أمام إعادة تعيين كلمة المرور وتدوير المفتاح الآخر للمستخدم. وهذه أصعب السلاسل الثلاث ملاحظةً، لأن استدعاءً واحداً يُنتج بيانات اعتماد دائمة، ولا يرى المستخدم الذي سُلبت هويته أي شيء.

ما يُظهره CloudTrail. حدث CreateAccessKey من iam.amazonaws.com يختلف فيه requestParameters.userName عن الهوية الواردة في userIdentity. هذا التباين هو الإشارة. فإنشاء المستخدمين مفاتيح لأنفسهم أمر طبيعي. أما إنشاء جهة فاعلة مفاتيح لجهة أخرى فنادر خارج سكربت الإعداد الأولي للمستخدمين، ومن السهل إدراج دور ذلك السكربت في قائمة السماح. ويظهر الاستخدام اللاحق على شكل استدعاءات API من المستخدم الضحية من عنوان IP مصدر ووكيل مستخدم جديدين.

الإصلاح. أزل iam:CreateAccessKey من كل جهة فاعلة ليست مسار إدارة الهوية، وحيث يتعين على المستخدمين إدارة مفاتيحهم بأنفسهم، حدّد نطاق المنح بـ ${aws:username} بحيث لا يستطيع المستخدم إنشاء مفاتيح إلا لنفسه. الشرح الكامل: إنشاء مفتاح وصول لمستخدم.

كيفية اكتشاف تصعيد الامتيازات في AWS

تشترك السلاسل الثلاث أعلاه في نمط قابل للتعميم. فتصعيد الامتيازات يترك أحداثاً عادية بمعاملات غير معتادة، من جهات فاعلة ليس لها سجل في إجرائها. ويقوم الاكتشاف في CloudTrail على أربعة أمور.

أولاً، يجب أن يكون CloudTrail مفعّلاً لكل حساب وكل منطقة، مع تسليم المسار إلى حساب مركزي لا تستطيع أحمال العمل الكتابة فيه. فالمهاجم القادر على تعطيل المسار أو حذفه يزيل الدليل، ومكان StopLogging وDeleteTrail هو قائمة المراقبة نفسها التي تضم أحداث التصعيد.

ثانياً، راقب المعاملات وليس أسماء الأحداث فقط. فـ CreateFunction بمفرده أمر روتيني، بينما يستحق CreateFunction مع دور مسؤول في المعاملات تنبيهاً. وينطبق الأمر نفسه على CreateAccessKey عندما يختلف المستخدم المستهدف عن الجهة المستدعية.

ثالثاً، ضع خط أساس لكل جهة فاعلة. فدور CI ينشئ دالة كل ساعة ومطوّر لم يستدعِ IAM منذ عام مصدران مختلفان، والحدث نفسه من كل منهما يعني أشياء مختلفة.

رابعاً، اربط الأحداث ببعضها. فالتصعيد تسلسل: إنشاء ثم استدعاء، وتحديث الثقة ثم التقمّص، وإنشاء مفتاح ثم استخدامه من مكان جديد. والقاعدة التي تربط الحدث الأول بالثاني ضمن نافذة زمنية قصيرة تُنتج إنذارات كاذبة أقل بكثير من أي من الحدثين بمفرده. ونشاط Lambda وS3 وDynamoDB من أحداث البيانات، ويجب تفعيله في المسار قبل أن يمكن ربطه.

الاكتشاف هو خط الدفاع الثاني

يخبرك CloudTrail بعد إجراء الاستدعاء. أما خط الدفاع الأول فهو أن تعرف، قبل أي استدعاء، أي الجهات الفاعلة قادرة على إجرائه. وهذا يعني أخذ كل سلسلة على الخريطة وحلّها مقابل التفويض الحقيقي في الحساب: سياسات الهوية، والحدود، وSCP، وسياسات الثقة، والشروط. والسلسلة التي تكون نتيجتها السماح لجهة فاعلة هي مسار مثبت، والإصلاح هو التغيير المذكور أعلاه، يُطبَّق قبل أن يجربه أحد. ويُجري Pathbreak هذا الحل بصلاحيات قراءة فقط عبر كل حساب، ويرتّب المسارات المثبتة حسب ما تصل إليه، ويؤكد كل إصلاح بعد نشره. وتسرد أداة pathbreak-audit المجانية الجهات الفاعلة في حساب واحد التي تملك هذه الأذونات، كنقطة انطلاق.

الأسئلة الشائعة