استغلال الثغرة CVE-2025-61624 في FortiGate: صحّحوا ثم غيّروا كل الأسرار في الإعدادات

في 16 أكتوبر 2026 أضافت وكالة CISA الثغرة CVE-2025-61624 إلى كتالوج الثغرات المعروفة المستغلة (KEV)، وحددت للجهات الفيدرالية الأمريكية مهلة معالجة تنتهي في 19 أكتوبر. تقع الثغرة في سطر أوامر FortiOS، نظام تشغيل جدران الحماية FortiGate التي تعمل في كثير من المكاتب الصغيرة والمتوسطة. تمنحها Fortinet درجة CVSSv3 تبلغ 6.0 بخطورة متوسطة، وتمنحها NVD درجة 6.5. ومن السهل أن تنزل ثغرة متوسطة الخطورة، صدر إصلاحها منذ أبريل، إلى أسفل قائمة الأولويات.

الأفضل أن تعيدوا النظر فيها. فالثغرة تتطلب تسجيل دخول بصلاحية مسؤول، وفي الاختراق الذي أوصلها إلى قائمة CISA كان المهاجمون يملكون هذه البيانات مسبقًا، بعد أن فكّوا تشفيرها من ملفات إعدادات جدران حماية مسروقة. لذلك لا يدور هذا المقال حول التصحيح وحده بقدر ما يدور حول ما بعده: الإصدارات المتأثرة، وكيف تفحصون جهاز FortiGate لديكم، وما الذي توصي Unit 42 بالبحث عنه، ولماذا يجب تغيير كل كلمة مرور ومفتاح مشترك مسبقًا وشهادة موجودة في الإعدادات بمجرد الشك في أنها خرجت من المؤسسة.

ما الذي نشرته Fortinet وCISA

تصف نشرة Fortinet FG-IR-26-122، المنشورة أول مرة في 14 أبريل 2026، ثغرة path traversal في مفسر سطر الأوامر في FortiOS وFortiPAM وFortiProxy وFortiSwitchManager "قد تسمح لمهاجم يملك صلاحيات مميزة بكتابة ملفات عشوائية أو حذفها عبر معاملات مصاغة خصيصًا لأوامر موجودة". وتصنفها النشرة الآن بأنها "Known Exploited: Yes"، وتذكر أن أثرها رفع الصلاحيات، وتشير إلى تصحيح افتراضي باسم FG-VD-59270.0day في تحديث قاعدة بيانات FMWP رقم 25.120.

اتضحت الصورة في 14 أكتوبر حين نشرت Unit 42 التابعة لشركة Palo Alto Networks تحقيقها في اختراق شركة اتصالات، استُخدمت فيه هذه الثغرة لتحميل برمجية خبيثة تعيش في الذاكرة فقط على أجهزة FortiGate تسميها PEERSTITCH. وبعد يومين أضافتها CISA إلى KEV.

الإصدارات المتأثرة والإصدارات المصححة

وفق FG-IR-26-122:

السطر الذي سيوقع معظم المكاتب الصغيرة هو الثالث. فجهاز FortiGate الذي ما زال على 7.2 أو 7.0 أو 6.4 لن يحصل على أي إصلاح في فرعه الحالي، أي أن "التصحيح" يعني الترقية إلى فرع آخر، مع ما يتطلبه ذلك من اختبار ونافذة صيانة. وإذا كان طراز جهازكم لا يدعم 7.4 أو 7.6، يتحول الأمر إلى نقاش حول استبدال العتاد.

كيف استخدمها المهاجمون

تقول Unit 42 إن الاختراق وقع في سبتمبر 2024 لدى مؤسسة اتصالات، وإنها تتتبع المجموعة باسم CL-STA-0954، المعروفة أيضًا باسم UNC5820. وجاءت سلسلة الهجوم كما تصفها Unit 42 على النحو التالي:

