الاستجابة لحوادث الاختراق

حالة استخدام

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

الأهداف

بعد استكمال هذا الموضوع الفرعي، يجب أن يكون الممارس قادرًا على القيام بما يلي:

• تحديد نقطة الاختراق الأولية لموقع الويب
• تحديد الإجراءات التي اتخذها المهاجم بعد الاختراق الأولي

العرض

التعرف على حادثة اختراق

بالنسبة لمعظم ضحايا حوادث الاختراق، يمكن أن يكون التأخير بين الاختراق الأولي والكشف أشهرًا أو حتى سنوات، وغالبًا ما يكتشف الاختراق من قبل مهندس يعتقد أن شيئًا ما “يبدو غريبًا”. يمكن أن تشمل بعض علامات الاختراق ما يلي:

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

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

الانتقال من مؤشرات الاختراق إلى الاختراق الأولي

بمجرد التأكد من أن الموقع قد تم اختراقه من خلال واحد أو أكثر من مؤشرات الاختراق (indicators of compromise)، فإن الخطوة التالية هي التحليل الرجعي للعثور على مصدر الاختراق الأولي، وذلك لأجل هدفين:

• تحديد الثغرة الأمنية التي مكنّت المهاجم من اختراق الموقع مما يسمح لمالك الموقع بإصلاح الثغرة الأمنية قبل استعادة الموقع.
• بمجرد العثور على اختراق أولي يمكنك العمل على العثور على الأنشطة التي يقوم بها المهاجم.

ليس الأمر دائمًا أن اختراق موقع الويب يبدأ بوجود ثغرة أمنية في موقع الويب نفسه، ولكن قد يكون هذا أكثر الطرق شيوعًا للاقتحام ولكن يجب ألا تستبعد شيئًا مثل حساب مطوّر مخترق يسمح للمهاجم ببساطة بتحميل باب خلفي أو استخدام تبعية فيها باب خلفي backdoored dependencyكجزء من هجوم سلسلة التوريد.

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

يجب أن تراعي أنه حتى المهاجمين ذوي حد الكفاءة الأدنى يحاولون عادة تغطية مساراتهم، وتشمل بعض التقنيات التي قد يستخدمونها:

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

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

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

• يجب أن تراعي تحليل السجلات وتخزينها بتنسيق أكثر تنظيمًا لتسهيل البحث،
• غالبًا ما يحاول المهاجمون إخفاء هجماتهم من خلال الترميز، لذا ابحث بسرعة في السجلات عن علامات النسبة المئوية (٪) لمعرفة ما إذا كانت هناك بيانات مشفرة لعنوان موقع الويب.
• ابحث عن السلاسل المرتبطة بأنماط الهجوم، ولاحظ أن فاحصات الثغرات الأمنية الآلية على الإنترنت تقوم بالفحص بشكل كامل وعشوائي ولذلك يجب أن تتوقع الكثير من النتائج. إذا عثرت على العديد من النتائج، حاول العثور على أنماط فيما بينها، ويمكن أن تكون الأنماط التي تظهر باستمرار في جميع أنحاء السجلات أقل إثارة للاهتمام. وأكثرها إثارة للاهتمام هي مجموعات من الأنماط المختلفة التي تشترك في عنوان بروتوكول الإنترنت و/أو مجال عناوين بروتوكول الإنترنت و/أو وكيل المستخدم. ويدل ذلك على وجود شخص يختبر الموقع. وتشمل بعض الأنماط المفيدة التي يجب البحث عنها:
  • الطلبات التي تحتوي على أقواس زاوية (< و >) وخاصة السلسلة النصية سكريبت(<script).
  • الطلبات باستخدام محددات جافا سكريبت مثل أون كليك (onClick) وأون ماوس أوفر (onMouseOver) وما إلى ذلك.
  • الطلبات التي تحتوي على السلسلة /.. بداخلها.
  • الطلبات التي تحتوي على علامات اقتباس مفردة و/أو كلمات إس كيو إل رئيسية (select، and، or where، update، delete) فيها
  • الطلبات التي تولد استجابة كبيرة بشكل غير عادي لنقطة النهاية الخاصة بها (على سبيل المثال، عادةً ما ينشئ فهرس المقالة صفحة ويب 30 ألف تولد صفحة 300 ألف.)

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

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

تتبع المهاجم مستقبلًا

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

طرد المهاجم

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

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

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

التعافي من الاختراق

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

إذا تعرضت بيانات المستخدم للاختراق، فقد يُطلب من مالك الموقع قانونًا و/أو أخلاقيًا الكشف عن الخرق، وإدارة ذلك تقع خارج نطاق مسار التعلّم هذا ولكن هذه مقالة يمكن أن تبدأ بها.

الممارسة

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

أكمل تحليل السجل – اختراق ووردبرسLog Analysis – Compromised WordPress على بلو تيم لابز أونلاين (Blue Team Labs Online) (تحتاج إلى حساب مجاني). إذا كنت تواجه أي مشاكل، توجد مقالة لتساعدكa write-up. أكمل تحدي الفريق الأزرق من وب سترايك[WebStrike Blue Team Challenge على سايبر دفندرز (CyberDefenders) (تحتاج إلى حساب مجاني). على الرغم من أن هذا التحدي يتضمن استخدام ملفات الحزم التي تم التقاطها بدلًا من سجلات الويب، تبقى المبادئ هي ذاتها.

اختبار مهارة

استكمل بشكل مستقل أو مع مُرشِد تحدي بلو تيم تومكات تيك أوفرTomcat Takeover Blue Team Challenge في سايبر دفندرز (CyberDefenders) (تحتاج إلى حساب مجاني). يُمثل هذا التحدي سيناريو هجوم بين الأطراف ولكنه يشمل استخدام ملفات الحزم التي تم التقاطها بدلًا من سجلات الويب.

موارد التعلّم