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

الفكرة المركزية

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

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

هذا هو بالضبط كيف يعمل bhunter. يستمع إلى المنفذ 22 (خدمة SSH) ويجمع كل تسجيلات الدخول وكلمات المرور التي يحاولون الاتصال بها. ثم، باستخدام كلمات المرور المجمعة، يحاول الاتصال بالعقد المهاجمة.

خوارزمية العمل

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

والجزء الثاني هو المسؤول المباشر عن الهجوم. علاوة على ذلك، يتم تنفيذ الهجوم في وضعين: BurstAttack (هجوم انفجاري) - تسجيلات دخول القوة الغاشمة وكلمات المرور من القائمة العامة وSingleShotAttack (هجوم طلقة واحدة) - كلمات مرور القوة الغاشمة التي استخدمتها العقدة التي تمت مهاجمتها، ولكن لم يتم استخدامها بعد يضاف إلى القائمة العامة.

من أجل الحصول على بعض قواعد بيانات تسجيلات الدخول وكلمات المرور على الأقل بعد الإطلاق مباشرة، تتم تهيئة bhunter بقائمة من الملف /etc/bhunter/defaultLoginPairs.

السطح البيني

هناك عدة طرق لإطلاق bhunter:

فقط كفريق

sudo bhunter

مع هذا الإطلاق، من الممكن التحكم في bhunter من خلال القائمة النصية الخاصة به: إضافة معلومات تسجيل الدخول وكلمات المرور للهجوم، وتصدير قاعدة بيانات لتسجيلات الدخول وكلمات المرور، وتحديد هدف للهجوم. يمكن رؤية جميع العقد المخترقة في الملف /var/log/bhunter/hacked.log

باستخدام تموكس

sudo bhunter-ts # команда запуска bhunter через tmux  
sudo tmux attach -t bhunter # подключаемся к сессии, в которой запущен bhunter

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

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

ميزة هذه الطريقة عن الأولى هي أنه يمكننا إغلاق المحطة بأمان والعودة إليها لاحقًا، دون أن يوقف bhunter عملها. بالنسبة لأولئك الذين ليسوا على دراية بـ tmux، أقترح ذلك ورقة الغش هذه.

كخدمة

systemctl enable bhunter
systemctl start bhunter

في هذه الحالة، نقوم بتمكين التشغيل التلقائي لـ bhunter عند بدء تشغيل النظام. في هذه الطريقة، لا يتم توفير التفاعل مع bhunter، ويمكن الحصول على قائمة العقد المخترقة من /var/log/bhunter/hacked.log

فعالية

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

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

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

الأخطاء التي لم أصلحها بعد

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

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

ما الذي يجب العمل عليه أيضًا؟

اسم الخدمة

وفقًا لـ RFC-4253، يتبادل العميل والخادم أسماء الخدمات التي تنفذ بروتوكول SSH قبل التثبيت. هذا الاسم موجود في حقل "اسم الخدمة"، وهو موجود في الطلب من جانب العميل وفي الاستجابة من جانب الخادم. الحقل عبارة عن سلسلة، ويمكن العثور على قيمته باستخدام wireshark أو nmap. فيما يلي مثال لـ OpenSSH:

$ nmap -p 22 ***.**.***.** -sV
Starting Nmap ...
PORT   STATE SERVICE VERSION
22/tcp open  ssh     <b>OpenSSH 7.9p1 Debian 10+deb10u2</b> (protocol 2.0)
Nmap done: 1 IP address (1 host up) scanned in 0.47 seconds

ومع ذلك، في حالة Paramiko، يحتوي هذا الحقل على سلسلة مثل "Paramiko Python sshd 2.4.2"، والتي يمكن أن تخيف شبكات الروبوت المصممة "لتجنب" الفخاخ. ولذلك، أعتقد أنه من الضروري استبدال هذا الخط بشيء أكثر حيادية.

ناقلات أخرى

SSH ليس الوسيلة الوحيدة للإدارة عن بعد. وهناك أيضا التلنت، RDP. يجدر إلقاء نظرة فاحصة عليهم.

تمديد

سيكون من الرائع أن يكون لديك العديد من الفخاخ في بلدان مختلفة وأن تقوم مركزيًا بجمع تسجيلات الدخول وكلمات المرور والعقد المخترقة منها في قاعدة بيانات مشتركة

أين يمكنني التنزيل؟

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

المصدر: www.habr.com