• استغل المهاجمون الثغرة CVE-2024-47575 (المعروفة باسم FortiJump) في جهاز FortiManager المركزي للشركة، وسرّبوا أرشيفًا يضم الإعدادات العاملة لـ"أكثر من 500 جدار حماية FortiGate مُدار"، منها أجهزة تحمي عملاء تلك الشركة.
• احتوت تلك الإعدادات على "بيانات اعتماد إدارية ومحلية وخاصة بـSSL/VPN بصيغة مشفرة". وتكتب Unit 42: "أكدنا أن بيانات الاعتماد قابلة للاسترجاع، إذ نجحنا في كسر كلمات مرور الإدارة وSSL/VPN بالقوة الغاشمة من ملفات الإعدادات المسربة."
• بهذه الكلمات فتح المهاجمون جلسات SSL VPN إلى جدران الحماية الطرفية، ثم استخدموا CVE-2025-61624 للانتقال من صلاحية مسؤول FortiOS إلى صلاحية root على نظام التشغيل الأساسي. وفعلوا ذلك بإنشاء كائن system.auto-script باسم ../../../../setup، لأن محرك auto-script لا ينقّح أسماء الكائنات.
• ومن هناك حقنوا PEERSTITCH في خدمة السجلات miglogd وخدمة VPN ‏iked. وتقول Unit 42 إنها "لا تترك ملفًا تنفيذيًا دائمًا على القرص، ولا تفتح منافذ استماع، ولا تبدأ أي اتصال شبكي صادر".

كما محوا آثارهم. تذكر Unit 42 تنفيذ killall -9 miglogd وkillall -9 syslogd قبل تشغيل السكربتات، وdiagnose debug crashlog clear لمسح سجلات الأعطال، والحذف التلقائي لحسابات المسؤول المزيفة ومجموعات VPN وكائنات auto-script بعد استخدامها بوقت قصير. وعلى بعض جدران الحماية فعّلوا التقاط حزم يستهدف RADIUS ‏(UDP 1812 و1813) وLDAP ‏(TCP 389) وTFTP ‏(UDP 69). هذا جمع لبيانات الاعتماد، وليس فضولًا.

الدرس لشركة من 40 موظفًا لا علاقة له بقطاع الاتصالات أو بنسب الهجوم إلى دول. الدرس أن ثغرة متوسطة الخطورة لا تعمل إلا بعد المصادقة تحولت إلى صلاحية root على مئات الجدران لأن كلمات مرور المسؤولين كانت قد تسربت مسبقًا. إذا سبق أن فقدتم نسخة احتياطية من الإعدادات، أو تركتم واجهة الإدارة مكشوفة على الإنترنت، أو استخدمتم كلمة مرور مسؤول FortiGate في مكان آخر، فإن شرط "تتطلب مصادقة" يحميكم أقل مما توحي به الدرجة.

افحصوا الإصدار ومدى الانكشاف

في واجهة الويب لجهاز FortiGate يظهر إصدار البرنامج الثابت في أداة الحالة على لوحة المعلومات. ومن سطر الأوامر، يعرض الأمر get system status الإصدار ورقم البناء في الأسطر الأولى. قارنوه بالجدول أعلاه، وكرروا ذلك مع أي FortiProxy أو FortiPAM أو FortiSwitchManager لديكم.

بعد ذلك تحققوا ممن يستطيع الوصول إلى واجهة الإدارة. شغّلوا show system interface وانظروا إلى سطر set allowaccess على كل منفذ يواجه الإنترنت. إن احتوى على https أو ssh أو http فصفحة دخول الإدارة لديكم مكشوفة على الإنترنت. تطلب إرشادات الاستعادة من Fortinet نفسها تعطيل الوصول الإداري على الواجهات الخارجية وحصر الدخول في مضيفين موثوقين، وترتّب مدونة PSIRT في يونيو 2026 الخيارات: trusted hosts جيد، وlocal-in policy أفضل، وإلغاء الإدارة من الإنترنت تمامًا هو الأفضل.

