دعوة للعمل في مجال الأمن: نحتاج إلى قاعدة بيانات سحابية للثغرات الأمنية

📣تحديث: في يونيو 2022، أطلقنا OPEN CVDB، وهي قاعدة بيانات للثغرات السحابية يقودها المجتمع – https://www.cloudvulndb.org/.

في عصر ما قبل السحابة، كانت المسؤولية عن الأمن تقع بالكامل في أيدي المستخدمين. ومع انتقالنا إلى السحابة، لم نشهد فقط عناصر جديدة للتأمين ونقاط ضعف جديدة، ولكن أيضًا توازنًا جديدًا للمسؤولية المشتركة عن الأمان بين المستخدمين ومقدمي الخدمات السحابية (CSPs). كان هناك ترتيب عمل تقريبي حيث يتعامل مقدمو الخدمات السحابية مع أشياء مثل الأمن المادي والأجهزة والخدمات المدارة، بينما يكون المستخدمون مسؤولين عن البرامج والهويات وحماية البيانات. وبينما نكشف عن أنواع جديدة من نقاط الضعف، نكتشف المزيد والمزيد من المشكلات التي لا تتناسب مع النموذج الحالي.

اكتشف فريق بحث Wiz وكشف عن العديد من الثغرات الأمنية الخطيرة هذا العام – مثل الثغرات الأمنية عبر الحسابات في AWS، وChaosDB، وOMIGOD – ووجدنا أن هذه الثغرات الأمنية لا تتناسب مع نموذج مسؤوليات أمان السحابة اليوم، ونتيجة لذلك، فإن التعداد والاستجابة يتراجعان.

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

لتوضيح ما نعنيه، دعونا نلقي نظرة على ثلاثة أمثلة على الثغرات السحابية التي كشف عنها فريق بحث Wiz في عام 2021 وما حدث بعد ذلك.

مثال الضعف السحابي رقم 1: ثغرات AWS عبر الحسابات

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

إحدى الخدمات الضعيفة كانت خدمة مستودع AWS Serverless. كانت السياسة التي قدمتها أمازون لمستخدميها تفتقر إلى شروط تحديد النطاق، ولم تكن خدمة المستودع بدون خادم تدعم شروط تحديد النطاق في ذلك الوقت. ونظرًا لعدم تحديد النطاق، يمكن لأي مستخدم للخدمة الوصول إلى حاويات S3 الخاصة بمستأجر آخر إذا تم تكوينها باستخدام سياسة الضعف.

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

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

مثال الضعف السحابي رقم 2: OMIGOD

مثالنا الثاني هو الذي أطلقنا عليه اسم OMIGOD. كانت OMIGOD عبارة عن مجموعة من 4 ثغرات أمنية جديدة اكتشفناها في وكيل OMI الخاص بشركة Microsoft، وهو برنامج وسيط سحابي تستخدمه العديد من خدمات Azure ويتم تثبيته بصمت على الأجهزة الافتراضية للمستخدمين بواسطة Microsoft عند إعداد هذه الخدمات (Azure Log Analytics وAzure Automation والمزيد). مكنت نقاط الضعف هذه من تنفيذ التعليمات البرمجية عن بعد وتصعيد الامتيازات المحلية في امتيازات الجذر. عند الكشف عنها، قامت Microsoft بتصحيح الثغرات الأمنية وأصدرت إصدارًا جديدًا من وكيل OMI.

نشرت Microsoft هذا الإعلان كجزء من برنامج Patch Tuesday وقدمت إرشادات للمستخدمين حول كيفية تحديث الوكيل. ومع ذلك، فإننا نرى موقفًا مشابهًا هنا كما في مثال AWS عبر الحسابات: بما أن المستخدمين لم يكن لديهم أي فكرة عن تثبيت وكلاء OMI في بيئتهم، لم تكن لديهم طريقة لمعرفة أنهم معرضون للخطر أو أين كانوا عرضة للخطر. لم تنشر Microsoft أي معلومات بخصوص الخدمات المتأثرة في البداية.

وفقًا لنموذج المسؤولية المشتركة، يكون مستخدم السحابة مسؤولاً عن تحديث نقاط الضعف في البرامج داخل أجهزته الافتراضية. ولكن ماذا يحدث عندما لا يعرف المستخدمون وجود وكلاء OMI في بيئتهم؟ كيف يمكن أن يعرفوا؟

