Перейти до вмісту
-Advanced
UA RU
093 442 18 08 Консультація

Post

MikroTrick у MikroTik RouterOS: як закрити критичні SSH-вразливості

CERT Polska підтвердила активні атаки на пристрої MikroTik RouterOS, у яких SSH доступний із публічних мереж. Ланцюжок отримав назву MikroTrick: комбінація двох помилок дозволяє без автентифікації отримати повний контроль над пристроєм. Виправлення вже доступні, тому пріоритетна дія - оновити RouterOS і перевірити, чи не було сторонніх змін.

Під час цього розкриття опубліковано шість CVE, що стосуються SSH server/client, bandwidth-test, перевірки X.509 і WebFig. Не можна стверджувати, що кожна з шести вразливостей окремо активно експлуатується. Підтверджені атаки стосуються саме комбінованого SSH-ланцюжка.

Коротко: що робити адміністратору

  1. Визначити точну версію RouterOS на кожному пристрої.
  2. Якщо SSH, WWW/WWW-SSL або bandwidth-test доступні з недовірених мереж - закрити таку експозицію до оновлення.
  3. Оновити RouterOS до 6.49.21, 7.23.4, 7.24.2 або новішого погодженого випуску відповідної гілки.
  4. Після перезавантаження перевірити Log і Flagged.
  5. Переглянути users, SSH keys, scripts, scheduler, proxy, tunnels і незнайомі зміни firewall/NAT.
  6. Якщо є ознаки компрометації - контрольовано ізолювати пристрій, не очищати Flagged і не робити reset до збереження журналів та конфігурації.
  7. Визначити scope, відкликати або замінити пов'язані credentials із довіреного середовища та відбудувати пристрій із перевіреної конфігурації.

Які версії RouterOS уразливі

Для всіх шести опублікованих CVE зазначені однакові діапазони:

Гілка RouterOS Уразливі версії Виправлена межа
6.x від 6.0.0 до версій нижче 6.49.21 6.49.21 Long-term
7.0-7.23 від 7.0.0 до версій нижче 7.23.4 7.23.4 Long-term
7.24 від 7.24 до версій нижче 7.24.2 7.24.2 Stable

MikroTik також включила виправлення до 7.25 beta 3. Для production не потрібно переходити на beta лише через цей advisory, якщо для вашої гілки є погоджений Stable або Long-term випуск.

Фраза «RouterOS 7.23 захищена» без номера patch release небезпечна. Версії 7.23.0-7.23.3 входять до уразливого діапазону, а виправлена межа починається з 7.23.4. Для production у гілці 7.23 слід обирати 7.23.5 або новіший погоджений випуск: за офіційним changelog версія 7.23.5 виправляє проблему IPv6 DHCP, внесену в 7.23.4.

Як безпечно перевірити версію

Використовуйте наявний довірений канал керування. Не відкривайте WinBox або SSH в інтернет спеціально для діагностики.

Read-only команди:

/system/resource/print
/system/package/print
/system/package/update/print
/system/routerboard/print

Зафіксуйте:

  • модель і архітектуру;
  • поточну версію RouterOS;
  • канал оновлень;
  • установлені пакети;
  • версію RouterBOARD firmware;
  • вільне місце;
  • роль пристрою в мережі.

Перевірте кожен MikroTik окремо. Резервний маршрутизатор, CAPsMAN-контролер або вузол у філії може мати іншу гілку RouterOS.

Що входить до MikroTrick

CVE-2026-67276 - підміна SSH-користувача

RouterOS порівнювала RSA public key не повністю: перевіряла тип і modulus, але не exponent. Знаючи ім'я користувача та публічний modulus його ключа, атакувальник міг сформувати інший ключ, пройти перевірку підпису й відкрити SSH command channel від імені цільового облікового запису без його private key.

Отримані права відповідають правам атакованого користувача. Саме тому спільні адміністративні облікові записи та надмірні policy masks додатково збільшують наслідки.

CVE-2026-86060 - підвищення привілеїв SSH-сесії

Помилка обробки аргументів у SSH login path дозволяла через спеціально сформоване ім'я користувача змінити trusted RouterOS policy mask. Результатом могло бути підвищення привілеїв до повних адміністративних прав.

