Введение
3 сентября 2026 года MikroTik выпустил патчи почти одновременно для нескольких поддерживаемых веток RouterOS: 7.25beta3, 7.24.2, 7.23.4 и 6.49.21, и рекомендовал установить патчированную версию как можно скорее. Вендор описал этот релиз как важное обновление безопасности, но временно withheld детали уязвимости, чтобы дать администраторам время обновить свои устройства.
Некоторые из исправлений касались уязвимостей, обнаруженных Славомиром Розбицким из CERT Polska, которые были сообщены вендору через согласованное раскрытие уязвимостей (CVD). Мы планировали синхронизировать публикацию их деталей с релизом обновлений, но новые версии были выпущены раньше, чем мы ожидали. Вендор также использовал push-уведомления в приложении MikroTik, чтобы подчеркнуть необходимость обновления.
Срочность объявления и отсутствие конкретной информации о угрозах вызвали обширные спекуляции на официальном форуме MikroTik. В то же время пользователи начали публиковать логи устройств, предполагая, что атаки могли начаться до того, как патчи стали доступны.
Идентификация CVE-2026-86060
Когда новые версии RouterOS стали доступны, мы начали анализировать различия в патчах, чтобы определить, исправил ли вендор уязвимости, о которых мы сообщали. Пакеты также содержали изменения в механизмах, которые не были охвачены нашими отчетами.
Патчированные версии RouterOS проверяли имя пользователя перед передачей его в приложение /nova/bin/login. Объем этой проверки предполагал, что до патча имя пользователя могло повлиять на то, как программа интерпретировала свои аргументы. Декодированная функция выглядела следующим образом:
Добавлена проверка имени пользователя. Выделенное условие отклоняет имена пользователей, начинающиеся с дефиса (0x2d) или пробела (0x20).
Мы также выявили изменения в механизме Flagged, который обнаруживает записи конфигурации, которые могут указывать на компрометацию. Новое правило проверяло при запуске наличие учетной записи ops, принадлежащей привилегированной полной группе. Если условие выполнялось, RouterOS отключал учетную запись, записывал предупреждение и устанавливал статус Flagged. Введение таких специфических индикаторов компрометации (IoCs) могло означать, что вендор имел по крайней мере частичное представление о атаках.
Затем мы изучили логи, опубликованные администраторами на форуме MikroTik и Reddit. В нескольких отчетах появились две характерные записи:
неудачная попытка входа для пользователя -2 с 82.192.72.4 через ssh
пользователь ops добавлен через ssh:-2@82.192.72.4
Мы заметили, что в этих логах присутствует, казалось бы, противоречивая последовательность: неудачная попытка входа для пользователя -2, за которой следует создание учетной записи ops в рамках одной и той же сессии.
Сочетание этой информации с результатами анализа патчей позволило нам идентифицировать новую критическую уязвимость менее чем за час, присвоить ей идентификатор CVE-2026-86060 и предоставить вендору детали и рабочий скрипт доказательства концепции.
В сочетании с CVE-2026-67279 уязвимость позволяла злоумышленнику получить полные административные привилегии без знания пароля, обладания SSH-ключом или завершения аутентификации. Мы назвали эту цепочку MikroTrick.
CVE-2026-67279
SSH предоставляет несколько административных возможностей, включая удаленный доступ к терминалу, выполнение команд, передачу файлов и туннелирование соединений в рамках зашифрованного канала связи. Протокол состоит из трех последовательных слоев:
транспорт,
аутентификация пользователя,
обработка соединений и каналов.
После установления TCP-соединения клиент и сервер согласовывают криптографические алгоритмы и выполняют обмен ключами для установления общего секрета. Сервер подписывает параметры обмена своим хост-ключом, что позволяет клиенту проверить личность сервера. При первом подключении клиенты часто следуют модели Доверие при Первом Использовании (TOFU). Затем обе стороны извлекают ключевой материал для дальнейшей связи из общего секрета. С этого момента их связь зашифрована и защищена от модификации. Этот этап аутентифицирует сервер для клиента, но еще не пользователя для сервера.
Затем клиент аутентифицирует пользователя одним из разрешенных методов, таких как пароль или открытый ключ. Если аутентификация проходит успешно, сервер отправляет SSH_MSG_USERAUTH_SUCCESS. Только тогда начинается обработка канала, позволяя клиенту получить доступ к оболочке, выполнить команду или использовать другие административные функции в соответствии с привилегиями, назначенными SSH-пользователю. Это разделение указано в RFC 4253, RFC 4252 и RFC 4254.
После первоначального обмена ключами любая сторона может инициировать другой, известный как повторный обмен ключами. Это изменяет транспортные ключи без завершения TCP-соединения или изменения состояния протоколов более высокого уровня. Повторный обмен ключами обычно происходит после передачи определенного объема данных или по истечении определенного времени, но протокол также допускает его до завершения аутентификации пользователя.
Уязвимые версии SSH-сервера RouterOS неправильно обрабатывали повторный обмен ключами, инициированный во время аутентификации пользователя. Когда повторный обмен ключами завершался, сервер безусловно переходил из временного состояния повторного обмена ключами в обработку канала, вместо того чтобы возобновить прерванную аутентификацию. В результате он принимал канал сессии и связанные с ним запросы, несмотря на то, что никогда не отправлял SSH_MSG_USERAUTH_SUCCESS.
Уязвимость не устанавливала аутентифицированную личность или назначала какие-либо привилегии. Однако она позволяла соединению перейти от аутентификации пользователя к обработке канала, что было предпосылкой для эксплуатации CVE-2026-86060.
CVE-2026-86060
После успешной аутентификации клиент может открыть канал сессии. Эксплуатация CVE-2026-67279 обходит это требование. Чтобы создать удаленную консоль, клиент обычно отправляет pty-req, за которым следует shell. Сервер создает псевдотерминал и запускает дочерний процесс, прикрепленный к нему. В RouterOS этот процесс - /nova/bin/login, вызываемый по следующему шаблону:
/nova/bin/login -ssh -trace <trace> -h <client address> [-c <command>] <username> <policy mask>
Во время нормальной работы последний t