وأخيرًا اسألوا أين تُحفظ النسخ الاحتياطية للإعدادات. ملف إعدادات FortiGate المصدَّر إلى مجلد مشترك، أو المرسَل بالبريد إلى مقاول، أو المخزَّن في FortiManager غير مصحح، هو من النوع نفسه الذي رأت Unit 42 أنه سُرق.

صحّحوا، أو انتقلوا من الفروع القديمة

رقّوا FortiOS 7.6 إلى 7.6.5 أو أحدث، و7.4 إلى 7.4.10 أو أحدث، واتبعوا أداة مسار الترقية (upgrade path tool) من Fortinet بدل القفز عدة إصدارات دفعة واحدة. وإن كنتم على 7.2 أو 7.0 أو 6.4، فخططوا الآن للانتقال إلى 7.4 أو 7.6. وتضيف مدونة Fortinet في يونيو سببًا ثانيًا: الإصدارات 7.4 و7.6 و8.0 "تدعم تجزئة PBKDF2 لبيانات اعتماد المسؤولين"، وتوصي بإزالة إعدادات كلمات المرور القديمة عبر set login-lockout-upon-weaker-encryption.

يمكن للتصحيح الافتراضي المذكور في FG-IR-26-122 أن يمنحكم وقتًا إذا كانت نافذة الصيانة بعد أيام. لكنه ليس بديلًا عن الترقية، ولا يفعل شيئًا لبيانات اعتماد تسربت بالفعل.

ما الذي تبحثون عنه

نشرت Unit 42 جدولًا للكشف. هذه هي الفحوص التي يستطيع فريق تقنية معلومات صغير تنفيذها فعلًا أو تسليمها لمزوّد الخدمة:

• الإعدادات: ابحثوا في الإعدادات الحالية والنسخ المحفوظة عن كائنات system.auto-script تحتوي أسماؤها على ../../. يعرض الأمر show system auto-script الكائنات الحالية. رأت Unit 42 الاسمين ../../../../setup و../../tmp/apache2/conf/md-acme.conf.
• سجلات الأعطال: شغّلوا diagnose debug crashlog read وابحثوا عن أعطال Signal 11 تخص miglogd أو iked أو syslogd. وسجل أعطال فارغ على جهاز يعمل منذ أشهر يستحق السؤال أيضًا، فالمهاجمون مسحوه.
• الذاكرة: مناطق مجهولة حجمها 16,384 بايت بصلاحيات rwxp في خرائط ذاكرة /bin/miglogd و/bin/iked. تحتاجون لهذا إلى الدعم الفني لدى Fortinet ‏(TAC) أو فريق استجابة للحوادث، لأن المسؤول العادي لا يملك shell.
• الملفات والشبكة: أسماء الملفات lldprx وpM.js وipssem.js وindex.js وindex.wasm، وعناوين IP ‏23.240.77[.]233 و47.18.167[.]159 و45.32.41[.]202 و198.199.122[.]22، إضافة إلى بصمات SHA-256 وقاعدة YARA في قسم مؤشرات الاختراق في التقرير.
• الحسابات وVPN: حساب مسؤول باسم FortiGateCloud لم تنشئوه، ومستخدمو إدارة أو VPN ظهروا ثم اختفوا، وعمليات دخول SSL VPN من عناوين غير مألوفة. وتطلب مدونة Fortinet في يونيو أيضًا البحث عن حسابات غير معروفة "مثل forticloud وfortiuser وfortinet-support وfortinet-tech-support".

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

لماذا لا ينتهي العمل بالتصحيح

جهاز FortiGate مصحح بكلمة مرور المسؤول نفسها، وكلمات مرور مستخدمي VPN نفسها، ومفاتيح IPsec نفسها، يظل مفتوحًا لمن فك تشفير الإعدادات القديمة. وخلاصة Unit 42 واضحة: مواد الثقة المأخوذة من منصة الإدارة "تغادر مع المهاجم وتبقى صالحة حتى يتم تدويرها". قلنا الأمر نفسه عن أجهزة الحافة في مقالة Citrix NetScaler: تدوير الأسرار بعد التصحيح، والنمط لم يتغير.