CERT Polska описує MikroTrick як комбінацію двох критичних SSH-помилок. Разом обхід входу та підвищення привілеїв пояснюють ризик повного захоплення пристрою без автентифікації.

Ще чотири вразливості в тому самому пакеті

CVE-2026-67277 - витік пам'яті та перезапуск через bandwidth-test

Неавтентифіковане related-з'єднання btest могло перейти у стан, доступний лише після входу. Наслідки включають розкриття фрагмента kernel memory та remote DoS із перезапуском ядра RouterOS.

CVE-2026-67278 - підміна TLS-сервера

RouterOS приймала некоректні RSA/PKCS#1 v1.5 signatures під час перевірки X.509. За умови контролю або перенаправлення вихідного TLS-з'єднання атакувальник міг підмінити довірений сервер. До оновлення не слід використовувати вбудовані SSH clients або вихідні TLS-з'єднання через недовірені мережі.

CVE-2026-67279 - SSH rekey до автентифікації

Після client-requested rekey SSH міг перейти до connection protocol, хоча автентифікація ще не відбулася. Це дозволяло відкрити session channel, надіслати exec request і виконувати операції з файлами у керованому RouterOS namespace, включно з файлами підтримки, де можуть бути конфігураційні й діагностичні дані.

CVE-2026-67281 - читання файлів через WebFig

Помилка в /jsproxy могла дозволити неавтентифіковане читання root-owned files, включно зі сховищами конфігурації з credentials. Практичний висновок - WWW/WWW-SSL не повинні залишатися доступними з недовірених мереж, а після підозри на компрометацію потрібно змінювати не лише пароль адміністратора.

Тимчасове зменшення поверхні атаки

Оновлення не можна замінити firewall-правилом, але до maintenance window потрібно прибрати непотрібний зовнішній доступ.

Read-only інвентаризація:

/ip/service/print
/ip/firewall/filter/print
/ipv6/firewall/filter/print
/tool/bandwidth-server/print

Перевірте:

  • чи доступні SSH, WWW, WWW-SSL, WinBox, API або API-SSL з WAN;
  • чи обмежене керування trusted management network або VPN;
  • чи вимкнений bandwidth-test server, якщо він не потрібний;
  • чи захищений IPv6 input так само, як IPv4;
  • чи немає тимчасових allow rules без власника;
  • чи використовує сам роутер /system ssh, /system ssh-exec або вихідний TLS через недовірені сегменти.

Не вставляйте універсальний firewall-скрипт у production. Правильний порядок залежить від interface lists, VLAN, VPN, динамічних WAN і поточних NAT. Помилка може відрізати адміністратора або зупинити зв'язок між офісами.

Як підготувати оновлення без втрати мережі

До зміни версії підготуйте:

  • зашифрований binary backup і текстовий export поза маршрутизатором;
  • локальний або out-of-band доступ;
  • maintenance window;
  • список критичних сервісів;
  • changelog цільової версії;
  • критерії rollback;
  • відповідального за перевірку після перезавантаження.

Запишіть, що має відновитися: основний і резервний WAN, DHCP, DNS, публічні NAT, VLAN, WireGuard/IPsec, routing між майданчиками, CAPsMAN, телефонія, NTP, syslog і моніторинг.

Оновлюйте кілька пристроїв послідовно. Спочатку перевірте менш критичний вузол з аналогічною конфігурацією, потім переходьте до решти. RouterBOARD firmware перевіряйте окремо: його оновлення може вимагати додаткового перезавантаження.

Перевірка після оновлення

Після перезавантаження виконайте:

/system/resource/print
/system/device-mode/print
/log/print where topics~"critical"

Потім перевірте:

  • встановлену версію;
  • основний та резервний інтернет;
  • DHCP і DNS із клієнтських VLAN;
  • NAT і доступність погоджених публічних сервісів;
  • VPN tunnels і маршрути між офісами;
  • CAPsMAN та точки доступу;
  • logging, NTP і моніторинг;
  • users, groups, SSH keys і certificates;
  • scripts, scheduler, proxy servers і tunnels;
  • невідомі файли та незнайомі зміни конфігурації.

