جهاز تحكم عن بعد شديد تنفيذ التعليمات البرمجية غير المصادق عليها (RCE) تم اكتشاف ثغرة أمنية مؤخرًا في خادم OpenSSH (sshd) على أنظمة Linux القائمة على glibc. هذا الخلل الخطير، الذي يُعزى إلى CVE-2024-6387يشكل خطرًا أمنيًا كبيرًا لأنه يسمح بتنفيذ تعليمات برمجية عن بعد غير موثوقة كجذر.
يأتي هذا الاكتشاف في أعقاب ثغرة أمنية خطيرة أخرى تم اكتشافها في مكتبة XZ Utils قبل بضعة أشهر فقط، مما يُبرز التحديات المستمرة في مجال الأمن السيبراني. على الرغم من أن الثغرة CVE-2024-6387 تُعدّ ثغرة خطيرة، إلا أن استغلالها عمليًا أمرٌ بالغ الصعوبة. مع ذلك، من الضروري فهم المخاطر واتخاذ خطوات لحماية أنظمتك. يُستخدم بروتوكول SSH على نطاق واسع عبر منصات مختلفة على خوادم Linux، مما يجعل أمنه بالغ الأهمية.
التفاصيل التقنية
تظهر هذه المشكلة عندما يفشل العميل في المصادقة داخل تسجيل الدخول الفترة التي تم ضبطها على 120 ثواني بشكل افتراضي في الإصدارات الأخيرة و 600 ثوانٍ في الإصدارات الأقدم. عند انتهاء هذه المهلة، يتم تشغيل sshd سيغالرم يتم تشغيل المعالج. تحدث المشكلة لأن هذا المعالج يستدعي وظائف متعددة، مثل سجل النظام ()، والتي من غير الآمن استدعاؤها من داخل معالج الإشارة. تُشكل حالة السباق هذه خطرًا كبيرًا على الأنظمة التي تعمل بنظام التشغيل الافتراضي سشد ترتيب.
من المثير للاهتمام أن هذه الثغرة الأمنية ليست جديدة تمامًا. إنها انحدار لمشكلة سابقة، CVE-2006-5051، أبلغ عنها مارك دود عام 2006. تضمنت هذه الثغرة الأمنية السابقة أيضًا حالة تسابق في معالج الإشارات في إصدارات OpenSSH السابقة للإصدار 4.4، مما قد يؤدي إلى رفض الخدمة أو السماح بتنفيذ التعليمات البرمجية عن بُعد.
حدث التراجع في أكتوبر 2020 مع إصدار OpenSSH 8.5p1. أثناء تحديث البنية التحتية للتسجيل، تم إصدار توجيه مهم (#ifdef DO_LOG_SAFE_IN_SIGHAND) تم إزالته عن غير قصد من سيجدي() هذه الوظيفة، التي يتم استدعاؤها مباشرةً بواسطة sshd سيغالرم أصبح معالج النظام غير آمن مرة أخرى. إليك تفصيل للخطة الزمنية للثغرة:
- OpenSSH < 4.4p1:عُرضة لحالة السباق ما لم يتم تصحيحها لـ CVE-2006-5051 أو CVE-2008-4109.
- 4.4p1 ≤ OpenSSH < 8.5p1:آمن بسبب وجود #ifdef DO_LOG_SAFE_IN_SIGHAND، مما جعل sigdie() تستدعي _exit(1) بأمان.
- 8.5p1 ≤ OpenSSH < 9.8p1:أصبحت عرضة للخطر مرة أخرى بسبب إزالة التوجيه #ifdef DO_LOG_SAFE_IN_SIGHAND.
إن آثار هذه الثغرة خطيرة بشكل خاص على أنظمة Linux المستندة إلى glibc، حيث سجل النظام () قد يستدعي في حد ذاته وظائف غير آمنة أخرى مثل مالوك () و مجانا()هذا يُنشئ سيناريو يُمكن فيه للمهاجم تنفيذ تعليمات برمجية عشوائية كجذر دون الحاجة إلى المصادقة. وذلك لأن التعليمات البرمجية المُفعّلة في sshd تعمل بصلاحيات نظام كاملة وتفتقد الحماية.
تفاصيل الضعف
تنشأ هذه الثغرة الأمنية بسبب حالة تسابق في معالج الإشارة في خادم OpenSSH (sshd)، مما يؤثر على الأنظمة في إعداداتها الافتراضية. كشفت عمليات البحث باستخدام Censys وShodan عن أكثر من 14 مليون خادم OpenSSH معرض للاختراق ومتصل بالإنترنت. تشير بيانات مجهولة المصدر من Qualys إلى أن حوالي 700,000 خادم خارجي متصل بالإنترنت معرض للاختراق، وهو ما يمثل 31% من إجمالي الخوادم المتصلة بالإنترنت التي تستخدم OpenSSH في قاعدة عملاء OpenSSH العالمية. والجدير بالذكر أن أكثر من 0.14% من هذه الخوادم المعرضة للاختراق تعمل بإصدارات OpenSSH التي انتهت صلاحيتها/انتهت صلاحيتها.
تطوير الاستغلال والإفصاح
من خلال فهم عملية الاستغلال التفصيلية، يمكن لمسؤولي النظام ومحترفي الأمن تقدير مدى خطورة هذه الثغرة الأمنية وأهمية تنفيذ التصحيحات في الوقت المناسب وتدابير الأمن القوية بشكل أفضل.
يتطلب استغلال ثغرة حالة سباق معالج الإشارة في OpenSSH فهمًا عميقًا لهجمات التوقيت والتلاعب بالذاكرة. فيما يلي، نوضح الخطوات التي قد يتخذها المهاجم لاستغلال هذه الثغرة.
بدء اتصالات متعددة
يقوم المهاجم ببدء العديد من الاتصالات بخادم OpenSSH المستهدف، مما يؤدي بشكل متكرر إلى تشغيل تسجيل الدخول الحد الأقصى دون إكمال المصادقة. يؤدي هذا الإجراء إلى رفع الخادم سيغالرم إشارة.
معالج إشارة المقاطعة
يعتمد الاستغلال على مقاطعة معالج إشارة الخادم في اللحظة التي ينفذ فيها عمليات غير آمنة للإشارة غير المتزامنة، مثل سجل النظام ()يقوم المهاجم بإرسال مدخلات مصممة خصيصًا للتلاعب بتخطيط ذاكرة الخادم، مما يؤدي إلى تلف الكومة.
التلاعب بتخطيط الذاكرة
بالتلاعب بذاكرة الخادم، يُنشئ المهاجم حالة غير متسقة في الكومة. ويتم ذلك عن طريق تشغيل إشارة SIGALRM أثناء وظائف تخصيص أو إلغاء تخصيص الذاكرة مثل مالوك () or مجانا()يتطلب استغلال هذه الثغرة عادةً حوالي 10,000 محاولة. كل محاولة تُعيد ضبط مُؤقت LoginGraceTime، مما يُتيح للمُهاجم نافذة جديدة لتفعيل الثغرة.
ضبط التوقيت بدقة
أثناء عملية الاستغلال، يُعدِّل المهاجم توقيت مُدخلاته بناءً على التغذية الراجعة من المحاولات السابقة. يُعدُّ هذا الضبط الدقيق بالغ الأهمية لمقاطعة مُعالِج الإشارة بنجاح في اللحظة الحرجة. على الرغم من وجود دفاعات حديثة مثل التوزيع العشوائي لتخطيط مساحة العنوان (ASLR) وتقنية عدم التنفيذ (NX)، يستخدم المهاجم أنماط ذاكرة متوقعة وتقنيات توقيت مُتقدمة لتجاوز هذه الحماية.
تنفيذ تعليمات برمجية عشوائية
يتيح الاستغلال الناجح للمهاجم إعادة كتابة هياكل الذاكرة الحرجة، مما يؤدي إلى تنفيذ تعليمات برمجية عشوائية والتحكم عن بعد في الخادم باستخدام امتيازات الجذر.
رؤى البحث والتطوير
ركز الباحثون بشكل أساسي على الآلات الافتراضية ذات ظروف الشبكة المستقرة في الغالب. ورغم إحراز تقدم كبير، يُتوقع إجراء تحسينات إضافية، لا سيما في استغلال أنظمة amd64 الأحدث حيث يكون ASLR أقوى. وقد أدى اكتشاف تقرير خطأ ذي صلة إلى التواصل الفوري مع مطوري OpenSSH، مما يؤكد أهمية اتخاذ إجراءات سريعة لمعالجة هذه الثغرات الأمنية.
OpenSSH: ضمان اتصالات مؤسسية آمنة
OpenSSH (الغلاف الآمن المفتوح) هو مجموعة أساسية من أدوات الشبكات الآمنة، مبنية على بروتوكول SSH (الغلاف الآمن). يضمن تشفيرًا قويًا للخصوصية ونقل الملفات بشكل آمن، مما يجعله أساسيًا لإدارة الخوادم عن بُعد واتصالات البيانات الآمنة. على الرغم من الثغرة الأمنية الأخيرة، لا يزال OpenSSH معيارًا في مجال أمان البرمجيات بفضل ميزاته الشاملة في الأمان والمصادقة، وقابليته للتوسع، وقدرته على فرض ضوابط وصول قوية.
إصدارات OpenSSH المتأثرة
- الضعيفة: الإصدارات الأقدم من 4.4p1 (ما لم يتم تصحيحها لـ CVE-2006-5051 وCVE-2008-4109) والإصدارات من 8.5p1 وحتى 9.8p1، ولكن لا تشملها.
- غير ضعيف:الإصدارات من 4.4p1 إلى 8.5p1، ولكن لا تشملها، وذلك بسبب التصحيح التحويلي لـ CVE-2006-5051.
لا تتأثر أنظمة OpenBSD بهذا الخطأ، وذلك بفضل آلية آمنة تم تطويرها في عام 2001 والتي تمنع هذه الثغرة الأمنية.
التأثير المحتمل لـ regreSSHion
في حال استغلال هذه الثغرة، قد تؤدي إلى اختراق كامل للنظام، مما يسمح للمهاجمين بتنفيذ أوامر برمجية عشوائية بأعلى الصلاحيات. قد يؤدي هذا إلى الاستيلاء الكامل على النظام، وتثبيت برمجيات خبيثة، والتلاعب بالبيانات، وإنشاء ثغرات أمنية للوصول المستمر. كما قد يُسهّل انتشار الشبكة، مما يُمكّن المهاجمين من اختراق أنظمة أخرى معرضة للخطر داخل المؤسسة واستغلالها. طبيعة هذه الثغرة، التي تعمل عن بُعد، تجعل استغلالها صعبًا، لكن التطورات في مجال التعلم العميق قد تزيد من معدل النجاح.
خطوات فورية للتخفيف من المخاطر
- إدارة التصحيح:قم بتطبيق التصحيحات المتوفرة لـ OpenSSH بسرعة وأعط الأولوية لعمليات التحديث المستمرة.
- تعزيز التحكم في الوصول:قم بالحد من الوصول إلى SSH من خلال عناصر التحكم المستندة إلى الشبكة لتقليل مخاطر الهجوم.
- تقسيم الشبكة واكتشاف الاختراق:تقسيم الشبكات لتقييد الوصول غير المصرح به والحركات الجانبية داخل البيئات الحرجة، ونشر أنظمة لمراقبة الأنشطة غير العادية التي تشير إلى محاولات الاستغلال والتنبيه إليها.
- تنفيذ حل مؤقت:إذا لم يكن من الممكن إجراء الترقية على الفور، فقم بتعيين تسجيل الدخول المعلمة ل 0 في ملف تكوين OpenSSH. هذا يمنع بقاء الجلسات غير المُصادق عليها مفتوحةً واستغلالها. مع ذلك، تجدر الإشارة إلى أن هذا قد يؤدي إلى رفض الخدمة إذا كانت جميع منافذ الاتصال مشغولة.
- تعزيز الأمن مع Seccomp:من خلال تقييد نداءات نظام sshd، وتقليل سطح الهجوم ومنع استغلال الوظائف غير الآمنة مثل syslog، وبالتالي تقييد تنفيذ التعليمات البرمجية التعسفية في حالة وجود ثغرات أمنية.
RELIANOID مُوازِن التحميل: الالتزام بالأمان
جميع اصدارات RELIANOID يحتوي مُوازن الأحمال على الحزم المُحدثة في مستودعنا، مما يعكس التزامنا بتوفير مُوازن أحمال أكثر أمانًا وموثوقية. تأكد من تثبيت آخر التحديثات على مُوازنات الأحمال والخوادم لديك.
كن يقظًا وتأكد من أن أنظمتك محمية ومُصححة ضد هذا التهديد الأمني الخطير. تواصل مع خبراء الأمن لدينا لمعرفة المزيد عن هذه الثغرة الأمنية.
مدونات ذات صلة
