Rancher Manager умеет пересылать запросы от имени пользователя через встроенный метапрокси. Список разрешённых адресов у него есть, но проверка стояла там, где уже не могла остановить пересылку. Отказ попадал в журнал, а сам запрос всё равно уходил дальше. В результате любой прошедший аутентификацию пользователь мог отправить запрос с сервера Rancher на внутренние хосты, недоступные ему напрямую.
Что именно ломалось
Метапрокси нужен, чтобы сервер Rancher пересылал запросы только к заранее перечисленным адресам. Проверку списка выполняли до обработчика, который оборачивает обратный прокси. Отклонённый адрес записывался в журнал, но запрос уже передавался транспорту прокси. Пользователь сам выбирал метод, заголовки, тело и строку запроса. Ответ возвращался ему.
Уязвимость получила идентификатор CVE-2026-88809 и высокий уровень опасности. Оценка CVSS 3.1 - 7.6. Класс - SSRF, подделка запросов на стороне сервера: сервер выполняет обращение по адресу, который выбрал пользователь. Для атаки хватает учётной записи Rancher. Права администратора в локальном кластере не нужны.
На практике это даёт чтение данных из внутренних систем и отправку запросов с сетевой позиции сервера Rancher. В части окружений доступен эндпоинт метаданных облачного экземпляра. Например, в AWS при включённом IMDSv1 оттуда можно забрать учётные данные облачного провайдера.
Условия атаки
Запрос должен дойти до сервера Rancher по HTTP/1.1 с полным адресом назначения в строке запроса. HTTP/2 такую форму передать не может. Прокси, которые разбирают HTTP, переписывают или отбрасывают такие запросы.
Проверяли nginx, Traefik, Envoy и HAProxy - каждый из них закрывает этот путь. Поэтому трафик через Ingress, который создаёт установка по умолчанию Helm, блокируется, пока его обслуживает один из этих контроллеров. Однако несколько поддерживаемых конфигураций оставляют прямой путь открытым.
Обращение к сервису Rancher из пода локального кластера. Режим без внешнего доступа вместе с балансировщиком четвёртого уровня. Сквозное шифрование TLS. Публикация через порт узла или сеть узла.
Опираться на Ingress как на защиту не стоит. Он сужает круг тех, кто дотянется до уязвимого эндпоинта. При этом поды локального кластера достают до сервиса Rancher напрямую при любой установке.
Что меняет патч
Исправление переносит проверку списка в обработчик, который оборачивает обратный прокси. Запрос к адресу вне списка отклоняется до установки соединения. Клиент получает ошибку, а не содержимое от прокси.
Правка только на стороне сервера. Запросы к разрешённым адресам пересылаются как раньше, ломающих изменений нет. Обновиться нужно до 2.15.3, 2.14.7, 2.13.11, 2.12.15 или 2.11.19 - по своей ветке. В записи CVE отдельно отмечено, что под вопросом и более старые версии, поддержка которых закончилась.
Сведений об эксплуатации в реальных атаках нет. CISA ADP указывает Exploitation: none.
Пока обновления нет
Полностью закрыть проблему обходной мерой нельзя. Снизить риск помогают три вещи.
Первое: пустить весь трафик к серверу Rancher через прокси или Ingress-контроллер, который разбирает HTTP. Не через балансировщик четвёртого уровня, сквозное TLS, прямой сервис, порт узла или сеть узла. Второе: правилами NetworkPolicy в локальном кластере запретить рабочим подам подключаться к портам сервиса Rancher. Доступ при этом оставить контроллеру Ingress и остальным компонентам, которым он нужен. Третье: ограничить исходящий трафик самого сервера Rancher сетевыми политиками или группами безопасности. Тогда он не дойдёт до внутренних сервисов и эндпоинта метаданных.
Если есть подозрение, что установку использовали до обновления, смените учётные данные, доступные с сетевой позиции сервера Rancher. В том числе облачные, которые выдаёт эндпоинт метаданных.
Журналы помогут лишь отчасти. Каждая попытка оставляет строку Failed to proxy. Но обычные отклонённые запросы пишут ту же строку, поэтому по журналу нельзя понять, ушёл запрос дальше или нет.
Уязвимость нашёл исследователь под ником D0HY30N.
Ссылки
