آخرین بررسی: ۷ سپتامبر ۲۰۲۶
اگر یک Router یا Firewall مبتنی بر MikroTik RouterOS مدیریت میکنید، این بهروزرسانی امنیتی را نباید مانند یک Update معمولی به تعویق بیندازید.
CERT Polska شش آسیبپذیری امنیتی در RouterOS شناسایی کرده است و تأیید کرده که ترکیب دو آسیبپذیری بحرانی در قالب زنجیرهای با نام MikroTrick در حملات واقعی علیه تجهیزات MikroTik مورد سوءاستفاده قرار گرفته است.
دو آسیبپذیری اصلی این زنجیره عبارتاند از:
CVE-2026-67276
CVSS 9.2
SSH Authentication Bypass
+
CVE-2026-86060
CVSS 9.2
SSH Privilege Manipulation
=
MikroTrickدر سناریوی مورد تأیید CERT Polska، دستگاههایی در معرض خطر بیشتری قرار دارند که سرویس SSH آنها از شبکه عمومی اینترنت قابل دسترس است.
اقدام فوری: RouterOS را به نسخه دارای Fix ارتقا دهید. صرفاً بستن SSH یا محدودکردن Firewall یک راهکار موقت است و جای نصب Patch امنیتی را نمیگیرد.
فهرست مطالب
- MikroTrick چیست؟
- CVE-2026-67276 چیست؟
- CVE-2026-86060 چیست؟
- چهار آسیبپذیری دیگر RouterOS
- کدام نسخههای RouterOS آسیبپذیرند؟
- به چه نسخهای Upgrade کنیم؟
- آیا حملات واقعی تأیید شدهاند؟
- نشانههای احتمالی نفوذ
- Flagged در RouterOS چیست؟
- چگونه Router را بررسی کنیم؟
- اگر فعلاً نمیتوانیم Update کنیم چه کنیم؟
- اگر Router هک شده باشد چه کنیم؟
- بعد از Update چگونه MikroTik را امنتر کنیم؟
- سؤالات متداول
MikroTrick چیست؟
MikroTrick نامی است که CERT Polska برای ترکیب دو آسیبپذیری SSH در MikroTik RouterOS انتخاب کرده است.
CVE-2026-67276
↓
SSH Authentication Weakness
↓
CVE-2026-86060
↓
Privilege Manipulation
↓
Full Administrative Accessاهمیت این زنجیره در این است که مهاجم در شرایط لازم میتواند بدون داشتن Authentication معتبر عادی به دسترسی مدیریتی بسیار بالا روی RouterOS برسد.
این مسئله برای Routerهایی که SSH آنها مستقیماً روی Public IP قابل دسترس است جدیتر است.
CVE-2026-67276؛ ضعف بحرانی در احراز هویت SSH
این آسیبپذیری دارای امتیاز:
CVSS: 9.2است.
مشکل به نحوه بررسی RSA Public Key در فرآیند Authentication مربوط میشود.
RouterOS در نسخههای آسیبپذیر تمام اجزای Public Key را هنگام مقایسه با Key مجاز User بهشکل صحیح بررسی نمیکرد.
در نتیجه در شرایط مشخص، مهاجمی که اطلاعات لازم از Public Key یک User را داشته باشد میتواند Authentication مبتنی بر RSA را دور بزند؛ بدون اینکه Private Key واقعی آن User را در اختیار داشته باشد.
این ضعف به معنی شکستهشدن عمومی RSA نیست. مشکل در نحوه اعتبارسنجی Public Key توسط RouterOS قرار دارد.
CVE-2026-86060؛ دستکاری سطح دسترسی در SSH
دومین Vulnerability بحرانی نیز:
CVSS: 9.2دارد.
این ضعف در پردازش Username در مسیر SSH Login قرار دارد.
یک Username دستکاریشده میتواند باعث تغییر Policy Mask مورد اعتماد RouterOS شود و Session را به سطح دسترسی بالاتری برساند.
در ترکیب با CVE-2026-67276، نتیجه میتواند بسیار خطرناک باشد:
Authentication Bypass
+
Privilege Escalation
=
Administrative CompromiseRouterOS فقط دو آسیبپذیری ندارد؛ شش CVE منتشر شده است
CERT Polska در مجموع شش آسیبپذیری را گزارش کرده است:
| CVE | بخش | اثر اصلی |
|---|---|---|
| CVE-2026-67276 | SSH Authentication | دورزدن Authentication مبتنی بر RSA در شرایط مشخص |
| CVE-2026-86060 | SSH Login | Privilege Escalation |
| CVE-2026-67277 | Bandwidth Test | Memory Disclosure و Remote DoS |
| CVE-2026-67278 | X.509 / TLS | ضعف در اعتبارسنجی RSA Signature |
| CVE-2026-67279 | SSH | انجام برخی عملیات File بدون Authentication کامل |
| CVE-2026-67281 | WebFig | خواندن غیرمجاز فایل در شرایط آسیبپذیر |
CVE-2026-67277؛ Bandwidth-Test نیز آسیبپذیر است
این Vulnerability امتیاز:
CVSS: 8.8دارد.
مشکل باعث میشود یک Client بدون Authentication کامل بتواند Bandwidth-Test را وارد حالتی کند که نباید پیش از Login قابل دسترس باشد.
پیامدهای گزارششده شامل:
- Memory Disclosure
- Kernel Memory Leakage
- Remote Denial of Service
- Restart شدن RouterOS
است.
اگر Bandwidth Test Server از اینترنت در دسترس است و استفادهای از آن ندارید، این Exposure باید حذف شود.
CVE-2026-67278؛ مشکل X.509 و TLS
این Vulnerability به اعتبارسنجی Signatureهای RSA/PKCS#1 v1.5 در فرآیند X.509 مربوط است.
اهمیت آن زمانی بیشتر میشود که RouterOS خودش یک TLS Connection به مقصدی خارج از Router ایجاد کند.
در سناریوی مناسب برای مهاجم، ضعف اعتبارسنجی میتواند زمینه Impersonation سمت TLS Server را ایجاد کند.
CVE-2026-67279؛ SSH قبل از تکمیل Authentication
در این ضعف، SSH State Machine در شرایطی به مرحلهای میرسد که هنوز Authentication کامل نشده، اما Session قادر به انجام برخی عملیات میشود.
اثر گزارششده میتواند شامل ایجاد یا تغییر File در فضای مدیریتشده RouterOS باشد.
CVE-2026-67281؛ آسیبپذیری WebFig
این مشکل در مسیر:
/jsproxyدر WebFig قرار دارد و در شرایط آسیبپذیر میتواند به خواندن File بدون Authentication منجر شود.
این مورد یک دلیل دیگر برای این Best Practice قدیمی است:
WebFig یا WWW/WWW-SSL را مستقیماً برای کل اینترنت باز نگذارید. مدیریت Router بهتر است فقط از Management Network یا VPN انجام شود.
کدام نسخههای RouterOS در معرض این آسیبپذیریها هستند؟
CERT Polska محدوده آسیبپذیر را بهصورت کلی چنین اعلام کرده است:
- RouterOS 7.24 قبل از 7.24.2
- RouterOS 7.x قدیمیتر از نسخه اصلاحشده شاخه مربوطه
- RouterOS 6.x قبل از 6.49.21
روش سادهتر برای Administrator این است که به جای تفسیر نسخههای آسیبپذیر، مطمئن شود نسخه نصبشده حداقل یکی از Releaseهای اصلاحشده یا جدیدتر است.
نسخههای دارای Patch
Fix امنیتی در این Releaseها منتشر شده است:
RouterOS 7 Stable:
7.24.2 یا جدیدتر
RouterOS 7 Long-term:
7.23.4 یا جدیدتر
RouterOS 6 Long-term:
6.49.21
Development:
7.25beta3 یا جدیدتربرای شبکه Production معمولاً Stable یا Long-term مناسبتر از Development/Beta است. هدف این نیست که فقط به 7.25beta3 بروید؛ کافی است Release اصلاحشده مناسب Channel خود را نصب کنید.
نسخه RouterOS را چگونه بررسی کنیم؟
/system resource printیا:
/system package update check-for-updatesدر WinBox نیز:
System
→ Packages
→ Check For Updatesقابل استفاده است.
قبل از Update چه کنیم؟
روی Router عملیاتی ابتدا Backup و Export بگیرید:
/system backup save name=before-security-update
/export file=before-security-updateفایلها را از خود Router نیز خارج کرده و در Storage امن نگهداری کنید.
اگر همین الان به Compromise مشکوک هستید، Backup را فقط بهعنوان Evidence نگه دارید و آن را بعداً بدون بررسی روی Router تمیز Restore نکنید.
آیا MikroTrick واقعاً در حملات استفاده شده است؟
بله.
CERT Polska اعلام کرده است که سوءاستفاده از ترکیب دو Vulnerability اصلی برای تصاحب RouterOSهایی که SSH آنها از Public Network قابل دسترس بوده، در حملات واقعی تأیید شده است.
این موضوع تفاوت مهمی با یک CVE صرفاً آزمایشگاهی دارد.
Vulnerability Published
+
Exploit Chain Known
+
Real-World Exploitation Confirmed
=
Immediate Patch Priorityنشانههای مشاهدهشده در حملات
CERT Polska چند Indicator را در حملات بررسیشده گزارش کرده است.
یکی از Log Patternهای مهم:
login failure for user -2 from <ip> via ssh
user <name> added by ssh:-2@<ip>همچنین User با نام:
opsدر برخی سیستمهای Compromised مشاهده شده است.
نبود این Indicators ثابت نمیکند Router سالم است. اینها فقط نشانههای شناختهشده حملات مشاهدهشده هستند.
IPهای گزارششده در حملات مشاهدهشده
CERT Polska این IPها را در فعالیتهای مشاهدهشده ذکر کرده است:
82.192.72.4
103.102.31.18وجود Connection از این IPها باید بررسی شود؛ اما:
IOCهای IP میتوانند در طول زمان تغییر کنند. Firewall کردن فقط همین دو Address یک راهکار امنیتی کافی نیست و جای Patch را نمیگیرد.
Flagged در RouterOS چیست؟
MikroTik در Releaseهای اصلاحشده از مکانیزم Flagged استفاده میکند.
RouterOS هنگام Startup Configuration را برای برخی نشانههای شناختهشده تغییر غیرمجاز بررسی میکند.
اگر نشانه مشکوکی پیدا شود:
- بعضی Configurationهای مشکوک Disable میشوند.
- یک Critical Log ثبت میشود.
- پارامتر Flagged برابر yes قرار میگیرد.
وضعیت را بررسی کنید:
/system/device-mode/printبه این مقدار دقت کنید:
flagged: yesاگر flagged=yes است، دستگاه را بالقوه Compromised در نظر بگیرید.
اما عکس آن صحیح نیست:
flagged=no
≠
Router قطعاً سالم استمکانیزم Flagged فقط تعدادی از نشانههای شناختهشده Compromise را تشخیص میدهد.
بعد از Update چه چیزهایی را بررسی کنیم؟
۱. Userها
/user print detailهر User ناشناس را بررسی کنید؛ بهخصوص:
ops۲. Scripts
/system script print detail۳. Scheduler
/system scheduler print detail۴. IP Services
/ip service print۵. SOCKS
/ip socks print۶. Web Proxy
/ip proxy print۷. NAT
/ip firewall nat print detail۸. Firewall
/ip firewall filter print detail۹. Interfaceها و Tunnelها
/interface print detail۱۰. Files
/file print detail۱۱. Log
/log printبه موارد مربوط به:
- SSH Login
- User Creation
- Configuration Changes
- Critical Flagged Message
توجه کنید.
اگر فعلاً امکان Update نداریم چه کنیم؟
این اقدامات فقط Temporary Mitigation هستند.
SSH را از اینترنت ببندید
اگر SSH نیاز ندارید:
/ip service disable sshاگر SSH نیاز دارید، دسترسی آن را فقط به Management Subnet یا IPهای Trusted محدود کنید.
WWW را در صورت عدم نیاز Disable کنید
/ip service disable wwwWWW-SSL را نیز بدون نیاز Public نکنید
Management Serviceها بهتر است از VPN در دسترس باشند.
Bandwidth Test Server را بررسی کنید
/tool bandwidth-server printاگر نیاز ندارید:
/tool bandwidth-server set enabled=noWinBox را از Internet Public حذف کنید
حتی اگر Vulnerability اصلی فعلی SSH باشد، Management Plane نباید بدون ضرورت از Internet برای همه Sourceها باز باشد.
برای مدیریت Remote، یک VPN مانند WireGuard انتخاب بسیار مناسبتری از Public SSH، WinBox یا WebFig است. راهنمای اتصال امن با WireGuard را میتوانید مطالعه کنید.
بستن Service جای Update را نمیگیرد. CERT Polska صراحتاً این اقدامات را فقط راهکار موقت کاهش Attack Surface معرفی کرده است.
اگر Router احتمالاً Compromised شده است چه کنیم؟
اگر:
flagged=yesمشاهده کردید،- User ناشناس وجود دارد،
- Script یا Scheduler غیرعادی پیدا کردید،
- Log مشکوک مشاهده کردید،
- Configuration بدون توضیح تغییر کرده است،
صرفاً User مشکوک را Delete نکنید و به کار ادامه ندهید.
مرحله ۱: Router را Isolate کنید
دسترسی مهاجم به Router و شبکه داخلی را محدود کنید.
مرحله ۲: Evidence را حفظ کنید
قبل از Factory Reset:
- Logs
- Configuration
- User List
- Scripts
- Scheduler
- Firewall
- Files
را برای بررسی Incident ذخیره کنید.
مرحله ۳: دستگاه را از منبع قابل اعتماد Rebuild کنید
پس از ثبت Evidence، Router باید Reset و از Configuration قابل اعتماد بازسازی شود.
Full Backup یک Router مشکوک را بدون Audit روی Router تمیز Restore نکنید. ممکن است همان Configuration مخرب را دوباره وارد دستگاه کنید.
مرحله ۴: Credentialها را Rotate کنید
در صورت تأیید یا احتمال جدی Compromise این موارد را تغییر دهید:
- RouterOS Passwords
- SSH Keys
- WireGuard Keys در صورت نیاز
- IPsec Secrets
- PPPoE Credentials
- RADIUS Secrets
- API Credentials
- SNMP Credentials
فرض کنید Secretsی که روی Router قرار داشتهاند ممکن است افشا شده باشند.
بعد از Patch چگونه MikroTik را Hardening کنیم؟
Management را از WAN عمومی حذف کنید
ساختار مناسبتر:
Administrator
↓
WireGuard VPN
↓
Management VLAN
↓
MikroTikنه:
Internet
↓
Public SSH / WinBox
↓
Routerسرویسهای غیرضروری را Disable کنید
/ip service printFTP، Telnet، WWW، API یا SSH را فقط در صورت نیاز فعال نگه دارید.
Management VLAN ایجاد کنید
در شبکههای سازمانی Management Plane باید از User VLAN جدا باشد.
Input Firewall را جدی بگیرید
دسترسی مستقیم به خود Router را فقط برای منابع موردنیاز Allow کنید.
Logها را خارج از Router نگهداری کنید
Remote Syslog باعث میشود مهاجم نتواند با پاککردن Logهای Router تمام Evidence را حذف کند.
Backup منظم داشته باشید
Backup و Export را خارج از Router نگهداری کنید.
RouterOS را بهروز نگه دارید
Routerهای Edge جزو مهمترین Assetهای امنیتی شبکه هستند و Patch Management آنها باید بخشی از فرآیند نگهداری شبکه باشد.
برای Hardening بیشتر مقاله اشتباهات خطرناک در تنظیمات MikroTik را نیز مطالعه کنید.
کدام Routerها اولویت بالاتری برای بررسی دارند؟
اولویت فوری را به دستگاههایی بدهید که:
- Public IP دارند.
- SSH آنها از Internet قابل دسترس است.
- WebFig یا WinBox Public دارند.
- Bandwidth-Test Server فعال و Public دارند.
- Gateway اصلی سازمان هستند.
- VPN Concentrator هستند.
- دسترسی به VLANهای حساس دارند.
- RouterOS قدیمی اجرا میکنند.
اما Update فقط محدود به این دستگاهها نباشد.
برنامه اقدام پیشنهادی برای مدیر شبکه
- Inventory تمام RouterOS Deviceها را تهیه کنید.
- Version هر Router را مشخص کنید.
- Public Exposure سرویسهای Management را مشخص کنید.
- Routerهای دارای Public SSH را در اولویت اول قرار دهید.
- Backup و Export تهیه کنید.
- RouterOS را به Release اصلاحشده ارتقا دهید.
- Router را Reboot کنید.
/system/device-mode/printرا بررسی کنید.- Log را برای Flagged و SSH Indicators بررسی کنید.
- Userها را Audit کنید.
- Scripts و Scheduler را Audit کنید.
- Proxy، SOCKS و Tunnelها را بررسی کنید.
- Firewall و NAT را با Baseline مقایسه کنید.
- Public Management Services را حذف کنید.
- Remote Management را پشت VPN قرار دهید.
- Remote Logging را فعال کنید.
- در صورت مشاهده Compromise، Incident Response کامل اجرا کنید.
بررسی امنیت RouterOS در شبکههای سازمانی
در شبکههای سازمانی صرفاً Upgrade کردن Router کافی نیست. بهتر است Management Plane، Firewall Policy، VPN، User Access و Log Management نیز بررسی شوند.
گروه فناوری ارتباطات پندار بیستون در حوزه طراحی، پیادهسازی و بررسی زیرساختهای MikroTik فعالیت میکند.
اگر MikroTik شما SSH یا Management Service عمومی داشته و درباره احتمال Compromise اطمینان ندارید، قبل از هر تغییر گسترده Evidence را حفظ کرده و Configuration را بهصورت ساختاری بررسی کنید. برای بررسی فنی شبکه میتوانید از مشاوره فنی بیستون استفاده کنید.
سؤالات متداول
MikroTrick چیست؟
نام زنجیره حملهای است که CERT Polska برای ترکیب CVE-2026-67276 و CVE-2026-86060 در RouterOS انتخاب کرده است.
آیا MikroTrick واقعاً مورد سوءاستفاده قرار گرفته است؟
بله. CERT Polska سوءاستفاده واقعی از این زنجیره علیه دستگاههایی با SSH قابل دسترس از شبکه عمومی را تأیید کرده است.
CVE-2026-67276 چقدر خطرناک است؟
CVSS آن 9.2 است و به ضعف در Authentication مبتنی بر RSA در SSH مربوط میشود.
CVE-2026-86060 چیست؟
یک ضعف در مسیر SSH Login است که میتواند در شرایط لازم باعث دستکاری سطح دسترسی و Privilege Escalation شود.
آیا فقط SSH آسیبپذیر است؟
خیر. شش CVE منتشر شدهاند و Bandwidth-Test، X.509/TLS و WebFig نیز در میان Componentهای آسیبپذیر قرار دارند.
به کدام نسخه RouterOS ارتقا دهیم؟
Fix در 7.24.2 Stable، 7.23.4 Long-term، 6.49.21 و 7.25beta3 منتشر شده است. نسخههای جدیدتر همان شاخه نیز Fix را شامل میشوند.
آیا فقط بستن SSH کافی است؟
خیر. این اقدام Attack Surface را کاهش میدهد ولی جای Update امنیتی را نمیگیرد.
چگونه بفهمیم Router هک شده است؟
پس از Update، وضعیت flagged، Logها، Userها، Scripts، Scheduler، Proxy، SOCKS، Tunnelها و سایر Configurationها را بررسی کنید.
چگونه Flagged را بررسی کنیم؟
/system/device-mode/printاگر flagged=no باشد Router سالم است؟
الزاماً خیر. نبود Flag فقط به معنی پیدا نشدن نشانههای شناختهشده توسط مکانیزم فعلی RouterOS است.
وجود flagged=yes چه معنایی دارد؟
باید آن را نشانه جدی Unauthorized Access در نظر گرفت و Router را وارد فرآیند Incident Response کرد.
User با نام ops چیست؟
CERT Polska در حملات بررسیشده وجود یک User بسیار پرقدرت با نام ops را بهعنوان یکی از Indicators گزارش کرده است.
اگر ops وجود نداشته باشد Router سالم است؟
خیر. مهاجم میتواند Artifactهای متفاوتی ایجاد کند و نبود این User Compromise را رد نمیکند.
آیا RouterOS 6 نیز آسیبپذیر است؟
بله. برای شاخه v6 نسخه 6.49.21 شامل Fix منتشر شده است.
آیا بعد از هک میتوان Full Backup قبلی را Restore کرد؟
اگر Backup از زمانی باشد که احتمال Compromise وجود داشته، نباید بدون Audit دوباره Restore شود.
بعد از Compromise باید Password را تغییر دهیم؟
فقط Password Router کافی نیست. همه Credentialها و Secretهای قابل دسترس از Router باید براساس Scope حادثه Rotate شوند.
بهترین روش Remote Management چیست؟
Management Serviceها را از Public Internet حذف کرده و از VPN مانند WireGuard و Management VLAN استفاده کنید.
جمعبندی؛ این Update را به تعویق نیندازید
موضوع MikroTrick فقط انتشار چند CVE جدید نیست.
سه عامل این Incident را مهم میکنند:
Critical CVSS
+
Authentication / Privilege Weakness
+
Confirmed Active Exploitationاگر MikroTik مدیریت میکنید، ترتیب اقدام صحیح این است:
Update RouterOS
↓
Check Flagged
↓
Review Logs
↓
Audit Users / Scripts / Scheduler
↓
Check Firewall / Proxy / Tunnels
↓
Remove Public Management Access
↓
Use VPN for Administrationاگر Router نشانهای از Compromise دارد، فقط Patch کردن کافی نیست؛ باید فرض کنید مهاجم قبلاً داخل دستگاه بوده و Incident Response کامل انجام دهید.
دیدگاه خود را بنویسید