ونظرًا لعدم اليقين وعدم التواصل الواضح مع المستخدمين، كانت النتيجة ظهور عدد كبير من مستخدمي السحابة المرتبكين، وتعرض العديد من البيئات السحابية للاستغلال، والماسحات الضوئية الآلية التي سعت إلى اختراق أي شخص لا يعرف كيف أو ما إذا كان يجب عليه التحديث.

لقد تعلمنا هنا أن الثغرات الأمنية يمكن أن توجد في البرامج الوسيطة السحابية المثبتة مسبقًا، وليس فقط في البرامج التي يقوم المستخدمون بإنشائها أو تثبيتها بأنفسهم. أثرت مشكلة عدم الحصانة هذه على العديد من خدمات Azure الشائعة ومستخدمي هذه الخدمات، ولكن لم يتم إبلاغ هؤلاء المستخدمين. عملية إخطار المستخدمين حول نقاط الضعف السحابية برمتها بالكاد موجودة. ومع افتقارهم إلى قناة مناسبة، وجد مستخدمو السحابة أنفسهم عرضة للخطر دون علمهم. على الرغم من إصدار CVEs لـ OMI، إلا أنها لم تحدد خدمات Azure الضعيفة التي تم ربطها بها، ولم يكن لدى المستخدمين أدنى فكرة عما إذا كان ينبغي عليهم اتخاذ إجراء أو الإجراءات التي يجب اتخاذها.

مثال الضعف السحابي رقم 3: ChaosDB

مثالنا الثالث كان مع ChaosDB. في أغسطس 2021، اكتشفنا ثغرة أمنية غير مسبوقة على مستوى الخدمة في Azure Cosmos DB. تم تسريب مفاتيح الوصول الخاصة بالعملاء، مع أذونات الوصول إلى قواعد بيانات Cosmos DB لمستخدمي السحابة الآخرين. حدث هذا بسبب عيوب متعددة في الطريقة التي قدمت بها Microsoft ميزة Jupyter Notebook إلى خدمة Cosmos DB. باختصار، كانت حسابات Cosmos DB تأتي مرفقة بميزة Jupyter Notebook التي يتم تمكينها تلقائيًا. لم يكن هذا أمرًا واضحًا للعملاء، لذلك عندما تم العثور على عيوب في Jupyter Notebook أثرت على Cosmos DB، تم الكشف عن العديد من العملاء دون علمهم.

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

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

يجب علينا إنشاء طريقة أفضل للاستجابة لنقاط الضعف السحابية

الغرض من الأمثلة المذكورة أعلاه ليس مجرد مهاجمة مقدمي الخدمات السحابية. وفي معظم الحالات، استجابوا بسرعة وعملوا على تخفيف المشكلات قدر استطاعتهم. ولا تنشأ المشاكل من افتقارهم إلى الجهد، بل من الافتقار إلى التوحيد القياسي والشفافية والفهم الواضح لدور كل لاعب في الاستجابة لنقاط الضعف السحابية. القضايا الرئيسية هي كما يلي:

• لا توجد قناة إعلام موحدة عبر مقدمي خدمات الاتصالات

• لا يوجد تتبع للمشكلة في مكانه

• لا يوجد سجل خطورة لمساعدة المستخدمين على تحديد الأولويات

• – عدم الشفافية في التعامل مع نقاط الضعف واكتشافها

• مجموعة متنوعة من إجراءات الاستجابة عبر نقاط الضعف المختلفة

نريد أن نوجه دعوة إلى المجتمع الأمني ​​للعمل: هذا شيء يمكننا تحسينه. نعتقد أننا بحاجة إلى قاعدة بيانات مركزية للإبلاغ عن نقاط الضعف السحابية وتعدادها.

يجب أن تكون قاعدة البيانات هذه عامة وموحدة، بحيث تكون التقارير متسقة عبر مقدمي الخدمات السحابية. يجب أن يقوم مقدمو خدمات الاتصالات (CSPs) بالإبلاغ عن كل إدخال ويتضمن المعلومات الأكثر صلة بالمستخدمين: معرف الثغرة الأمنية والوصف وخطورتها وخطوات العلاج وطرق الكشف.

فيما يلي مثال لما يمكن أن يبدو عليه هذا الإدخال لـ ChaosDB:

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

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

شاهد الدعوة إلى اتخاذ إجراء في مجال الأمن: نحن بحاجة إلى ملخص لقاعدة بيانات الثغرات الأمنية في السحابة في BlackHat Europe 2021 —

تحديث