Уязвимость в RouterOS позволяет обойти аутентификацию в OpenVPN и CAPsMAN через подмену сертификата

В операционной системе RouterOS от компании MikroTik обнаружена критическая уязвимость, получившая идентификатор CVE-2025-42611. Она затрагивает механизмы проверки сертификатов в нескольких встроенных службах, включая OpenVPN, CAPsMAN и Dot1X (протокол 802.1X для контроля доступа к сети). Проблема позволяет злоумышленнику, находящемуся на пути сетевого трафика, обойти аутентификацию клиентов и серверов. Для полного устранения уязвимости требуется ручное вмешательство администратора, даже после установки обновления.

Содержание

Суть проблемы
Затронутые версии и статус исправления
Что делать администраторам
Контекст и последствия
Ссылки

Суть проблемы

RouterOS использует единое системное хранилище сертификатов, которому доверяют все службы. Логика проверки не разграничивает контексты: сертификат, импортированный для одной цели, может быть принят в другой. Например, если администратор добавил в хранилище корневой сертификат публичного центра сертификации (ЦС) для работы с внешними HTTPS-ресурсами, этот же ЦС становится доверенным для аутентификации клиентов OpenVPN или точек доступа в CAPsMAN. При этом службы не проверяют, что сертификат подписан именно тем ЦС, который ожидается, и не всегда сопоставляют имя субъекта (CN) или альтернативные имена (SAN).

Наиболее уязвимы системы, в которых настроено доверие к общедоступным центрам сертификации (например, Let's Encrypt) для защищённых соединений с внешними серверами. В такой конфигурации атакующий может получить легитимный X.509-сертификат (стандартный формат сертификатов открытых ключей) на любой домен через любой публичный ЦС и использовать его для:

полного обхода аутентификации клиента и сервера в CAPsMAN (система управления точками доступа MikroTik);
частичного обхода аутентификации клиента в OpenVPN (требуется только пароль, сертификат игнорируется);
обхода аутентификации сервера 802.1X, что открывает доступ к портам коммутатора.

Последствия различаются в зависимости от конфигурации, но в целом атакующий может выдать себя за точку доступа (CAP) и получить данные беспроводной сети (SSID, пароли, настройки VLAN), имитировать сервер CAPsMAN и переконфигурировать легитимные точки доступа, перехватить управление OpenVPN-сервером или получить доступ к коммутационным портам. Это позволяет злоумышленнику укрепить своё присутствие в сети и расширить зону поражения.

Затронутые версии и статус исправления

Уязвимость присутствует во всех выпусках RouterOS до версии 7.20 включительно. Разработчики выпустили исправление в RouterOS 7.21. Однако, как указано в бюллетене, версии 7.21 и выше всё ещё содержат проблему, но она стала значительно менее опасной при типовых конфигурациях. Главное изменение - теперь требуется ручная настройка области доверия для каждого вручную импортированного сертификата. Если этого не сделать, система остаётся уязвимой.

На момент публикации не известно о циркуляции публичных эксплойтов, но это не снижает риска: уязвимость можно использовать без специальных привилегий, с удалённым доступом и без взаимодействия с пользователем (CVSS 6.5, вектор AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N). Иными словами, атакующему достаточно быть on-path (например, находиться в одной сети) и не требуется никакой предварительной учётной записи на устройстве.

Что делать администраторам

Первоочередная рекомендация - обновить RouterOS до версии 7.21 или новее. После обновления необходимо вручную пересмотреть все импортированные сертификаты. У каждого сертификата есть свойство "trust-store" (область доверия), которое после обновления по умолчанию устанавливается в "all". Это означает, что сертификат будет доверен всем службам, что оставляет лазейку для атак. Администратор должен для каждого сертификата снять лишние флаги и оставить только те области, которые действительно нужны (например, для TLS-соединений с внешними серверами - только "tls", а для VPN-клиентов - "ovpn"). Кроме того, нужно проверить сценарии автоматического импорта сертификатов: если в них явно не указана область доверия, команда по умолчанию устанавливает "all", что вернёт систему в уязвимое состояние.

Дополнительно рекомендуется сегментировать сеть и не полагаться на сертификаты как на единственный фактор аутентификации для OpenVPN и CAPsMAN. В документации MikroTik подчёркивается, что разделить хранилища сертификатов для разных серверов одного типа (например, двух разных OpenVPN-серверов) в текущей реализации невозможно, поэтому использование сертификатов без пароля или других механизмов является рискованным.

Контекст и последствия

Эта уязвимость демонстрирует классическую ошибку неправильного ограничения канала связи (CWE-923) и неверной проверки сертификата (CWE-295). Вместо того чтобы сверять предъявленный сертификат с конкретным доверенным центром, RouterOS доверяет любому сертификату, подписанному любым центром из общего хранилища. Подобные недочёты нередки в встраиваемых системах, где производители стремятся упростить логику аутентификации. Однако в случае с маршрутизаторами MikroTik, широко используемыми в корпоративном и провайдерском секторе, последствия могут быть серьёзными.

Особенно опасна атака на CAPsMAN. Получив конфигурацию беспроводной сети, злоумышленник может узнать пароли Wi-Fi и настройки VLAN, что позволит проникнуть в изолированные сегменты сети. Имитация сервера CAPsMAN даёт возможность внедрить вредоносные настройки на легитимных точках доступа и перенаправлять трафик пользователей. В OpenVPN аутентификация по паролю может быть скомпрометирована отдельно, а отсутствие проверки сертификата делает возможной атаку "человек посередине", когда злоумышленник перехватывает и подменяет VPN-трафик.

Таким образом, CVE-2025-42611 подчёркивает важность грамотного управления сертификатами и ручной проверки конфигураций даже после установки исправлений. Обновление само по себе не устраняет проблему полностью - администраторам придётся потратить время на аудит и настройку. Те, кто пренебрежёт этим шагом, рискуют оставить свои сети открытыми для довольно незаметного вторжения.