ثغرات OpenSSL: كل ما تحتاج إلى معرفته

TL;DR: أصدر مشروع OpenSSL اثنتين من نقاط الضعف الجديدة، CVE-2022-3602 وCVE-2022-3786، وهي أقل خطورة مما تم الإعلان عنه سابقًا. وفقًا لـ Wiz Research، يصعب استغلال ثغرات تجاوز سعة المخزن المؤقت هذه وتتطلب عمليات استغلال محددة لكل تطبيق مستهدف؛ احتمالية حدوث محاولات استغلال جماعية عامة للعملاء/الخوادم التي تستخدم مكتبة OpenSSL 3 منخفضة. علاوة على ذلك، تُظهر بيانات Wiz أن 1.5% فقط من مثيلات OpenSSL هي إصدارات متأثرة.

*تم تحديث هذه المدونة في الأول من نوفمبر 2022 بعد إصدار تصحيح مشروع OpenSSL.

ما نعرفه عن ثغرات OpenSSL حتى الآن

OpenSSL هي مكتبة تشفير تُستخدم عالميًا لتشفير الاتصالات على الإنترنت. يتم استخدامه على نطاق واسع من قبل خوادم الإنترنت، بما في ذلك غالبية مواقع HTTPS.

نشرت OpenSSL تفاصيل عن اثنتين من نقاط الضعف الجديدة عالية الخطورة في OpenSSL (استشارة رسمية، منشور مدونة). تم الإعلان في البداية عن أن إحدى نقاط الضعف هذه (CVE-2022-3602) ذات خطورة حرجة، لكن OpenSSL خفضت خطورتها لاحقًا إلى عالية بسبب العديد من العوامل المخففة (التفاصيل أدناه). تعتبر الثغرة الأمنية الأخرى (CVE-2022-3786) أيضًا ذات خطورة عالية.

تؤثر هذه الثغرات الأمنية على إصدارات OpenSSL 3.0.0 وما فوق، بالإضافة إلى أي تطبيق يحتوي على مكتبة OpenSSL مضمنة متأثرة في نطاق الإصدار المتأثر. على الرغم من أن OpenSSL 3.3 هو الإصدار الرئيسي الحالي، إلا أنه لا يزال أقل انتشارًا بشكل ملحوظ من OpenSSL 1، والذي لم يتأثر بهذه الثغرة الأمنية.

يمكنك أيضًا مشاهدة ملخص الفيديو السريع الذي مدته 5 دقائق عن الثغرات الأمنية، بما في ذلك التحليل الفني والأفكار حول تأثيرها وخطورتها، بواسطة Shir Tamari رئيس قسم الأبحاث @Wiz:

ما هو الخلل الأمني ​​وراء هذه الثغرات الأمنية؟

في ظل ظروف محددة للغاية، قد تكون خوادم TLS والعملاء الذين يقومون بتشغيل الإصدارات المتأثرة من OpenSSL عرضة لتنفيذ التعليمات البرمجية عن بعد (RCE).

يكمن الخطأ في عملية التحقق من شهادة X.509 الخاصة بـ OpenSSL، والتي تكون عرضة لنوعين من تجاوز سعة المخزن المؤقت: 4 بايت (CVE-2022-3602)، وطول متغير (CVE-2022-3786). يقع هذا الخلل في مكون وحدة فك ترميز Punycode، والذي يعد جزءًا من مكتبة OpenSSL libcrypto.

هل يتأثر كل من عملاء وخوادم TLS بهذه الثغرات الأمنية؟

وفقًا لـ OpenSSL، يجب اعتبار أي تطبيق OpenSSL 3.0 يتحقق من شهادات X.509 المستلمة من مصادر غير موثوقة عرضة للخطر، وهذا يشمل عملاء TLS وخوادم TLS التي تم تكوينها لاستخدام مصادقة عميل TLS.

تحت أي ظروف يمكن استغلال نقاط الضعف هذه؟

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

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

هل الثغرات العامة متاحة لهذه الثغرات الأمنية؟

نعم، تم توفير برنامج استغلال عام واحد على الأقل لإثبات المفهوم (POC)، ولكن الغرض منه هو تعطل النظام الضعيف بدلاً من السماح بـ RCE. قد تصبح نقاط الرعاية الأكثر فعالية متاحة مع مرور الوقت.

إلى أي مدى يجب أن نكون قلقين؟

هناك العديد من العوامل المخففة المهمة التي تقلل من احتمالية استغلال نقاط الضعف هذه:

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

