Отличный материал:
Ник Пратли 4 сентября 2026 года опубликовал полный разбор “тихого” патча MikroTik. Вот суть.
Что случилось
3 сентября 2026 года MikroTik одновременно выкатил RouterOS 7.23.4 (long-term), 7.24.2 (stable) и 6.49.21 (v6) с одной и той же формулировкой: “важное обновление безопасности, детали пока не раскрываем”. Автор правильно заметил: когда ты выкладываешь пропатченный бинарник на зеркало — ты уже раскрываешь уязвимость. Diff между версиями и есть advisory.
Три уязвимости
1. SSH-пользователь -2 -> полный root
Самая критичная и уже активно эксплуатируемая. В RouterOS SSH-демон передаёт имя пользователя и маску прав в
/nova/bin/login как позиционные аргументы. Если имя начинается с
-, login воспринимает это как номер файлового дескриптора и читает из него доверенные данные. PTY (псевдотерминал) в SSH использует fd 0, 1, 2. Поэтому:
• Пользователь логинится по SSH с именем
-2
• Login читает данные из stderr/PTY (fd 2)
• Атакующий отправляет два NUL-разделённых поля: имя и маску политики
• Маска
654958 =
0x9fe6e = полные права RouterOS
Автор воспроизвёл атаку в лабе: read-only сессия получала полный административный доступ. В логах RouterOS это выглядело как
user ops added by ssh:-2@<адрес> — именно это видели администраторы на скомпрометированных роутерах.
Ограничение: SSH должен принять имя
-2 при аутентификации. Через локальную базу пользователей это не работает. Через RADIUS или User Manager — работает. Как именно атакующие в реальных инцидентах проходили этот барьер — пока неизвестно.
2. RSA-подпись без приватного ключа (forgery с e=3)
В
libucrypto.so функция
parseHashFromDerEncoded при проверке PKCS#1 v1.5 подписи не проверяла, что после извлечённого дайджеста в буфере ничего нет. Кроме того, проверка паддинга
FF FF FF... не требовала минимального количества байт — достаточно было
00 01 00.
Если для аккаунта авторизован RSA-ключ с экспонентой
e=3, атакующий может:
1. Взять публичный ключ (это не секрет)
2. Сформировать префикс:
00 01 00 || DER(SHA-256 DigestInfo) || хэш || мусор
3. Взять кубический корень от этого числа
Кубирование при проверке восстанавливает корректный префикс, мусор в хвосте 7.23.3 игнорировал. Автор подтвердил: SSH-аутентификация без приватного ключа работала на 7.23.3, на 7.23.4 — отказ.
Затронуты все потребители этой функции: SSH, IPsec/IKEv2, TLS (ssld), ACME (cloud).
3. Переполнение стека в mtget через TFTP
В
nova/bin/mtget при формировании TFTP-запроса имя удалённого файла копировалось в стековый буфер фиксированного размера через
rep movsb без проверки длины. Команда:
/tool fetch url="tftp://10.0.2.2/<длинный путь>" keep-result=no
Это аутентифицированная атака, но право
test входит в стандартную группу
read. То есть read-only оператор может её выполнить. Автор подтвердил контролируемое перезаписывание
EIP и выполнение произвольного ROP-вызова.
Связанные цепочки атак
Цепочка 1: известный публичный RSA e=3 -> подделка SSH-подписи -> аутентифицированный пользователь с правом
test -> crafted TFTP URL -> ROP в mtget.
Цепочка 2: SSH принимает имя
-2 (через RADIUS/User Manager) -> PTY-инъекция политики -> полные права -> создание пользователя
ops в группе
full -> опционально mtget.
Дополнительные исправления в 7.23.4
•
www: блокировка path traversal (
/../)
• SSH/SCP: проверка путей при рекурсивном копировании
•
diskd: проверка размеров в локальном RPC
• DHCP: замена небезопасных
sprintf на bounded-форматирование
• MAC-Telnet: закрытие скрытого API-транспорта через имя пользователя
\x06/login
• В
nova/bin/mode добавлен детект и автоочистка следов кампании (пользователь
ops, домены
mythtime.xyz,
leappoach.info,
eeongous.com)
Что делать прямо сейчас
1. Обновить до 7.23.4 / 7.24.2 / 6.49.21 или новее
2. Проверить
/system/device-mode/print — если
flagged: yes, роутер считать скомпрометированным
3. Найти неожиданного пользователя
ops в группе
full
4. Поискать в логах записи
ssh:-2@<адрес>
5. Проверить scheduler на записи с
fetch,
/poll/<UUID> и
import
6. Проверить конфигурацию RADIUS и User Manager
7. Аудит SSH RSA-ключей на предмет
e=3 — заменить на Ed25519/ECDSA или RSA
e=65537
8.