Flagged: no не доводить, що пристрій чистий. Механізм виявляє лише відомі виробнику ознаки. Перевірка users, scripts та інших змін потрібна навіть без Flagged.

Що робити при ознаках компрометації

Якщо Flagged: yes, у Log є critical message, з'явилися невідомі users/scripts або конфігурація не відповідає очікуваній:

  1. Контрольовано ізолюйте пристрій від мережі.
  2. До reset збережіть журнали та конфігураційні матеріали для аналізу.
  3. Не очищайте Flagged до завершення збору evidence.
  4. Визначте, які мережі, VPN, credentials і системи могли бути доступні через роутер.
  5. Відкличте або замініть пов'язані паролі, SSH keys, VPN secrets, certificates та інші credentials із довіреного середовища відповідно до встановленого scope.
  6. Після збереження матеріалів виконайте factory reset і відбудуйте конфігурацію з довіреного, перевіреного джерела.
  7. Видайте пристрою нові secrets і перевірте всі залежні VPN та інтеграції.
  8. Не відновлюйте повний binary backup із потенційно скомпрометованого пристрою без перевірки.
  9. Задокументуйте scope, виконані дії та acceptance test.

Просте встановлення патча не видаляє вже створеного користувача, script, tunnel або змінене firewall rule.

Acceptance checklist

Роботу можна прийняти, коли:

  • кожен RouterOS переведений на виправлений погоджений реліз;
  • зовнішні management services закриті або доступні лише з trusted network/VPN;
  • Flagged і critical logs перевірені;
  • немає незнайомих users, keys, scripts, scheduler tasks, proxy або tunnels;
  • бізнес-сервіси пройшли post-change test;
  • backup і rollback зберігаються поза пристроєм;
  • результати перевірки задокументовані.

Для ширшої перевірки використовуйте чекліст аудиту безпеки MikroTik RouterOS.

Допомога з терміновим оновленням MikroTik

IT Advanced може провести read-only інвентаризацію версій і зовнішніх сервісів, підготувати backup та rollback, погодити оновлення і перевірити мережеві функції після змін. Якщо є ознаки компрометації, спочатку узгоджується збереження evidence та план відновлення.

Замовити перевірку й оновлення MikroTik

Для первинної оцінки достатньо моделі пристрою, версії RouterOS, каналу оновлень і опису його ролі. Не надсилайте через форму паролі, private keys, VPN secrets або повний export.

Часті запитання

Що таке MikroTrick?

MikroTrick - назва активно експлуатованого ланцюжка з двох критичних SSH-вразливостей RouterOS. Комбінація дозволяє атакувати пристрої з SSH, доступним із публічних мереж, і отримувати повний контроль без автентифікації.

Які версії RouterOS потрібно оновити?

Уразливі RouterOS 6.0.0-6.49.20, 7.0.0-7.23.3 та 7.24-7.24.1. Виправлені межі - 6.49.21 Long-term, 7.23.4 Long-term і 7.24.2 Stable.

Чи достатньо закрити SSH з інтернету?

Ні. Це терміново зменшує ризик експлуатації SSH-ланцюжка, але пакет також містить проблеми bandwidth-test, TLS і WebFig. Закриття сервісів не замінює оновлення.

Чи доводить Flagged: no відсутність компрометації?

Ні. Flagged виявляє лише частину відомих ознак. Навіть за значення no потрібно перевірити users, SSH keys, scripts, scheduler, proxy, tunnels, firewall і незнайомі файли.

Чи можна відновити повний backup після підозри на атаку?

Не слід сліпо відновлювати binary backup із потенційно скомпрометованого пристрою. Спочатку збережіть evidence, потім виконайте factory reset і відбудуйте конфігурацію з довіреного перевіреного джерела.

Чи активно експлуатуються всі шість CVE?

Ні, такого підтвердження немає. CERT Polska підтвердила активну експлуатацію комбінації двох SSH-вразливостей MikroTrick, але це не можна автоматично переносити на кожну CVE окремо.

Як перевірити, що оновлення завершене успішно?

Перевірте версію RouterOS, Flagged і critical logs, потім протестуйте WAN, DHCP, DNS, NAT, VLAN, VPN, CAPsMAN, NTP, logging і моніторинг. Окремо перевірте users, keys, scripts та інші зміни конфігурації.