OpenSSL هي مكتبة برمجيات مفتوحة المصدر واسعة الاستخدام لتنفيذ الاتصالات الآمنة عبر شبكات الكمبيوتر. كيف تستخدم على نطاق واسع؟ حسنًا، من المحتمل أنك إذا قمت بالوصول إلى صفحة ويب HTTPS، فقد قمت بذلك عبر تشفير OpenSSL. توفر المكتبة وظائف وبروتوكولات التشفير لتشفير البيانات وفك التشفير والمصادقة والتحقق من التوقيع الرقمي. يمكن العثور على OpenSSL في أي مكان تقريبًا حيث تكون هناك حاجة لتأمين خوادم الويب وخوادم البريد الإلكتروني والشبكات الخاصة الافتراضية (VPN) وأنواع أخرى من اتصالات الشبكة.
بالنظر إلى الفقرة أعلاه، يجب أن يكون واضحًا مدى أهمية OpenSSL للعمل السليم للإنترنت. وهو عنصر حاسم في البنية التحتية الأمنية للعديد من أنظمة وتطبيقات الكمبيوتر. فهو يساعد على حماية البيانات الحساسة من الوصول غير المصرح به ويساعد على ضمان سلامة وصحة اتصالات الشبكة. ولهذا السبب يأخذ القائمون على المكتبة نقاط الضعف على محمل الجد ويحاولون تصحيحها في أسرع وقت ممكن. إن تصور قدرة المهاجمين على الوصول إلى خطوط الاتصال الآمنة للبنية التحتية لشبكة الويب العالمية أمر لا يمكن تصوره تقريبًا.
في هذه المقالة، سنفحص الثغرات الأمنية التي أدت إلى إصدار تصحيح OpenSSL 3.0.7 في أكتوبر 2022، وننظر إلى ما يمكننا تعلمه من الطريقة التي تعامل بها مشرفو OpenSSL مع المشكلة.
نقاط الضعف
في 25 أكتوبر 2022، نشر مشروع OpenSSL تقريرًا استشاري محذرا من أن التصحيح الجديد سيأتي قريبا للتعامل مع البعض حرج نقاط الضعف. تشير العلامة "الحرجة" إلى أنه من المحتمل أن تكون الثغرات الأمنية قابلة للاستغلال وأن سرقة المفاتيح الخاصة و/أو RCE على الخوادم المتأثرة أمر محتمل.
وبعد أسبوع، في الأول من نوفمبر 1، أصدر مشروع OpenSSL كلاً من التصحيح الجديد، 2022، و نقاط الضعف المحددة كانوا يهدفون إلى الإصلاح. وفي الفترة الفاصلة، تم تخفيض تصنيف نقاط الضعف من حرجة إلى "عالية الخطورة".
إذن، ما هي نقاط الضعف هذه؟
CVE-2022-3602 - تجاوز سعة المخزن المؤقت لعنوان البريد الإلكتروني X.509 بمقدار 4 بايت - في التحقق من شهادة X.509، وتحديدًا عند التحقق من قيد الاسم، يمكن أن يحدث تجاوز للمخزن المؤقت بمقدار أربعة بايت. يمكن للمهاجم تجاوز أربع وحدات بايت يتحكم فيها المهاجم في المكدس باستخدام عنوان بريد إلكتروني ضار. قد يحدث عطل (مما يؤدي إلى رفض الخدمة) أو تنفيذ تعليمات برمجية عن بعد بسبب تجاوز سعة المخزن المؤقت. في البداية، تم تصنيفها على أنها حرجة ولكن الاختبارات الإضافية أظهرت أن العديد من الأنظمة الأساسية تستخدم وسائل حماية تجاوز سعة المكدس لتقليل مخاطر تنفيذ التعليمات البرمجية عن بعد.
CVE-2022-3786 - تجاوز سعة المخزن المؤقت لعنوان البريد الإلكتروني X.509 - في التحقق من شهادة X.509، وتحديدًا عند التحقق من قيد الاسم، يمكن أن يحدث تجاوز في المخزن المؤقت. يمكن للمهاجم إنشاء عنوان بريد إلكتروني ضار في الشهادة لملء المكدس بأي عدد من وحدات البايت التي تحتوي على الحرف "."، وهو الرقم العشري 46. قد يحدث عطل نتيجة لتجاوز سعة المخزن المؤقت هذا (مما يتسبب في حدوث خطأ الحرمان من الخدمة).
فقط لأكرر مدى خطورة نقاط الضعف هذهأصدرت CISA، وكالة الأمن السيبراني وأمن البنية التحتية الأمريكية، بيانًا استشاري في نفس يوم OpenSSL، مشجعًاging المستخدمين والمسؤولين لمراجعة توثيق OpenSSL والترقية، حيثما ينطبق ذلك، إلى التصحيح الجديد 3.0.7.
كما ناقشنا سابقًا، فإن RCE (تنفيذ التعليمات البرمجية عن بعد) على أنظمة التشغيل أو خوادم البريد التي تقوم بتشغيل OpenSSL سيكون سيئًا للغاية لذا فمن المنطقي الكشف فقط عن نقاط الضعف بمجرد العثور على التصحيح المناسب وتقديمه.
ماذا سيحدث بعد ذلك
بمجرد نشر الاستشارة الأولية، بدأ الناس يتدافعون. كانت عبارة "لا داعي للذعر" عبارة شائعة في الموعد يُظهر مدى جدية الناس في التعامل مع الأخبار التي تنتقد OpenSSL نقاط الضعف.
بمجرد نشر الاستشارة، كان جميع أصحاب المصلحة المعنيين يجتهدون لمعرفة إصدار OpenSSL الذي تم استخدامه في الخادم ونظام التشغيل والتطبيقات والحزمة وما إلى ذلك. وبعيدًا عن الاستخدام الداخلي لـ OpenSSL فقط، كان الأشخاص بحاجة أيضًا إلى معرفة ما إذا كان أي من إصداراتهم الثالثة كان بائعو الطرف أو مقدمو الخدمات يستخدمون إصدار OpenSSL الضعيف. في ذلك الوقت، إذا لم تكن متأكدًا من الإصدار الذي كنت تستخدمه أو لم تكن متأكدًا من الإصدار الذي يستخدمه البائعون ومقدمو الخدمات، فقد كان من الآمن أخذ تطبيق ما في وضع عدم الاتصال بدلاً من المخاطرة بـ RCE المحتمل.
نظرًا لأن الاستشارة أعطت الجدول الزمني للتصحيح مسبقًا، مما أعطى الأشخاص الوقت الكافي للتعرف على البنية التحتية الخاصة بهم والبنية التحتية الخاصة ببائعيهم ومقدمي الخدمات. كانت الفكرة هي تخطيط كل ما هو مطلوب فيما يتعلق بالبنية التحتية المعنية بحيث يمكن إجراء الترقية، إذا لزم الأمر، بمجرد إصدار التصحيح.
كيف يمكنك التعامل معها؟
لنفترض الآن أنك مهندس في شركة تستخدم، على حد علمك، OpenSSL في خوادمها. بمجرد انتهاء الاستشارة، يتعين عليك معرفة إصدار المكتبة الذي يتم استخدامه (بما في ذلك أي كود قديم إذا كان لا يزال قيد التشغيل) ثم تحديد نفس الشيء لأي من البائعين أو مقدمي الخدمة لديك.
هذا هو المكان الذي يوجد فيه ملف سبوم يمكن أن يكون مفيدًا حقًا. يرمز SBOM إلى قائمة المواد البرمجية وهي قائمة بجميع المكونات وتبعيات البرامج التي تشكل منتجًا برمجيًا معينًا. يتضمن SBOM عادةً معلومات مثل أسماء وإصدارات جميع مكونات البرامج (انظر إلى أين سأذهب بهذا)، ومصادرها وتراخيصها، وأي نقاط ضعف معروفة أو مشكلات أمنية مرتبطة بكل مكون.
إذا كنت، كمهندس مسؤول، تتأكد من وجود SBOM محدث لكل منتج من منتجاتك، فإن العثور على المكان الذي كنت تستخدم فيه OpenSSL والإصدار الذي كان قيد الاستخدام سيكون أمرًا بسيطًا يتمثل في إجراء بحث في ملف SBOM . إذا تأكدت أيضًا من طلب SBOMs المحدثة من أي بائع أو مزود خدمة كانت شركتك تعمل معه، فيمكنك إجراء نفس البحث هناك أيضًا.
نظرًا لأنه تم إخبارك أن الثغرات الأمنية كانت تؤثر فقط على الإصدارات بين 3.0.0 و3.0.6، فكل ما عليك فعله هو التحقق من الإصدارات التي كنت تقوم بتشغيلها لمعرفة التطبيقات التي تحتاج إلى إزالتها أو تحديثها باستخدام التصحيح الجديد - 3.0.7. XNUMX.
فقط لإظهار مدى اتساع قائمة أنظمة التشغيل وتطبيقات المؤسسات المعروفة التي تستخدم OpenSSL، راجع هذا الإدارية تم نشرها كخدمة عامة حتى يعرف الناس مدى القلق الذي يجب أن يشعروا به.
كيف يمكن لمركز الأمان المبني على الأدلة أن يساعدك
كجزء من مشهد الأمن السيبراني المتطور، بما في ذلك بعيدة المدى نقاط الضعف، نشهد حاليا تطور أمن التطبيقات إلى أمن سلسلة توريد البرمجيات. لقد تم تطوير جيل جديد من الأدوات والتقنيات لمحاولة حل هذه المشكلات. من خلال تقديم نظام أساسي مستمر لضمان أمان التعليمات البرمجية قائم على الأدلة ويمكنه ضمان موثوقية دورة حياة تطوير البرامج ومكونات البرامج، تساعد الأدوات والحلول الآلية المؤسسات في تحقيق مستوى جديد من الأمان. يؤدي تحديد التبعيات ونقاط الضعف بشكل مستمر إلى تسهيل معالجة التصحيحات أو تطبيقها عندما تصبح متاحة.
كاتب هو مركز أمان سلسلة توريد البرمجيات. فهو يجمع الأدلة ويقدمها لكل بنية تمر عبر خط أنابيب CI/CD الخاص بك. كان الهدف من حل Scribe هو تسهيل الالتزام بلوائح الاتحاد الأوروبي والولايات المتحدة وأفضل الممارسات لتعزيز شفافية البرامج وتعزيز الثقة بين مطوري البرامج والمستخدمين. تتيح المنصة إمكانية إنشاء ومشاركة SBOMs شاملة بالإضافة إلى رؤى أمنية أخرى. بالإضافة إلى ذلك، يمكن للنظام التأكد من أن الإصدار الذي تشاهده يتوافق مع إطار عمل SSDF الخاص بـ NIST ومتطلبات المستوى 3 من SLSA. لم يعد عليك أن تتخبط في محاولة معرفة المكان الذي تستخدم فيه أي إصدار من المكتبة لأن لديك مخزن أدلة يحتوي على SBOM لكل من بنياتك. الآن، أصبح اكتشاف ذلك أمرًا بسيطًا مثل البحث عن جملة معينة في مستند نصي.
كلمة أخيرة: كن مستعدًا للكشف الكبير التالي عن الثغرة الأمنية
تقدم لنا قصة مشروع OpenSSL للتصحيح 3.0.7 وجهتي نظر متساويتين في الأهمية حول كيفية التعامل مع الثغرات الأمنية المحتملة.
من الجانب المتضرر – الشركة أو المشروع الذي من المحتمل أن يكون قد تعرض للخطر بسبب نقاط الضعف هذه، فقد قمنا بإبلاغ الشفافية. إنهم لا يكشفون على الفور عن المعلومات التي قد تسبب الضرر، لكنهم يكشفون عن كل ما في وسعهم بمجرد علمهم بوجود مشكلة. ليس فقط أنهم يقدمون أيضًا جدولًا زمنيًا للمعالجة بالإضافة إلى أكبر قدر ممكن من المعلومات حول المشكلة. بمجرد وجود التصحيح أو العلاج، لم يخجلوا من الكشف بالضبط عن الخطأ وكيف يمكن استغلاله. وهذا النوع من الشفافية يشجع الثقة. يريد المستخدمون والعملاء أن يعرفوا ويشعروا أن الشركة تهتم بهم أكثر، أو على الأقل بنفس القدر، كما تفعل بالنسبة للنتيجة النهائية أو لمجلس إدارتها.
في عام 2014، وقع مشروع OpenSSL ضحية لخلل فادح أطلق عليه اسم "ذو قلب"- ثغرة خطيرة في تطبيق TLS/DTLS الخاص بـ OpenSSL والتي مكّنت المهاجم من الحصول على أسرار مثل مواد مفتاح التشفير وكلمات المرور وغيرها من المعلومات الحساسة من الخوادم المتأثرة. أظهر Heartbleed ما يمكن أن تفعله الثغرة الأمنية الخطيرة في OpenSSL حيث أثرت على مجموعة واسعة من البرامج وتوزيعات Linux. إن محاولة تحديد وإصلاح كل نظام ضعيف قد سببت لفرق الأمن أشهرًا من الصداع. إن تنفيذ أداة، مثل SBOM، التي يمكن أن تجعل تحديث برنامجك وتصحيحه أسرع وأبسط، سيكون بمثابة نعمة لفريق الأمن السيبراني في أي شركة.
من الجانب العلاجي - معرفة ما يجب عليك العمل معه بالضبط - أي إصدار من الحزم التي تستخدمها هو أمر ضروري لتكون قادرًا على التعامل مع أي حالة طوارئ محتملة من هذا القبيل. لنأخذ Log4J كمثال - لا تزال بعض الشركات تحاول معرفة ما إذا كانت متأثرة بهذه الثغرة الأمنية بعد مرور أكثر من عام على اكتشافها.
حقيقة أن برامجك وخوادمك ليست فقط ما تحتاج إلى القلق بشأنه، بل إنها أيضًا برامج وخوادم أي موردين خارجيين تستخدمهم، أو أي مزودي خدمة تعمل معهم، حتى باستخدام اتصالات API، يعني أننا جميعًا منا، بحاجة حقًا إلى بناء شبكة من الثقة بيننا. ويجب أن تعتمد هذه الثقة قدر الإمكان على أدلة دامغة. قم بإنشاء وتتبع SBOMs الخاصة بك وتلك الخاصة بأي شركة تعمل معها، وشارك تلك SBOMs، وأظهر حسن النية في الإعلان عن أي ثغرة أمنية قابلة للاستغلال تكون على علم بها وإصلاحها.
سيتطلب الأمر منا جميعًا العمل معًا للوصول إلى عالم حيث تكون مشاركة مثل هذه الأدلة أمرًا شائعًا مثل مشاركة أحدث العلاقات العامة للشركة على وسائل التواصل الاجتماعي. وبدون هذه الثقة، فإننا نمهد الطريق للثغرة الحرجة الكبيرة التالية التي ستؤدي إلى تفكيك البنية التحتية المترابطة التي نعمل جميعًا بجد للحفاظ عليها.
يتم تقديم هذا المحتوى إليك بواسطة Scribe Security، وهي شركة رائدة في مجال توفير حلول أمان سلسلة توريد البرامج الشاملة - حيث توفر أحدث الأمان لعناصر التعليمات البرمجية وعمليات تطوير التعليمات البرمجية وتسليمها عبر سلاسل توريد البرامج. تعرف على المزيد.
الوظائف ذات الصلة
