روز ۱۶ اکتبر ۲۰۲۶، CISA آسیبپذیری CVE-2025-61624 را به فهرست آسیبپذیریهای شناختهشدهٔ مورد سوءاستفاده (KEV) اضافه کرد و مهلت رفع آن برای نهادهای فدرال آمریکا را ۱۹ اکتبر تعیین کرد. این باگ در خط فرمان FortiOS است، سیستمعامل فایروالهای FortiGate که در بسیاری از دفترهای کوچک و متوسط کار میکنند. فورتینت به آن امتیاز CVSSv3 برابر ۶٫۰ و شدت متوسط داده و NVD امتیاز ۶٫۵. امتیاز متوسط، آن هم با وصلهای که از آوریل منتشر شده، راحت به ته فهرست کارها میرود.
بهتر است دوباره نگاهش کنید. این نقص به ورود مدیر (admin) نیاز دارد، و در نفوذی که آن را به فهرست CISA رساند، مهاجمان این ورودها را از قبل داشتند؛ رمزها را از فایلهای پیکربندی دزدیدهشدهٔ فایروالها بازگشایی کرده بودند. پس موضوع این مقاله کمتر خود وصله است و بیشتر کاری که بعد از آن باید کرد: کدام نسخهها آسیبپذیرند، FortiGate خود را چطور بررسی کنید، Unit 42 دنبال چه نشانههایی را توصیه میکند، و چرا وقتی احتمال میدهید پیکربندی بیرون رفته، همهٔ رمزها، کلیدهای از پیش مشترک و گواهیهای داخل آن باید عوض شوند.
فورتینت و CISA چه منتشر کردند
هشدار FG-IR-26-122 فورتینت که اولین بار ۱۴ آوریل ۲۰۲۶ منتشر شد، یک path traversal در مفسر خط فرمان FortiOS، FortiPAM، FortiProxy و FortiSwitchManager را توضیح میدهد که به گفتهٔ خود هشدار «ممکن است به مهاجم دارای دسترسی ممتاز اجازه دهد با آرگومانهای دستکاریشده برای دستورهای موجود، فایل دلخواه بنویسد یا حذف کند». این هشدار اکنون وضعیت «Known Exploited: Yes» دارد، اثر آن را ارتقای سطح دسترسی ذکر کرده و از یک وصلهٔ مجازی به نام FG-VD-59270.0day در بهروزرسانی ۲۵.۱۲۰ پایگاه FMWP نام برده است.
زمینهٔ ماجرا ۱۴ اکتبر روشن شد، وقتی Unit 42 شرکت Palo Alto Networks گزارش بررسی یک نفوذ به شرکتی مخابراتی را منتشر کرد. در آن نفوذ از همین باگ برای بارگذاری یک ایمپلنت فقطحافظهای روی FortiGate استفاده شده بود که Unit 42 نامش را PEERSTITCH گذاشته است. دو روز بعد CISA آن را به KEV افزود.
نسخههای آسیبپذیر و نسخههای اصلاحشده
بر اساس FG-IR-26-122:
| محصول | آسیبپذیر | راهحل |
|---|---|---|
| FortiOS 7.6 | 7.6.0 تا 7.6.4 | 7.6.5 یا بالاتر |
| FortiOS 7.4 | 7.4.0 تا 7.4.9 | 7.4.10 یا بالاتر |
| FortiOS 7.2، 7.0، 6.4 | همهٔ نسخهها | مهاجرت به نسخهٔ اصلاحشده |
| FortiProxy 7.6 | 7.6.0 تا 7.6.4 | 7.6.5 یا بالاتر |
| FortiProxy 7.4 | 7.4.0 تا 7.4.11 | 7.4.12 یا بالاتر |
| FortiProxy 7.2، 7.0 | همهٔ نسخهها | مهاجرت به نسخهٔ اصلاحشده |
| FortiPAM 1.7 | 1.7.0 | 1.7.1 یا بالاتر (1.8 آسیبپذیر نیست) |
| FortiPAM 1.0 تا 1.6 | همهٔ نسخهها | مهاجرت به نسخهٔ اصلاحشده |
| FortiSwitchManager 7.2 | 7.2.0 تا 7.2.7 | 7.2.8 یا بالاتر |
| FortiSwitchManager 7.0 | 7.0.0 تا 7.0.6 | 7.0.7 یا بالاتر |
ردیفی که بیشتر دفترهای کوچک را گیر میاندازد ردیف سوم است. FortiGateای که هنوز روی 7.2، 7.0 یا 6.4 است در شاخهٔ فعلی خود هیچ وصلهای نمیگیرد، پس «وصله کردن» یعنی ارتقای شاخه، با همهٔ آزمایشها و پنجرهٔ تعمیراتی که لازم دارد. اگر مدل دستگاه شما از 7.4 یا 7.6 پشتیبانی نمیکند، بحث به تعویض سختافزار میرسد.
مهاجمان چطور از آن استفاده کردند
به گفتهٔ Unit 42 این نفوذ در سپتامبر ۲۰۲۴ در یک سازمان مخابراتی رخ داده و گروه مهاجم با نام CL-STA-0954، که با نام UNC5820 هم شناخته میشود، ردیابی میشود. زنجیرهٔ حمله، آنطور که Unit 42 شرح داده، این بود:
- مهاجمان از CVE-2024-47575 (معروف به FortiJump) روی FortiManager مرکزی شرکت سوءاستفاده کردند و آرشیوی را بیرون بردند که پیکربندی در حال اجرای «بیش از ۵۰۰ فایروال FortiGate تحت مدیریت» را داشت، از جمله دستگاههایی که از مشتریان این شرکت محافظت میکردند.
- این پیکربندیها «اعتبارنامههای مدیریتی، محلی و SSL/VPN به صورت رمزشده» را در خود داشتند. Unit 42 مینویسد: «تأیید کردیم که اعتبارنامهها قابل بازیابی بودند؛ رمزهای مدیریتی و SSL/VPN را از فایلهای پیکربندی خارجشده با brute-force با موفقیت بازیابی کردیم.»
- مهاجمان با این رمزها نشستهای SSL VPN به فایروالهای مرزی باز کردند و بعد با CVE-2025-61624 از سطح مدیر FortiOS به root روی سیستمعامل زیرین رسیدند. روش کار ساختن یک شیء
system.auto-scriptبا نام../../../../setupبود، چون موتور auto-script نام اشیا را پاکسازی نمیکند. - از آنجا PEERSTITCH را به daemon ثبت لاگ
miglogdو daemon ویپیان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) فعال کردند. این جمعآوری اعتبارنامه است، نه کنجکاوی.
درس این ماجرا برای یک شرکت ۴۰ نفره ربطی به مخابرات یا انتساب به دولتها ندارد. درس این است که یک باگ با شدت متوسط که فقط با احراز هویت کار میکند، روی صدها فایروال به root تبدیل شد چون رمزهای مدیر از قبل لو رفته بودند. اگر تا به حال فایل پشتیبان پیکربندی را گم کردهاید، رابط مدیریت را روی اینترنت باز گذاشتهاید، یا رمز مدیر FortiGate را جای دیگری هم استفاده کردهاید، شرط «نیاز به احراز هویت» کمتر از آنچه امتیازش نشان میدهد از شما محافظت میکند.
نسخه و میزان در معرض بودن را بررسی کنید
در رابط وب FortiGate نسخهٔ firmware در ویجت وضعیت داشبورد دیده میشود. در خط فرمان، دستور get system status نسخه و build را در خطوط اول نشان میدهد. آن را با جدول بالا مقایسه کنید. همین کار را برای هر FortiProxy، FortiPAM یا FortiSwitchManager که دارید انجام دهید.
بعد ببینید چه کسی به رابط مدیریت دسترسی دارد. دستور show system interface را اجرا کنید و خط set allowaccess را روی همهٔ پورتهای رو به اینترنت نگاه کنید. اگر https، ssh یا http در آن هست، صفحهٔ ورود مدیریت شما روی اینترنت است. راهنمای بازیابی خود فورتینت میگوید دسترسی مدیریتی روی رابطهای بیرونی را غیرفعال و ورود را به میزبانهای مورد اعتماد محدود کنید، و بلاگ PSIRT ژوئن ۲۰۲۶ گزینهها را رتبهبندی میکند: trusted hosts خوب است، local-in policy بهتر، و نبودن مدیریت از اینترنت بهترین.
در آخر بپرسید فایلهای پشتیبان پیکربندی کجا نگه داشته میشوند. فایل پیکربندی FortiGate که روی درایو اشتراکی خروجی گرفته شده، برای پیمانکار ایمیل شده، یا در یک FortiManager وصلهنشده مانده، دقیقاً از همان جنسی است که Unit 42 دزدیدهشدنش را دید.
وصله کنید، یا از شاخههای قدیمی مهاجرت کنید
FortiOS 7.6 را به 7.6.5 یا بالاتر و 7.4 را به 7.4.10 یا بالاتر ارتقا دهید و به جای پرش از چند build، مسیر ارتقای پیشنهادی فورتینت (upgrade path tool) را دنبال کنید. اگر روی 7.2، 7.0 یا 6.4 هستید، مهاجرت به 7.4 یا 7.6 را همین حالا برنامهریزی کنید. بلاگ ژوئن فورتینت دلیل دومی هم میآورد: نسخههای 7.4، 7.6 و 8.0 «از هش PBKDF2 برای اعتبارنامههای مدیر پشتیبانی میکنند» و توصیه میکند تنظیمات قدیمی رمز با set login-lockout-upon-weaker-encryption کنار گذاشته شود.
وصلهٔ مجازی ذکرشده در FG-IR-26-122 جایی که پنجرهٔ تعمیراتی چند روز دیگر است میتواند وقت بخرد. اما جایگزین ارتقا نیست و برای اعتبارنامههایی که از قبل لو رفتهاند هیچ کاری نمیکند.
دنبال چه بگردید
Unit 42 جدولی برای شناسایی منتشر کرده است. اینها بررسیهایی است که یک تیم IT کوچک واقعاً میتواند انجام دهد یا به ارائهدهندهٔ خود بسپارد:
- پیکربندی: پیکربندی فعلی و نسخههای ذخیرهشده را برای اشیای
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بگردید. لاگ کرش خالی روی دستگاهی که ماهها روشن بوده هم جای سؤال دارد، چون مهاجمان آن را پاک کردند. - حافظه: ناحیههای بینام ۱۶٬۳۸۴ بایتی با مجوز
rwxpدر نقشهٔ حافظهٔ/bin/miglogdو/bin/iked. برای این کار به پشتیبانی فنی فورتینت (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 در بخش IOC گزارش. - حسابها و VPN: حساب مدیری به نام
FortiGateCloudکه هرگز خودتان نساختهاید، کاربران مدیر یا VPN که ظاهر و ناپدید شدهاند، و ورودهای SSL VPN از نشانیهای ناآشنا. بلاگ ژوئن فورتینت هم میگوید دنبال حسابهای ناشناس «مانند forticloud، fortiuser، fortinet-support، fortinet-tech-support» بگردید.
پیش از هر ریاستارت، نصب مجدد firmware یا بازگشت به تنظیمات کارخانه، از لاگها، پیکربندی و خروجیهای عیبیابی نسخه بگیرید. ایمپلنتی که فقط در حافظه زندگی میکند ردپای دیگری تقریباً باقی نمیگذارد، و مقالهٔ بازیابی فورتینت هم میگوید اول اینها را حفظ کنید.
چرا وصله پایان کار نیست
FortiGate وصلهشده با همان رمز مدیر، همان رمز کاربران VPN و همان کلیدهای IPsec هنوز برای کسی که پیکربندی قدیمی را بازگشایی کرده باز است. نتیجهگیری Unit 42 صریح است: مواد اعتمادی که از یک پلتفرم مدیریت برده میشود «همراه مهاجم میرود و تا وقتی عوض نشود معتبر میماند.» همین حرف را دربارهٔ تجهیزات لبهٔ شبکه در مقالهٔ Citrix NetScaler: تعویض رمزها بعد از وصله زدیم و الگو عوض نشده است.
راهنمای فورتینت برای دسترسی غیرمجاز به پیکربندی دستگاه، که بعد از ارتقا اجرا میشود، به این ترتیب خلاصه میشود:
- پیکربندی را از یک پشتیبان سالم و مطمئن بازگردانید، یا پیکربندی تمیزی بسازید و محتوایش را بررسی کنید.
- اعتبارنامهٔ همهٔ مدیران، کاربران محلی و کاربران VPN را بازنشانی کنید.
- secretهای RADIUS و کلیدهای از پیش مشترک IPsec را عوض کنید.
- گواهیها را جایگزین و گواهیهایی را که ممکن است دزدیده شده باشند باطل کنید.
- رمز حساب LDAP که FortiGate با آن متصل میشود را عوض کنید.
- ورود مدیران را به میزبانهای مورد اعتماد محدود کنید، دسترسی مدیریتی را از رابطهای بیرونی بردارید و برای مدیران احراز هویت دومرحلهای بگذارید.
بلاگ ژوئن ۲۰۲۶ فورتینت دو نکته اضافه میکند: همهٔ نشستهای فعال مدیر و VPN را قطع کنید، و برای همهٔ حسابهای مدیر و VPN احراز هویت چندعاملی (MFA) بگذارید. نشستها مهماند چون بازنشانی رمز روی تونل VPNای که همین حالا برقرار است اثری ندارد. اگر FortiGate کاربران را با Active Directory احراز هویت میکند، حساب سرویس LDAP و هر رمزی که از مسیر RADIUS یا LDAP شنودشده عبور کرده باید لو رفته فرض شود و لاگهای domain controller هم باید بررسی شوند. ورودهای دزدیدهشدهٔ VPN همان راهی است که گروههای باجافزاری از آن وارد میشوند، همانطور که نهادهای امنیتی در مقالهٔ باجافزار SafePay شرح دادند، و MFA قابل فیشینگ هم تا حدی کمک میکند که در مقالهٔ فیشینگ AiTM به آن پرداختیم.
اگر یک شرکت پیمانکار FortiGate شما را مدیریت میکند
قربانی پروندهٔ Unit 42 یک ارائهدهندهٔ خدمات مدیریتشده (MSP) بود و آرشیو دزدیدهشده فایروالهای مشتریانش را هم شامل میشد. Unit 42 میگوید شبکههای آن مشتریان را بررسی نکرده، پس ادعای نفوذ به آنها را ندارد. اگر یک MSP فایروال شما را از طریق FortiManager یا کنسول مشابهی اداره میکند، همین هفته سه سؤال از او بپرسید: دستگاه شما چه نسخهای از FortiOS دارد، آیا پلتفرم مدیریتشان هیچوقت در معرض CVE-2024-47575 بوده، و رمزهای مدیر، VPN و IPsec شما آخرین بار کی عوض شدهاند. اگر کسی جواب سؤال سوم را نمیداند، فرض کنید جواب «زمان نصب» است.
پرسشهای متداول
آیا CVE-2025-61624 بدون رمز قابل سوءاستفاده است؟
خیر. فورتینت نوع حمله را «احراز هویتشده» ذکر کرده و توضیح NVD «مهاجم احراز هویتشده با پروفایل مدیر و دستکم مجوز خواندن و نوشتن» را شرط میداند. خطر از اینجاست که این اعتبارنامهها اغلب از طریق فایلهای پشتیبان، رمزهای تکراری یا صفحهٔ ورود رو به اینترنت لو رفتهاند.
روی FortiOS 7.2 هستیم. وصلهای برای 7.2 هست؟
خیر. FG-IR-26-122 همهٔ نسخههای 7.2، 7.0 و 6.4 را آسیبپذیر میداند و راهحل را «مهاجرت به نسخهٔ اصلاحشده» گذاشته است. اگر سختافزار شما پشتیبانی کند، به 7.4.10 یا بالاتر، یا 7.6.5 یا بالاتر نیاز دارید.
آیا ریاستارت PEERSTITCH را پاک میکند؟
Unit 42 آن را ساکن حافظه و بدون فایل اجرایی ماندگار توصیف میکند، اما مهاجمان اعتبارنامهٔ معتبر داشتند و میتوانستند برگردند. اول شواهد را جمع کنید، بعد مراحل بازیابی فورتینت را دنبال کنید، از جمله نصب تمیز firmware اگر نفوذ تأیید شد، و همهٔ secretها را عوض کنید.
FortiGate ما هیچوقت دسترسی مدیریتی روی WAN نداشته. در امانیم؟
کمتر در معرضید، اما خودبهخود در امان نیستید. در پروندهٔ Unit 42 مهاجمان پیکربندیها را از سرور مدیریت گرفتند و از طریق SSL VPN وارد شدند. به هر حال وصله کنید، محل نگهداری پشتیبانهای پیکربندی را بررسی کنید و از فعال بودن MFA روی حسابهای VPN مطمئن شوید.
اول کدام اعتبارنامهها را عوض کنیم؟
اول حسابهای مدیر و کاربران VPN، چون دسترسی مستقیم میدهند، بعد کلیدهای از پیش مشترک IPsec، secretهای RADIUS و حساب LDAP، و بعد گواهیها. قطع نشستهای فعال را هم بخشی از همین تغییر کنید.
برای ارتقا، جستوجوی نشانههای نفوذ یا تعویض اعتبارنامهها کمک لازم دارید؟ تیم ابر و DevOps فنپینو این کار را برای شرکتهای کوچک و متوسط انجام میدهد.
منابع: هشدار PSIRT فورتینت FG-IR-26-122، هشدار KEV سازمان CISA، ۱۶ اکتبر ۲۰۲۶، NVD CVE-2025-61624، گزارش PEERSTITCH از Unit 42، ۱۴ اکتبر ۲۰۲۶، راهنمای بازیابی فورتینت، بلاگ PSIRT فورتینت، ژوئن ۲۰۲۶. اطلاعات نسخهها در ۲ نوامبر ۲۰۲۶ بررسی شد.



