تحليل الهجوم (الجزء الثالث)

تحليل الهجوم (الجزء الأول)
تحليل الهجوم (الجزء الثاني)

دون باركر

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

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

القضايا المثيرة للاهتمام

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

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

مخرجات Snort

بناء الجملة المستخدم لاستدعاء Snort هو كما يلي:

C:\snort\bin\snort.exe –r c:\article_binary –dv –c snort.conf –A full

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

==============================================================
Snort processed 1345 packets.
==============================================================
Breakdown by protocol:
TCP: 524 (38.959%)
UDP: 810 (60.223%)
ICMP: 11 (0.818%)
ARP: 0 (0.000%)
EAPOL: 0 (0.000%)
IPv6: 0 (0.000%)
ETHLOOP: 0 (0.000%)
IPX: 0 (0.000%)
FRAG: 0 (0.000%)
OTHER: 0 (0.000%)
DISCARD: 0 (0.000%)
==============================================================
Action Stats:
ALERTS: 63
LOGGED: 63
PASSED: 0

يعد هذا القسم مثيرًا للاهتمام لأنه كان هناك 63 تنبيهًا تم تشغيلها بواسطة إجراء هجوم واحد. سنلقي نظرة على ملف alert.ids، الذي يمكنه تقديم الكثير من التفاصيل حول ما حدث. الآن، إذا كنت تتذكر أن أول شيء فعله المهاجم هو استخدام Nmap لإجراء فحص للشبكة، فقد أدى ذلك أيضًا إلى إنشاء التنبيه الأول الذي تم تشغيله بواسطة Snort.

[**] [1:469:3] ICMP PING NMAP [**]
[Classification: Attempted Information Leak] [Priority: 2]
08/09-15:37:07.296875 192.168.111.17 -> 192.168.111.23
ICMP TTL:54 TOS:0x0 ID:3562 IpLen:20 DgmLen:28
Type:8 Code:0 ID:30208 Seq:54825 ECHO
[Xref => http://www.whitehats.com/info/IDS162]

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

15:04:51.546875 IP (tos 0x0, ttl 128, id 9588, offset 0, flags [DF], proto: TCP (6), length: 51) 192.168.111.17.1347 > 192.168.111.23.80: P, cksum 0x5b06 (correct), 3389462932:3389462943(11) ack 2975555611 win 64240
0x0000: 4500 0033 2574 4000 8006 75d7 c0a8 6f11 E..3%[email protected].
0x0010: c0a8 6f17 0543 0050 ca07 1994 b15b 601b ..o..C.P.....[`.
0x0020: 5018 faf0 5b06 0000 4745 5420 736c 736c P...[...GET.slsl
0x0030: 736c 0a sl.

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

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

[**] [1:1248:13] WEB-FRONTPAGE rad fp30reg.dll access [**]
[Classification: access to a potentially vulnerable web application] [Priority:
2]08/09-15:39:23.000000 192.168.111.17:1454 -> 192.168.111.23:80
TCP TTL:128 TOS:0x0 ID:15851 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0x7779253A Ack: 0xAA1FBC5B Win: 0xFAF0 TcpLen: 20
[Xref => http://www.microsoft.com/technet/security/bulletin/MS01-035.mspx][Xref
=> http://cve.mitre.org/cgi-bin/cvename.cgi?name=2001-0341][Xref => http://www.s
ecurityfocus.com/bid/2906][Xref => http://www.whitehats.com/info/IDS555]

بمجرد حصول المهاجم على حق الوصول إلى خادم الويب، سيبدأ في استخدام عميل TFTP لنقل 4 ملفات: nc.exe، وipeye.exe، وfu.exe، وmsdirectx.exe. بمجرد نقل هذه الملفات، يستخدم المهاجم netcat لإرسال أداة مساعدة إلى جهاز الكمبيوتر الخاص به. ومن هناك، يمكنه فصل الأداة المساعدة الأخرى التي نتجت عن الهجوم الأولي والقيام بكل العمل المتبقي في الأداة المساعدة netcat. ومن المثير للاهتمام أن Snort لم يسجل أيًا من الإجراءات التي قام بها المهاجم عبر الأداة العكسية. ومع ذلك، وبغض النظر عن ذلك، استخدم المهاجم برنامجًا روتكيتًا أرسله عبر TFTP لإخفاء معلومات العملية عن netcat.

الخلاصة

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