تتلخص إرشادات Fortinet في حال الوصول غير المصرح به إلى إعدادات الجهاز، والتي تُطبق بعد الترقية، في هذا الترتيب:

1. استعيدوا الإعدادات من نسخة احتياطية سليمة معروفة، أو أنشئوا إعدادات نظيفة وتحققوا من محتواها.
2. أعيدوا تعيين بيانات اعتماد كل المسؤولين والمستخدمين المحليين ومستخدمي VPN.
3. غيّروا أسرار RADIUS والمفاتيح المشتركة مسبقًا لـIPsec.
4. استبدلوا الشهادات وألغوا الشهادات التي ربما سُرقت.
5. غيّروا كلمة مرور حساب LDAP الذي يتصل به FortiGate.
6. احصروا دخول المسؤولين في مضيفين موثوقين، وأزيلوا الوصول الإداري من الواجهات الخارجية، وفعّلوا المصادقة الثنائية للمسؤولين.

وتضيف مدونة Fortinet في يونيو 2026 نقطتين: أنهوا كل جلسات الإدارة وVPN النشطة، وفعّلوا المصادقة متعددة العوامل (MFA) على كل حسابات المسؤولين وVPN. الجلسات مهمة لأن إعادة تعيين كلمة المرور لا تؤثر في نفق VPN قائم بالفعل. وإذا كان FortiGate يصادق المستخدمين عبر Active Directory، فيجب اعتبار حساب خدمة LDAP وأي كلمة مرور مرت عبر مسار RADIUS أو LDAP تم التقاطه مكشوفة، ويجب أن تدخل سجلات وحدة التحكم بالمجال في عملية البحث. وبيانات دخول VPN المسروقة هي أيضًا الطريق الذي تدخل منه عصابات الفدية، كما وصفت الجهات الأمنية في مقالتنا عن برنامج الفدية SafePay، والمصادقة متعددة العوامل القابلة للتصيد لا تحمي إلا إلى حد، وهو ما تناولناه في مقالتنا عن تصيد AiTM.

إذا كان مزوّد خدمة يدير جهاز FortiGate لديكم

كانت الضحية في قضية Unit 42 مزوّد خدمات مُدارة (MSP)، وشمل الأرشيف المسروق جدران حماية عملائه أيضًا. وتوضح Unit 42 أنها لم تفحص شبكات أولئك العملاء، فهي لا تدّعي أنها اختُرقت. إذا كان مزوّد MSP يدير جدار الحماية لديكم عبر FortiManager أو منصة مشابهة، فاسألوه ثلاثة أسئلة هذا الأسبوع: ما إصدار FortiOS على جهازكم، وهل تعرضت منصة الإدارة لديه يومًا للثغرة CVE-2024-47575، ومتى غُيّرت آخر مرة أسرار الإدارة وVPN وIPsec الخاصة بكم. إن لم يعرف أحد جواب السؤال الثالث، فافترضوا أن الجواب هو "يوم التركيب".

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

هل تحتاجون إلى مساعدة في الترقية أو البحث عن مؤشرات الاختراق أو تدوير بيانات الاعتماد؟ يقدّم فريق السحابة وDevOps لدى Fanpino هذا العمل للشركات الصغيرة والمتوسطة.

المصادر: نشرة Fortinet PSIRT ‏FG-IR-26-122، تنبيه CISA حول KEV، ‏16 أكتوبر 2026، NVD CVE-2025-61624، تقرير Unit 42 عن PEERSTITCH، ‏14 أكتوبر 2026، إرشادات الاستعادة من Fortinet، مدونة Fortinet PSIRT، يونيو 2026. جرى التحقق من بيانات الإصدارات في 2 نوفمبر 2026.