صحائف الغش الأمن: الترقيع الظاهري

موضوع مقالتنا اليوم هو Virtual Patching.

Virtual Patching هي طبقة سياسة أمان مصممة لكشف ومنع استغلال الثغرات الأمنية المعروفة.

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

فلماذا التصحيح الظاهري ، لماذا ليس فقط تحديث التعليمات البرمجية؟

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

فوائد التصحيح الظاهري هي كما يلي:

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

عيوب التصحيح الظاهري:

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

يمكن تقسيم الاستعداد للتصحيح الظاهري إلى الخطوات التالية:

1. تدريب
2. تحديد التهديد
3. تحليل
4. إنشاء التصحيح الظاهري
5. التنفيذ والاختبار
6. الانتعاش / استمرار العمل

الضعف العام

على سبيل المثال ، خذ حقن SQL و ModSecurity WAF (منذ المصدر المفتوح).

WordPress Shopping Cart Plugin  WordPress /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php  reqID   SQL Injection. 

يحتوي WordPress Shopping Cart Plugin لـ WordPress على خلل قد يسمح للمهاجم بتنفيذ حقنة SQL. تكمن المشكلة في البرنامج النصي /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php ، حيث لا يتم تعقيم المعلمة reqID بشكل صحيح.

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

مرحلة الإعداد

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

فيما يلي بعض النقاط المهمة التي يجب تغطيتها أثناء الإعداد:

• مراقبة نقاط الضعف من البائع أو من المصادر العامة - إذا كنت تستخدم برنامجًا تابعًا لجهة خارجية ، فتأكد من أنك مشترك في جميع مراسلات الطوارئ من الموردين. سيساعدك هذا على تحديث آخر المستجدات في نقاط الضعف التي تواجه برامجك والتصحيحات ذات الصلة.
• قم بإعداد جميع الأعمال اللازمة مقدمًا للسماح بإدخال تصحيحات افتراضية في عملية الإنتاج - يجب إنشاء تصحيحات افتراضية بسرعة ، وبالتالي فإن عملية التحقق المعتادة للبقع لن تعمل هنا. نظرًا لأن التصحيحات الافتراضية لا تغير الشفرة المصدرية ، فإنها لا تتطلب نفس القدر من الاختبار مثل تصحيحات البرامج العادية. يجدر أن نعزو التصحيحات الافتراضية إلى نفس الفئة مثل تحديثات برامج مكافحة الفيروسات أو تحديثات التوقيع لمعرفات الهوية. سيؤدي هذا إلى تسريع عملية طرحها بشكل كبير في الإنتاج.
• أدخل الأدوات المساعدة للتصحيح الافتراضي مقدمًا - نظرًا لأن المعيار الرئيسي للتصحيح الافتراضي هو السرعة ، ثم تثبيت برنامج جديد إذا كنت بحاجة إلى تصحيح للطوارئ ، هي فكرة سيئة.
• زيادة التسجيل لأنظمتك - معيار السجل الذي تستخدمه معظم الخوادم الافتراضية (CLF) لا يوفر بيانات كافية للاستجابة للحوادث بشكل صحيح. يجب أن يكون لديك حق الوصول إلى البيانات التالية:
  
  U طلب URI (بما في ذلك QUERY_STRING)
  ◦ كل رؤوس الطلبات (بما في ذلك ملفات تعريف الارتباط)
  body طلب كامل الجسم (بما في ذلك حمولة ما بعد)
  response رؤوس استجابة كاملة
  response هيئة استجابة كاملة

مرحلة الكشف عن التهديد

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

نهج استباقي

الحالة التي تتولى فيها المؤسسة أعمال الأمان وتؤدي المهام التالية:

• التقييم الديناميكي للتطبيق - يتم تنفيذ عمليات اختبار pentests و / أو التقييم التلقائي على تطبيق ويب قيد التشغيل لتحديد أوجه القصور.
• مراجعة الشفرة المصدرية - يتم إجراء تقييم يدوي و / أو تلقائي للشفرة المصدرية لتطبيق الويب لاكتشاف أوجه القصور.

النهج التفاعلي

هناك ثلاث طرق تفاعلية رئيسية لتحديد نقاط الضعف:

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

مرحلة التحليل

الخطوات الموصى بها لمرحلة التحليل:

