Обход digest-аутентификации и отключение mTLS в Traefik нарушают безопасность маршрутов

В популярном реверс-прокси Traefik выявлены четыре уязвимости, три из которых позволяют обойти механизмы аутентификации и доступа. Наиболее серьёзная проблема связана с middleware digestAuth: из-за ошибки обработки неизвестных пользователей любой удалённый клиент может пройти проверку без пароля. Две другие уязвимости приводят к тому, что на маршрутах, требующих взаимной TLS-аутентификации (mTLS), проверка клиентского сертификата перестаёт выполняться. Уязвимы все версии Traefik до v2.11.55 включительно, а также ветка v3 до версии v3.7.11.

Детали уязвимостей

Критическая уязвимость в digestAuth затрагивает механизм HTTP-аутентификации на основе дайджеста. При обращении к защищённому маршруту сервер отправляет клиенту challenge, а клиент должен вычислить ответ, используя имя пользователя и пароль. Из-за ошибки в реализации middleware для пользователя, отсутствующего в настроенном списке, возвращается пустая строка вместо сообщения о том, что такого пользователя не существует. Поскольку остальные параметры для вычисления дайджеста клиент может подобрать самостоятельно или получить из самого challenge, ожидаемый ответ становится полностью вычислимым. В результате любой внешний злоумышленник может отправить запрос с произвольным именем и пустым паролем и успешно пройти аутентификацию на любом маршруте, защищённом digestAuth, включая панель управления и API Traefik, если они закрыты этим методом.

Две другие уязвимости связаны с конфликтами TLS-опций. В Traefik параметры TLS назначаются не самому маршрутизатору, а именам хостов, присутствующим в правилах маршрутизации. Когда несколько маршрутизаторов на одном входном порту используют одно и то же имя хоста с разными TLS-опциями, возникает конфликт. В этом случае Traefik по умолчанию откатывается к стандартным настройкам TLS. Такой откат применяется ко всем хостам, перечисленным в правиле, включая те, для которых конфликта не было. Поэтому маршрут, для которого включена обязательная проверка сертификата клиента, перестаёт её запрашивать, и пользователь без сертификата получает доступ к защищённому бэкенду. Аналогичная ошибка существует в провайдере Kubernetes Ingress NGINX. Для Ingress с аннотацией, задающей проверку клиентского сертификата, имя генерируемой TLS-опции создаётся на основе имени Ingress, а не самой политики mTLS. Два объекта Ingress, использующие один и тот же хост, один и тот же секрет с сертификатом и один и тот же режим проверки, получают разные имена TLS-опций, что также интерпретируется как конфликт и приводит к отключению запроса сертификата.

Четвёртая уязвимость, имеющая средний уровень серьёзности, затрагивает Kubernetes Ingress с опцией crossProviderNamespaces, которая ограничивает, из каких пространств имён можно подключать middleware. Проверка этого ограничения выполнялась для одних аннотаций, но не для другой - traefik.ingress.kubernetes.io/service.middlewares. В результате арендатор, чьё пространство имён исключено из списка разрешённых, мог подключить к своему сервису middleware оператора из другого пространства. Если такой middleware подставляет учётные данные для доступа к бэкенду, арендатор может перехватить их на контролируемом им сервере. Эта проблема затрагивает только ветку v3.7, начиная с версии v3.7.1, где была введена опция crossProviderNamespaces.

На данный момент нет публичных сообщений о реальных атаках с использованием этих уязвимостей. Однако критическая проблема digestAuth может быть проэксплуатирована удалённо без каких-либо предварительных условий, поэтому обновление следует провести в кратчайшие сроки. Особенно важно обновить Traefik в средах, где digestAuth используется для защиты панели управления или API. Даже если эти интерфейсы не доступны из интернета, риск остаётся высоким, поскольку атака может быть проведена из внутренней сети или через скомпрометированные сервисы.

Разработчики подготовили исправленные версии v2.11.55 и v3.7.11. Ветка v1, а также минорные выпуски v2 ниже v2.11 и v3 ниже v3.7 официально не поддерживаются и не получат отдельных исправлений. Пользователям этих версий необходимо перейти на актуальные поддерживаемые релизы. Для устранения уязвимостей, связанных с конфликтами TLS-опций, в дополнение к обновлению требуется явно включить новую статическую опцию strictTLSOptions. Она отключает откат к стандартным настройкам и вместо этого помечает конфликтующие маршрутизаторы как ошибочные. По умолчанию опция отключена, чтобы сохранить прежнее поведение, поэтому после обновления администраторам нужно вручную активировать её.

Эти находки показывают, что даже в зрелых инфраструктурных компонентах ошибки обработки крайних случаев могут полностью нейтрализовать настроенные механизмы безопасности. Внедрение строгих режимов проверки конфигурации становится полезной практикой для администраторов, особенно в многопользовательских Kubernetes-средах, где подобные конфликты сложнее отследить. Своевременное обновление и проверка настроек TLS остаются основными мерами защиты от описанных угроз.

Детали уязвимостей

Ссылки