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

Запись

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, включая support files с конфигурационными и диагностическими данными.

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 и другие изменения конфигурации.