ثغرة أمنية جديدة في البروتوكول ستطارد الويب لسنوات 

ثغرة أمنية جديدة تطال بروتوكول الويب لعدة سنوات قادمة ، ويتطلب هذا الخلل، الذي يطلق عليه اسم "HTTP/2 Rapid Reset"، إصلاح الخرق الأمني لكل خادم ويب تقريبًا حول العالم قبل القضاء على المشكلة. كشفت شركات Google وAmazon وMicrosoft وCloudflare هذا الأسبوع أنها واجهت هجمات مكثفة ومسجلة لرفض الخدمة الموزعة ضد بنيتها التحتية السحابية في شهري أغسطس وسبتمبر. تمثل هجمات DDoS، التي يحاول فيها المهاجمون إغراق الخدمة بحركة مرور غير مرغوب فيها لإسقاطها، تهديدًا كلاسيكيًا على الإنترنت، ويعمل المتسللون دائمًا على تطوير استراتيجيات جديدة لجعلها أكبر أو أكثر فعالية.

 

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

 

كتب إميل كينر وتيم أبريل من Google Cloud هذا الأسبوع "قد يمتد وقت التعافي من هجمات DDoS إلى ما بعد نهاية الهجوم". فالوجه الآخر للوضع لمصدر الضعف انه لا توجد ميزة Rapid Reset في برنامج معين، ولكنها توجد في مواصفات بروتوكول الشبكة HTTP/2 المستخدمة لتحميل صفحات الويب. تم تطوير HTTP/2 بواسطة فريق عمل هندسة الإنترنت IETF))، وهو موجود منذ حوالي ثماني سنوات وهو الوريث الأسرع والأكثر كفاءة لبروتوكول الإنترنت الكلاسيكي HTTP.  يعمل HTTP/2 بشكل أفضل على الهاتف المحمول ويستخدم نطاقًا تردديًا أقل، لذلك تم اعتماده على نطاق واسع جداً. تعمل IETF حاليًا على تطويرHTTP/3.  بالنظر إلى أن الهجوم يستغل نقطة ضعف أساسية في بروتوكول HTTP/2، فإننا نعتقد أنه يجب على جميع خوادم الويب تحديث بروتوكولاتها لحماية نفسها من هذه الثغرة الأمنية فإننا نعتقد أن أي صاحب موقع قام بتطبيق HTTP/2 سيكون عُرضة للهجوم.

كتب لوكاس باردو وجوليان ديسجاتس من Cloudflare هذا الأسبوع. وعلى الرغم من أنه يبدو أن هناك أقلية من التطبيقات التي لم تتأثر بإعادة التعيين السريع، يؤكد باردو وديسجاتس على أن المشكلة ذات صلة على نطاقٍ واسع بـ"كل خادم ويب حديث". على عكس خطأ Windows الذي يتم تصحيحه بواسطة Microsoft، أو خطأ Safari الذي يتم تصحيحه بواسطة Apple، فإن الخلل في البروتوكول لا يمكن إصلاحه بواسطة كيان مركزي واحد، لأن كل موقع ويب ينفذ المعيار بطريقته الخاصة. عندما تقوم الخدمات السحابية الرئيسية ومقدمو خدمات دفاع DDoS بإنشاء إصلاحات لخدماتهم، فإن ذلك يقطع شوطًا طويلًا نحو حماية كل من يستخدم البنية التحتية الخاصة بهم.

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

يقول لورينك: "من المهم أن نلاحظ أن شركات التكنولوجيا الكبرى اكتشفت هذا بينما كان يتم استغلاله بشكل نشط." يمكن استخدامه لإيقاف خدمة مثل التكنولوجيا التشغيلية أو التحكم الصناعي. هذا مخيف. على الرغم من أن سلسلة هجمات DDoS الأخيرة على Google وCloudflare وMicrosoft وAmazon أثارت ناقوس الخطر لكونها كبيرة جدًا، إلا أن الشركات تمكنت في النهاية من صد الهجمات، التي لم تسبب أضرارًا دائمة. ولكن بمجرد تنفيذ الهجمات، كشف المتسللون عن وجود ثغرة أمنية في البروتوكول وكيف يمكن استغلالها - وهو السبب والنتيجة المعروفة في مجتمع الأمن باسم "استغلال ثغرة".