حشرة Heartbleed – البق القديمة تموت بشدة

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

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

قصة Heartbleed

كما هو الحال مع العديد من الثغرات الأمنية الخطيرة ، لم يتم اكتشاف Heartbleed على الفور. تم إدخال هذا الخلل الأمني ​​في إصدار 1.0.1 من مكتبة OpenSSL في عام 2012 مع ملحق Heartbeat. كانت الإصدارات الضعيفة من OpenSSL هي OpenSSL 1.0.1 إلى 1.0.1f.

تم الكشف عن الثغرة الأمنية بعد ذلك بعامين (في أبريل 2014) من قبل باحثين أمنيين من Google وشركة أمن مستقلة تسمى Codenomicon ، وتم تصنيفها لاحقًا على أنها CVE-2014-0160. لمدة عامين ، كان الخطأ سرًا وربما لن نعرف أبدًا ما إذا كان أي شخص قد استفاد منه في ذلك الوقت.

تم إصلاح Heartbleed بواسطة مطوري برنامج OpenSSL بسرعة كبيرة – في غضون أسبوع كان هناك إصدار OpenSSL 1.0.1g وكان كل ما يتطلبه الأمر مجرد تحديث برنامج لجميع الخوادم المتأثرة. ومع ذلك ، كان هذا مجرد دليل واحد على مدى صعوبة تحديث البرامج المنتشرة على نطاق واسع – استخدمت معظم تطبيقات TLS على الإنترنت مكتبة OpenSSL (لحسن الحظ ، وليس Microsoft) ، بما في ذلك Apache و nginx بالإضافة إلى بعض الأجهزة من شركات مثل مثل Cisco و Apple. أثرت الثغرة الأمنية أيضًا على مواقع مثل Yahoo.

كيف يعمل Heartbleed

لفهم Heartbleed ، يجب علينا أولاً أن نفهم Heartbeat.

Heartbeat هو امتداد لمكتبة OpenSSL. مكتبة OpenSSL هي مشروع مفتوح المصدر لتنفيذ طبقة النقل الآمنة وطبقة المقابس الآمنة (SSL / TLS) وكذلك DTLS. تُستخدم هذه المكتبة من قبل معظم البرامج الأخرى التي تتطلب TLS للاتصالات الآمنة ، على سبيل المثال ، خوادم الويب وخوادم البريد والمزيد.

تم تقديم ملحق Heartbeat للتحقق مما إذا كان اتصال TLS لا يزال متاحًا. إنها آلية بسيطة للغاية: يرسل العميل رسالة خاصة تسمى a رسالة نبضات القلب إلى الخادم. تحتوي هذه الرسالة على بيانات وتحديد حجمها. استجابةً لذلك ، من المتوقع أن يرسل الخادم نفس طلب نبضات القلب بنفس البيانات ونفس حجم البيانات. تم اقتراح هذه الآلية في RFC 6520.

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

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

1. طلب العميل: 1 بايت من البيانات الحقيقية ، الحجم المعلن: 200 بايت.
2. استجابة الخادم: 200 بايت من البيانات (1 بايت أصلي + 199 بايت من الذاكرة المجاورة) ، الحجم: 200 بايت.

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

أسباب استمرار الحشرات القديمة

يعد استمرار حشرة Heartbleed فرصة جيدة لتحليل سبب صعوبة التخلص من الحشرات القديمة. فيما يلي بعض الأسباب الشائعة:

• يتم استخدام البرامج الضعيفة في أحد الأجهزة. ربما يكون هذا هو السبب الرئيسي وراء عدد النتائج في تقرير شودان المذكور في بداية هذه المقالة. تستخدم العديد من أجهزة إنترنت الأشياء OpenSSL للتعامل مع TLS وهذه الأجهزة التي تم تقديمها بين عامي 2012 و 2014 ستكون عرضة لـ Heartbleed. قد لا يكون لدى بعضها تحديثات للبرامج الثابتة على الإطلاق وفي حالة الآخرين ، قد يختار مالكو الأجهزة عدم القيام بمثل هذه التحديثات.
• تستخدم الشركة إصدارًا مخصصًا من البرامج المعرضة للخطر. في حالة Heartbleed ، فإن OpenSSL هي مكتبة مفتوحة المصدر وربما قامت بعض الشركات بتعديلها لأغراضها. في مثل هذه الحالات ، لا يكون التصحيح المباشر ممكنًا – يجب على الشركة بعد ذلك إعادة تقديم كودها المخصص في الإصدار الجديد من المكتبة. غالبًا ما يكون هذا هو السبب في عدم تحديث برامج الويب مفتوحة المصدر مثل WordPress على الفور من قبل الشركات حتى إذا تم العثور على أخطاء جديدة خطيرة.
• إهمال بسيط – قد لا تدرك الشركات الصغيرة ببساطة أن البرنامج الذي تستخدمه يحتاج إلى تحديث أمني لأنه لا تحتوي جميع البرامج على تحديثات تلقائية. على سبيل المثال ، إذا استأجروا شركة خارجية لإعداد خادم ويب ثم لم يقم أحد بإدارته ، فلن يعرفوا أي شيء عن تأمينه.
• تقييم المخاطر – قد تقرر بعض الشركات أن مخاطر التعرض للاختراق والتداعيات المحتملة لا تستحق عناء تطبيق التحديث الأمني. على سبيل المثال ، قد يكون لأصل الويب أهمية تجارية قريبة من الصفر ، ولا يرتبط بأي شكل من الأشكال بأصول أخرى ، ولا يحمل أي بيانات حساسة على الإطلاق.
• عبء العمل الزائد والأولويات – إذا كان لدى الشركة الكثير من نقاط الضعف في البرامج التي يجب التعامل معها وفريقًا محدودًا لإصلاحها ، فمن الضروري تحديد الأولويات وقد يتم تأجيل بعض الأخطاء لفترة طويلة لمجرد أنها لا تعتبر مانعات. هذه حقيقة تواجهها العديد من شركات تطوير الويب – غالبًا ما تتجاوز الأخطاء الأمنية الجديدة تلك التي تم إصلاحها في إطار زمني معين.

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