مقدمة عن مطاردة هجمات الاستطلاع السيبرانية عبر سجلات الاحداث

 

للكشف عن نشاطات سيبرانية مشبوهة على أنظمة تشغيل ويندوز مرتبطة بهجمات الاستطلاع (Reconnaissance) ولعمل مطاردة للتهديدات (Threat Hunting)، يلزم بشكل مبدئي بالتفتيش بسجلات الاحداث (event viewer) ضمن قسم سجلات الحماية (Security Event Log) على سجلات تحمل الارقام التالية:

·       Event ID 4624: Successful logon events

·       Event ID 4625: Failed logon events

·       Event ID 4634: Successful logoff events

·       Event ID 4647: User initiated logoff events

ايضا في حال كان Sysmon مفعل ويقوم بحفظ سجلات، يلزم البحث عن سجلات اضافية على النحو التالي:

·       Event ID 1: Process creation events

·       Event ID 3: Network connection events

·        Event ID 7: Image load events

·       Event ID 8: CreateRemoteThread events

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

وبعد يجب توثيق تفاصيل الحادثة بما يشمل كيفية اكتشاف الاختراق، والاجراءات التي تمت واستخراج مؤشرات الاختراق (IoCs).

 ثغرة خطيرة في Google Chrome

 

أكتشف مؤخرا ثغرة خطيرة في متصفح Google Chrome تسبب في الحاق الضرر على الأنظمة المخترقة على مستوى سرية المعلومات (confidentiality) وسلامة المعلومات (integrity) وكذلك التوافرية (availability). الثغرة سببها برمجية ضمن المتصفح  متعلقة بجزئية (Animation).

تكمن الخطورة الثغرة بسهولة استغلالها كونها لا تتطلب عمل مصادقة (authentication)، يحث يستطيع المخترق ادخال معلومات تتسبب في احداث خلل في ذاكرة الجهاز المخترق (memory corruption).

الثغرة تحمل رقم (CVE-2022-0609) ومسماها use-after-free in Chrome’s Animation component، يمكن تلافي هذه الثغرة من خلال تحديث نسخة المتصفح للنسخة رقم 98.0.4758.102.

الثغرة الخطيرة "Apache Log4Shell"

CVE-2021-44228

"Apache Log4Shell"

الثغرة الخطيرة جدا

يمكن استغلال هذه الثغرة من أجل تنفيذ أوامر على نظام معين عن بعد (unauthenticated remote code execution "RCE") تمكّن من السيطرة الكاملة على النظام المخترَق.

يتم استغلال خاصية (Java Naming and Directory Interface) أو JNDI لتحميل ملف يحتوي على برمجية تسبب السيطرة على النظام وتنفيذ أوامر بصلاحيات عالية عن طريق تحويل ملف لتكوين object باستخدام خاصية Java deserialization .يُستغل هذا الـ object لتكوين malicious code على الجهاز المخترق.

الـ JNDI عبارة عن Java API يتيح الربط مع خدمات الاسماء والأدلة naming and directory services للاستعلام عن المعلومات data والمصادر resources عبر عدة وسائل منها بروتوكول LDAP وبروتوكول DNS كما في الشكل بالأسفل. من الأشياء التي يمكن الاستعلام عنها هو URI يؤشر على Java class يحتوي على خورازميات تنفيذية.

يتيح JNDI شمول متغيرات variables ضمن نص الرسالة للحدث بحيث يقوم بالاستعلام عن قيمة المتغير (مثلا اسم المستخدم أو اسم الجهاز) عبر أحدى الوسائل المتوفرة لديه. يعمل على النظام المصاب بهذه الثغرة خدمة او مجموعة من الخدمات (مثلا web server firewall، وغيرهما)، الخدمة العاملة تقوم بتسجيل الاحداث من خلال النظام LOG4J الذي يعمل من خلال JNDI.

يقوم المخترق بارسال طلب HTTP Get ويضمن في جزء user-agent متغير يشير لمصدر على خادم الـ LDAP. خادم الـ LDAP هو ضمن منطومة المخترق وتحت إدارته وعليه ملفات تخريبية (malware) حسب الشكل بالأسفل.

سيقوم الـ JNDI بارسال طلب لخادم الـ LDAP لاستعلام عن المصدر المطلوب والذي بدوره سيجيب الطلب بارسال الملف الذي يحتوي على الاوامر التنفيذية بعد تحويل محتوي الملف ل object.