2. تنفذ العديد من الأنظمة الأساسية وسائل حماية لتجاوز سعة المكدس والتي من شأنها أن تخفف من مخاطر تنفيذ التعليمات البرمجية عن بعد.

3. العديد من تخطيطات مكدس الأنظمة الأساسية والمترجمين ليست عرضة للنوع المحدد من تجاوز سعة المخزن المؤقت المسموح به بواسطة CVE-2022-3602.

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

بشكل عام، سيحتاج المهاجم إلى (1) إصدار شهادة TLS ضارة مُعدة خصيصًا، و(2) توقيعها بواسطة مرجع مصدق، و(3) تحديد خادم يقوم بتشغيل إصدار ضعيف من TLS 3، والذي (4) تم تكوينه لـ mTLS و(5) ليس لديه إجراءات تخفيف فعالة لمنع الاستغلال. وهذا السيناريو غير مرجح لكنه ليس مستحيلا.

بيانات بحث Wiz: كم عدد المنظمات المعرضة للخطر؟

لتقدير التأثير المحتمل للثغرة الأمنية، قمنا بتحليل مئات البيئات السحابية من جميع مقدمي الخدمات السحابية الرئيسيين (AWS، وGCP، وAzure، وOCI، وAliCloud) وملايين أعباء العمل. النتائج: أكثر من 75% من المؤسسات لديها مثيل واحد متأثر على الأقل في بيئتها. والخبر السار هو أن 1.5% فقط من مثيلات OpenSSL هي إصدارات متأثرة، في حين أن 98.5% منها عبارة عن إصدارات أقدم غير متأثرة (راجع شكل). يمكن تفسير هذا الانتشار المنخفض من خلال مراجعة سريعة لوثائق توزيع Linux: فقط الإصدارات الأحدث مثل Ubuntu 22 وRHEL 9 تتضمن OpenSSL 3 في بيانات حزمتها.

ما الذي يجب على فرق الأمن فعله الآن

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

تعريف

حدد الأصول التي تقوم بتشغيل الإصدارات المتأثرة من OpenSSL.

تحديد الأولويات

قم بتحديد أولويات الأصول المتأثرة بالترتيب التالي:

1. الأصول التي تواجه الإنترنت.

2. الأصول ذات المهام الحرجة: الأصول التي تحتوي على بيانات حساسة، وأسرار، وخدمات إنتاج، وما إلى ذلك.

3. الخطوة الثانية: الأصول ذات الامتيازات العالية أو مسارات الحركة الجانبية الأخرى التي تسمح للهجوم بالوصول إلى الأصول والخدمات الحساسة.

4. الأصول المتبقية المتأثرة.

التعاون

يعد التصحيح دائمًا رياضة جماعية، خاصة في البيئات السحابية الأصلية حيث تكون ملكية البنية التحتية لا مركزية.

1. قم بتعيين الأصول المتأثرة على المالكين.

2. اعمل مع المطورين لديك للتأكد من أنهم على دراية بالمشكلة، ويفهمون آثارها المحتملة، وأنهم شركاء لك في هذه العملية.

3. تمتع بعملية واضحة لتفويض الجهود بسهولة إلى الفرق التي تمتلك البنية التحتية المتأثرة وتتبع التقدم.

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

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

استخدم Wiz Threat Center للحصول على قائمة ذات أولوية للأصول المتأثرة

يكتشف Wiz حزم OpenSSL المتأثرة على جميع أعباء العمل السحابية، بما في ذلك الأجهزة الافتراضية والحاويات والوظائف بدون خادم وحتى الأجهزة الافتراضية. بالإضافة إلى ذلك، يمكن للعملاء استخدام Wiz Security Graph لتركيز جهود الإصلاح على أعباء العمل التي تواجه أكبر المخاطر (على سبيل المثال، أعباء العمل التي تتعرض بشكل فعال للإنترنت أو التي يمكنها الوصول إلى الموارد الحساسة).

نحن هنا للمساعدة

نحن هنا للمساعدة! الأمان السحابي هو شغفنا، لذا لا تخجل ولا تتردد في التواصل معنا إذا كانت لديك أي أسئلة أو تعليقات. يمكننا أيضًا المساعدة في توفير فحص كامل لبيئتك بدون وكيل لتحديد أصولك المعرضة للخطر وتحديد أولوياتها. يحظى Wiz بثقة كل من Salesforce، وMorgan Stanley، وBMW، وCostco، وSnowflake، وSlack، وأكثر من 30% من قائمة Fortune 100.

اتصل بنا