• حدد مدى ملائمة الترقيع الظاهري لحالتك - إنه أمر رائع لإغلاق أوجه القصور المتعلقة بالإدخال (أي الحقن) ، ولكن قد لا يوفر مستوى حماية مناسبًا لهجمات الأنواع أو الفئات الأخرى. يجب إجراء تحليل مفصل وشامل للمشكلة الأساسية لتحديد ما إذا كان برنامج التصحيح الافتراضي سيوفر مستوى مناسبًا من الكشف والتغطية.
• إشراك أنظمتك لتتبع الأخطاء / المهام - أدخل معلومات الثغرات الأمنية في متتبعك لمزيد من التتبع والتحقيق.
• تحقق من الثغرة الأمنية - ابحث عن الاسم الرسمي للثغرة الأمنية ، إن وجد. إذا تم اكتشافه بطرق استباقية ، فعليك أن تعطيه رقمًا فريدًا / اسمًا فريدًا.
• حدد مستوى الخطر - من المهم دائمًا فهم مدى أهمية تأثير استغلال هذه الثغرة الأمنية بالنسبة لك. على سبيل المثال ، ما إذا كان سيكون تسرب معلومات أو الوصول إلى قاعدة البيانات.
• تحديد إصدارات البرامج التي هي في خطر - من المهم أن نفهم ما إذا كنت في خطر أو ليست في خطر.
• حدد تحت تكوينات البرنامج التي قد تنشأ عنها مشكلة - يمكن أن تظهر بعض الثغرات الأمنية فقط مع تكوينات معينة من البرنامج.
• قم بإعداد قائمة من Proof of Concept يستغل أو الحمولات المستخدمة أثناء الهجوم / الاختبار - العديد من منشورات الضعف مصحوبة برمز PoC الذي يوضح الضعف. إذا كانت هذه البيانات متاحة ، فقم بتحليلها. سيكون هذا مفيدًا في تطوير واختبار تصحيح افتراضي.

مرحلة إنشاء التصحيح الظاهري

ترتبط عملية إنشاء تصحيح افتراضي جيد بجانبين:

• لا ايجابيات كاذبة - لا تمنع حركة المرور العادية على الرغم من الظروف
• بدون ايجابيات كاذبة - لا تفوت أي هجوم ، حتى عندما يحاول المهاجم تجنب الاكتشاف.

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

دليل إنشاء التصحيح الظاهري
نهج إيجابي (القائمة البيضاء ، القائمة البيضاء) في التصحيح الظاهري

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

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

مثال

في هذه الحالة ، يجب أن تحتوي المعلمة reqID على أعداد صحيحة فقط حتى نتمكن من تطبيق هذا التصحيح الظاهري:

 # # ,     1    "reqID" # SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter - Duplicate Parameters Names Seen.',logdata:'%{matched_var}'" SecRule &ARGS:/reqID/ "!@eq 1" # # ,   reqID     # SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:2,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'" SecRule ARGS:/reqID/ "!@rx ^[0-9]+$" 

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

النهج السلبي (القائمة السوداء ، القائمة السوداء) في التصحيح الظاهري

يعتمد هذا النهج على قائمة القواعد التي تحدد بعض الهجمات المعروفة بدلاً من السماح فقط بحركة مرور صالحة.

مثال على إنشاء تصحيح افتراضي يستند إلى القائمة السوداء في ModSecurity

على سبيل المثال ، رمز PoC من مصدر عام:

 http://localhost/wordpress/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php?reqID=1' or 1='1 

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

 SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'" SecRule ARGS:/reqID/ "@pm '" 

احذر من إنشاء تصحيحات افتراضية لمآثر محددة

بالطبع ، هذا يبدو جذابا وتوفير الوقت. على سبيل المثال ، إذا عثر pentest على XSS على صفحتك واستخدم الحمل التالي:

 <script> alert('XSS Test') </script> 

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

إنشاء بقع افتراضية تلقائيًا

يمكن أن يصبح إنشاء التصحيح اليدوي أمرًا لا يطاق نظرًا لتزايد عدد نقاط الضعف وتصبح الأتمتة خطوة ضرورية. إذا تم اكتشاف الثغرات الأمنية باستخدام الأدوات الآلية (على سبيل المثال ، ماسحات الضعف) ، فقد يكون من الممكن تحويل تقارير هذه الأدوات إلى تصحيحات. أكثر أدوات أتمتة التصحيح شيوعًا هي الاستيراد المباشر إلى WAF (بشكل طبيعي ، إذا كان الحل الخاص بك يدعم هذا) ، والبرامج النصية لمجموعة قواعد OWASP ModSecurity الأساسية (CRS) ، و ThreadFix Virtual Patching.

مرحلة التنفيذ والاختبار

لاختبار التصحيح الافتراضي الجديد الخاص بنا بشكل صحيح ، قد نحتاج إلى الأدوات التالية:

• متصفح الويب
• أدوات الويب المساعدة للأجهزة الطرفية (مثل curl and wget)
• الوكيل المحلي
• ModSecurity AuditViewer

الخطوات التالية:

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

مرحلة الانتعاش / الاستمرارية

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