تعريف الـ OSPF Throttling

 

تعريف الـ OSPF Throttling

يقوم بروتوكول الـ  OSPF بإرسال رسائل تحديث عند حدوث تغيير في الشبكة، مما يتسبب بتغيير على قاعدة بيانات البروتوكول LSDB عند الراوترات التي وصلها رسائل التحديث OSPF LSA، وهذا يؤدي إلى قيام الراوتر بإجراء عمليات احتساب المسارات للشبكات نتيجة للتغيرات الحاصلة وخصوصا في الحالات التي تكون فيها وضعية الشكبة غير مستقرة. لكي يتجنب الراوتر إجهاد المعالج في إجراء عمليات الحساب بسبب ورود أكثر من تحديث متتالي، يقوم الراوتر بجدولة هذه العملية من خلال انتظار فترة من الزمن قبل الشروع بعملية الحساب. يطلق على هذه الخاصية إسم OSPF Throttling، تقوم هذه الخاصية بتأخير بدء عملية الحساب لفترة محددة او تباعد الفترات بين عمليات الاحتساب المتتالية كلما ورد رسالة تحديث OSPF LSA.

يتم ضبط عمل خاصية OSPF Throttling من خلال ثلاثة ضوابط زمنية لكي لا تمتد فترة التأخير لفترات طويلة، وهذه الضوابط هي:

-         spf-start هي الفترة الزمنية الأولية التي ينتظرها الرواتر قبل الشروع في أول عملية حساب.

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

-         spf-max-wait وهي أقصى مدة ممكنة ينتظرها الراوتر بين عمليتي حساب متتاليتين.

لو افترضنا أن الرواتر استلم رسالة تحديث OSPF LSA فإنه سينتظر مدة spf-start 5 ثواني (على سبيل المثال) قبل بدء عملية حساب المسارات للوضع الحالي بعد التغيير، بعد تشغيل عملية الحساب وانتهائها سينتظر الراوتر مدة spf-hold (نفترض قيمتها هو 10 ثواني) قبل بدء العملية مرة أخرى في حال ورود رسالة تحديث جديدة تستدعي تشغيل العملية من جديد، هنا سينتظر الراوتر مدة spf-hold الحالية (10 ثواني) قبل الشروع بالحساب، وستتضاعف المدة لتصبح (20 ثانية)، ستبقى تتضاعف هذه المدة ما دام الأمر يستلزم تشغيل عملية الحساب. لكن أقصى قيمة يمكن أن تصلها مدة الانتظار بين عمليتي حساب هو  spf-max-wait ولنفترض أنها (40 ثانية).

حال انقضت مدة spf-hold الحالية دون ورود رسالة تحديث وعدم الحاجة لتشغيل العملية فإن مدة الانتظار البينية تعود لقيمتها spf-hold الأصلية.

 

الفرق بين عمل السويتش وعمل الراوتر

 نتيجة وجود VLANs على السويتشات فإن التوصيل بين السويتشات يتم من خلال مداخل بوضعية trunks.

جهاز السويتش (layer2 switch) يجسد مبادئ ال layer2 forwarding، بينما الراوتر يجسد مبادئ ال  layer3 forwarding.

مقارنة بين المبدئين:

السويتش one broadcast domain في حال دخل فريم متجه للكل يقوم السويتش بتمريره عبر جميع المنافذ الأخرى غير الذي دخل منه، بينما هذا نرفوض بالرواتر (لن يمرره عبر المنافذ الأخرى).

السويتش يربط بين عناصر الشبكة الواحدة بينما الراوتر يربط بين الشبكات.

السويتش يمرر الفريم اذا كان وجتهه غير معلومة بالنسبة له (unknown destination) بينما الراوتر يقوم باهمال الرسالة المتجهة لعنوان غير معروف.

السويتش يمرر البيانات بشفافية transparently اي لا يغير بال headers المضافة عليها بينما الراوتر يغير layer2 header ويغير TTL and checksum

السويتش يبني ال forwarding table تلقائيا دون الحاجة لبروتوكول learning process، بينما هذا غير ممكن بالرواتر يتطلب static or dynamic routing

لمزيد من التفاصيل عن الفرق بين اعدادات الخاصة لمنافذ layer2 وبين منافذ layer3، تابع الموضوع التالي:

https://ipmasters-tc.blogspot.com/2013/08/switched-port-routed-port.html