ثغرة SSHole: تجاوز تسجيل الدخول إلى SSH

تخيل إن مهاجم يقدر يدخل على حساب مستخدم في سيرفر Linux عن طريق SSH من غير ما يعرف كلمة المرور، ومن غير ما يمتلك مفتاح SSH الخاص بالحساب!
ده بالضبط اللي بتسمح بيه ثغرة أمنية جديدة اسمها SSHole، واللي دفعت فريق OpenSSH لإصدار تحديث أمني عاجل في 5 نوفمبر 2026، بعد اكتشاف مشكلة في طريقة التعامل مع كلمات المرور على بعض الأنظمة التي تستخدم مكتبة musl.
الثغرة تستهدف بشكل أساسي بعض إعدادات Alpine Linux، وممكن تؤثر على أنظمة Linux أخرى تستخدم نفس المكونات والإعدادات.

---

🔍 إزاي ثغرة SSHole بتشتغل؟​

علشان نفهم المشكلة، لازم نعرف الأول إزاي SSH بيتحقق من كلمة المرور.
في Linux، بيانات كلمات المرور المشفرة بتتخزن في الملف:

/etc/shadow

لما المستخدم يحاول تسجيل الدخول عن طريق SSH باستخدام كلمة المرور، وفي حالة إن OpenSSH مش بيستخدم PAM، بيستخدم دالة اسمها crypt() لحساب الهاش ومقارنته بالهاش المخزن.
لو النتيجتين متطابقتين، بيتم قبول تسجيل الدخول.

لكن فيه حسابات بتكون مجهزة لتسجيل الدخول باستخدام SSH Keys فقط، وبيكون حقل كلمة المرور الخاص بيها في ملف /etc/shadow يحتوي على العلامة: *
العلامة دي معناها إن مفيش هاش صالح لتسجيل الدخول باستخدام كلمة المرور.

---

💥 فين المشكلة الأمنية؟​

المشكلة بتحصل بسبب طريقة تعامل مكتبة musl مع كلمات المرور الطويلة.
في بعض الحالات، لما يتم إرسال كلمة مرور أطول من 256 بايت، دالة crypt() بترجع العلامة * بدل نتيجة الهاش، ودي بتكون إشارة لحدوث خطأ أثناء عملية الحساب.

المشكلة إن OpenSSH في المسار المتأثر ممكن يقارن القيمة دي بالعلامة الموجودة بالفعل في ملف /etc/shadow.
وبما إن القيمتين متطابقتين، بيحصل تجاوز لعملية التحقق من كلمة المرور، وبيتم قبول تسجيل الدخول!
يعني المهاجم ممكن يدخل الحساب المستهدف من غير معرفة كلمة المرور الحقيقية، ومن غير امتلاك الـ Private Key الخاص بالمستخدم.

---

⚠️ إيه الأنظمة والإعدادات المعرضة للخطر؟​

مش كل سيرفر عليه OpenSSH معرض للثغرة. لازم مجموعة من الشروط تجتمع مع بعض:

1. النظام يستخدم مكتبة musl بدلًا من glibc، زي بعض إصدارات Alpine Linux.
2. OpenSSH بيعمل التحقق من كلمات المرور بدون استخدام PAM.
3. خاصية تسجيل الدخول باستخدام كلمة المرور مفعلة من خلال PasswordAuthentication yes.
4. الحساب المستهدف يحتوي حقل كلمة المرور الخاص به على *.
5. يوجد حساب محلي آخر على نفس السيرفر يحتوي هاش كلمة مرور يبدأ بـ $5$ أو $6$.

وجود الحساب الإضافي مهم لأن OpenSSH بيستخدم معلومات الـ Salt من حساب آخر عند التعامل مع بعض الحسابات التي لا تحتوي على هاش صالح.

كمان لازم تكون كلمة المرور المرسلة بطول يتراوح بين 257 و1024 بايت.

---

📌 نقطة مهمة جدًا​

البايت مش بالضرورة يساوي حرف واحد، خصوصًا مع الأحرف العربية وUnicode.
كمان استخدامك لمفتاح SSH بدل كلمة المرور مش معناه إن السيرفر محمي تلقائيًا؛ لأن خاصية Password Authentication ممكن تفضل مفعلة حتى لو أنت شخصيًا بتستخدم المفاتيح فقط.

---

🛡️ إزاي تحمي سيرفر Linux من SSHole؟​

الحل الأفضل هو تثبيت التحديث الأمني الخاص بتوزيعتك.

1. تحديث OpenSSH​

على Alpine Linux، استخدم:

apk update
apk upgrade -U -a

بعد التحديث، لازم تعيد تشغيل خدمة SSH علشان تتأكد إن العملية بتستخدم النسخة المحدثة:

rc-service sshd restart

خد بالك إن Alpine أصدرت إصلاحات لفروع مختلفة من النظام، وبالتالي مش شرط يظهر رقم الإصدار 10.6p2 عندك؛ لأن الإصلاح تم تضمينه أيضًا في إصدارات أقدم من OpenSSH الخاصة بحزم Alpine.

2. تعطيل تسجيل الدخول باستخدام كلمة المرور مؤقتًا​

لو مش قادر تثبت التحديث فورًا، ممكن تعطل تسجيل الدخول باستخدام كلمات المرور من إعدادات SSH:

PasswordAuthentication no

بعد تعديل الإعدادات، اختبر صحتها:

sshd -t

وبعد التأكد من عدم وجود أخطاء، أعد تشغيل الخدمة.

قبل تعطيل Password Authentication، تأكد إن تسجيل الدخول باستخدام SSH Keys شغال بالفعل، واحتفظ بجلسة SSH الحالية مفتوحة لحد ما تختبر الاتصال الجديد، علشان متفقدش الوصول للسيرفر.

---

❓ الأسئلة الشائعة​

------------------

هل كل سيرفرات Linux معرضة لثغرة SSHole؟​

لا، الثغرة مرتبطة بتجميعة معينة من OpenSSH وmusl مع تعطيل PAM وتوفر شروط إضافية. الأنظمة التي تستخدم glibc لا تتأثر بهذا المسار من الثغرة.

هل استخدام SSH Keys بيحميني من الثغرة؟​

مش بالضرورة. لو تسجيل الدخول باستخدام كلمات المرور ما زال مفعّلًا، ممكن يفضل السيرفر معرضًا للخطر حتى لو أنت بتستخدم SSH Keys في اتصالاتك المعتادة.

ما الإصدار الذي أصلح ثغرة SSHole؟​

الإصلاح موجود في OpenSSH 10.6p2، كما قامت Alpine Linux بتوفير تحديثات إصلاح لفروعها المدعومة والمتأثرة.

هل يمكن استغلال الثغرة عن بُعد؟​

نعم، المهاجم يحتاج فقط إلى الوصول إلى خدمة SSH على السيرفر، مع توفر شروط الاستغلال المطلوبة.

---

🔗 الخلاصة​

ثغرة SSHole مثال مهم على إن مشكلة صغيرة في التعامل مع القيم المرجعة من دوال التشفير ممكن تتحول إلى تجاوز كامل للمصادقة.
لو بتدير سيرفر Alpine Linux أو أي نظام بيستخدم musl مع OpenSSH، راجع إعدادات SSH وثبّت التحديث الأمني فورًا.
متستناش لحد ما تكتشف إن حسابات السيرفر بقت متاحة من غير كلمة مرور! 🔐