خلال العام الماضي، اكتشف فريق بحث Wiz مجموعة من أسطح الهجوم الجديدة في السحابة. سنقدم هذا الأسبوع اثنين منهم في مؤتمر Blackhat السنوي في لاس فيغاس. نظرًا لأن Wiz يخدم قاعدة واسعة من عملاء المؤسسات، فلدينا منظور فريد لا يمتلكه معظم الباحثين – فنحن نرى ما إذا كانت نقاط الضعف التي نبلغ عنها لموفري الخدمات السحابية تؤدي إلى إصلاحات فعالة في بيئات العملاء.
ما مدى عزلة حسابات AWS؟
كانت حلقة التعليقات هذه حاسمة بالنسبة لبحثنا حول فئة جديدة من الثغرات الأمنية “عبر الحسابات” في Amazon Web Services (AWS). يستخدم العملاء AWS (وغيرهم من موفري الخدمات السحابية) مع توقع أن بيئاتهم السحابية معزولة تمامًا عن العملاء الآخرين. أردنا معرفة ما إذا كان هذا الافتراض صحيحًا.
لذلك، في نوفمبر الماضي، قام فريق البحث لدينا بتعيين جميع الخدمات في AWS التي تسمح بالوصول من حسابات أخرى لمعرفة ما إذا كان أي منها قد يعرض العملاء عن غير قصد. في غضون 10 أيام فقط من البحث، اكتشفنا ثلاث نقاط ضعف في خدمات AWS المختلفة التي تسمح لأي شخص بقراءة حسابات عملاء AWS الآخرين أو الكتابة فيها.
على الرغم من أنه سيكون من الصعب على الجهات الفاعلة الضارة استغلال هذه الثغرة الأمنية في العالم الحقيقي، إلا أن حقيقة أنه من الممكن تنفيذ عمليات غير مصرح بها على حسابات العملاء الآخرين يعد اكتشافًا مذهلاً. هذا هو ناقل تعرض جديد يمكن أن يسمح للمهاجم بسرقة البيانات من بيئات آمنة للغاية دون ترك أي أثر.
لقد أبلغنا Amazon بالمشكلات في نوفمبر 2020، وتحركت AWS سريعًا لمعالجتها. ومع ذلك، لا يمكن إصلاح إحدى الثغرات الأمنية بواسطة AWS وحدها – يجب على كل مستخدم ضعيف تحديث سياساته الحالية. أبحاثنا تشير إلى ذلك لا يزال أكثر من 90% من العملاء معرضين للخطر حتى يومنا هذا.
والأكثر من ذلك، نحن نشك بشدة في أن العديد من الخدمات في AWS معرضة لهذا النوع من الثغرات الأمنية عبر الحسابات.
كيف يعمل الوصول عبر الحسابات – ويمكن استغلاله
ببساطة، تسمح سياسات الموارد لخدمات AWS المختلفة بالوصول إلى بعضها البعض. لماذا هذا مهم؟ في هذه الأيام، يتبنى معظم عملاء السحابة نهجًا متعدد الحسابات. فبدلاً من إدارة جميع عملياتهم في حساب سحابي واحد، يقومون بتقسيم النشاط إلى عدة حسابات سحابية، لكل منها بيئة محددة لغرض محدد. من الشائع أن تمتلك الشركة مئات أو آلاف الحسابات في AWS. لتسهيل إدارة ذلك، يمنح العملاء خدمات AWS حق الوصول لتنفيذ العمليات عبر حساباتهم المتعددة.
على سبيل المثال، تتيح خدمة CloudTrail الشهيرة للعملاء جمع السجلات من حسابات متعددة ومركزيتها في مجموعة واحدة.
عندما يمنح العملاء حق الوصول إلى خدمة AWS الرسمية، فإنهم يثقون بها تمامًا. لن يفكر معظمنا مرتين قبل منح AWS CloudTrail إمكانية الوصول إلى مجموعات S3 والموارد السحابية الأخرى. لذلك تفاجأنا عندما اكتشفنا أنه في بعض الحالات، يمكن التعامل مع خدمات AWS (CloudTrail وAWS Config وServerless Repository) لمنح أي شخص إمكانية الوصول إلى الموارد المحددة للعملاء الآخرين.
نقاط الضعف
في اثنتين من الخدمات المعرضة للخطر، CloudTrail وAWS Config، سمحت سياسة الموارد التي تم تعيينها تلقائيًا بواسطة AWS لأي شخص بكتابة سجلات الخدمة في حسابات العملاء الآخرين. هنا هو انهيار التدفق الضعيف:
-
يقوم المهاجم بتكوين CloudTrail على حسابه لكتابة السجلات في المجموعة المستهدفة. المجموعة المستهدفة المختارة موجودة في حساب العميل.
-
تجمع CloudTrail السجلات وتكتب في مجموعة بيانات العميل، وتخدم المهاجم وتتصرف نيابة عنه دون علمه.
-
تسمح المجموعة بالوصول نظرًا لأن الحاوية تثق في CloudTrail.
أثرت الثغرة الأمنية الأكثر خطورة على AWS’ Serverless Repository، وهي خدمة منصة تسمح للعملاء بتخزين ونشر التطبيقات بدون خادم. لكي تعمل الخدمة بشكل صحيح، تحتاج الخدمة إلى سحب الكائنات من حاويات S3 الخاصة بالعملاء – ولا يفكر العملاء مرتين قبل منح الوصول إلى الحاويات الخاصة بهم من خلال سياسة الموارد. لقد وجدنا طريقة لاستغلال الخدمة للقراءة من مجموعات S3 الخاصة بالعملاء الآخرين، والتي غالبًا ما تحتوي على معلومات حساسة مثل كود المصدر وكلمات المرور وغيرها من العناصر. وكان هذا صحيحًا حتى بالنسبة للحسابات المعزولة غير المتصلة بالإنترنت.
السبب الجذري
السبب الجذري للثغرات الأمنية هو أنه يمكن خداع خدمات AWS لتنفيذ إجراءات نيابة عن المهاجم، وتثق المجموعة المستهدفة في الخدمة دون شروط.
على سبيل المثال، اعتبارًا من نوفمبر الماضي، كانت هذه هي سياسة الموارد الافتراضية لـ AWS لحاوية S3.
يسمح لخدمة AWS تسمى Serverless Repository بالوصول إلى أي كائن في المجموعة. المشكلة هي أن الأمر مفتوح للغاية. لا تحدد هذه السياسة أو تحد من أي مكان من يمكن استخدام الخدمة للوصول إلى المعلومات في أي حاوية S3 خاصة بالعميل.
باختصار، كانت سياسة AWS الافتراضية غير آمنة، وتجعل من السهل على الجهات الفاعلة الضارة الانتقال من حساب إلى آخر، مما يؤدي إلى إلحاق الضرر. لم تتح للعملاء مطلقًا فرصة تكوين سياسات الموارد الخاصة بهم بشكل آمن – فقد كانوا غير آمنين بشكل افتراضي.
حلت المشكلة… أم أنها كذلك؟
ويُحسب لأمازون أنها تصرفت بسرعة لإصلاح نقاط الضعف من خلال إضافة شروط إلى سياسات الموارد الأساسية التي تقيد الوصول بشكل أفضل.
ومع ذلك، لا تستطيع AWS حل هذه المشكلة بمفردها. يمكن للعملاء أنفسهم فقط تعديل وتحديث سياسات الموارد الخاصة بهم. يكون حل الثغرة الأمنية دائمًا أقل فعالية عندما يكون هناك حاجة لتفاعل المستخدم. في هذه الحالة، أرسلت أمازون تنبيهات مثل تلك الموجودة أدناه إلى المستخدمين المعرضين للخطر عبر البريد الإلكتروني وإشعار الأمان في لوحة معلومات الصحة الشخصية في أمازون.
ومع ذلك، بعد مرور 5 أشهر من إصلاح السياسات، أظهر استطلاع أجريناه لبيئات AWS أن أكثر من 90% من حاويات المستودعات بدون خادم لا تزال مهيأة بشكل غير صحيح ومعرضة للخطر. وجد استطلاعنا أيضًا أن أكثر من 25% من البيئات لا تزال تستخدم سياسة CloudTrail التي تم تكوينها بشكل خاطئ.
ونظرًا لأن هذه النتائج تستند إلى مجموعة عينات واحدة، فلا يمكننا تحديد ما إذا كانت تمثل بيئات عملاء AWS بشكل عام. لكنها تشير إلى نقص واسع النطاق في الوعي، مما يترك العديد من الحسابات مكشوفة.
كيف أحمي البيئة السحابية الخاصة بي؟
يحتوي Wiz على عناصر تحكم مدمجة تكتشف حالات التعرض السحابية الجديدة، بما في ذلك نقاط الضعف في AWS عبر الحسابات. يمكن لعملائنا استخدام هذا الرابط لمراجعة أي تعرض في حسابك، أو التواصل معنا للمناقشة.
إذا لم تكن من عملاء Wiz، فسننشر تعليمات حول كيفية قيام مستخدمي AWS بتحديث سياسات الموارد الخاصة بهم لمنع الوصول غير المصرح به. وتخطط AWS أيضًا لإضافة هذه الثغرات الأمنية إلى محلل AWS Access حتى يتمكن جميع المستخدمين من الحصول على إشعارات جاهزة للوصول إلى الخدمة التي تم تكوينها بشكل خاطئ.
الوجبات الجاهزة
نظرًا لأن هذا النوع من التعرض عبر الحسابات جديد، فإن معظم العملاء لا يدركون تمامًا أنهم معرضون للخطر وأن العديد من البيئات المعزولة معرضة لناقلات تسرب البيانات هذه. علاوة على ذلك، نعتقد أن نقاط الضعف الثلاث التي اكتشفناها هي قمة جبل الجليد: من المحتمل وجود ثغرات أمنية مماثلة في خدمات AWS الأخرى.
يحتاج هذا الموضوع إلى مزيد من البحث، ونأمل أن يكون بحثنا الأول من بين العديد من الأبحاث. يسعدنا العمل مع أي فريق أمني يرغب في استكشاف هذه المشكلات بشكل أكبر.
السحابة هي المستقبل، ومع ذلك لم يكن هناك ما يكفي من استكشاف الثغرات الموجودة في نسيج البنية التحتية السحابية التي يعتمد عليها اقتصادنا الحديث.
يجب أن تكون هناك طريقة أفضل
العملية الحالية للإبلاغ عن الثغرات الأمنية السحابية وتتبعها معطلة. يقوم بائعو الخدمات السحابية بإصلاح المشكلات بهدوء عندما يعلمون بها، ولكن لا توجد قاعدة بيانات مركزية لمخاطر التعرض السحابية المعروفة. يتحمل المستخدمون مسؤولية إصلاح هذه المشكلات، لكن ليس لديهم طريقة لمعرفة وجود هذه الثغرات.
ولهذا السبب نتعاون مع موردي الخدمات السحابية والمؤسسات الأخرى لإنشاء عملية أفضل. انضم إلى مجموعة Slack الخاصة بنا لمساعدتنا في بدء الثورة.
