В AWS Bedrock AgentCore обнаружили обход шлюза через поддельные JWT
Исследователи выявили уязвимости в коммуникации между компонентами AWS Bedrock AgentCore Runtime и службой метаданных микровиртуальной машины (MMDS), а также продемонстрировали атаку на внутренние механизмы платформы. Впоследствии AWS добавил взаимную аутентификацию TLS для взаимодействия с платформенным прокси.
Перенаправление журналов через MMDS
Платформенный компонент Logger периодически получал предподписанный URL S3 по незашифрованному HTTP. При этом он не проверял токен аутентификации MMDS и не подтверждал адрес назначения. Исследователи подделывали ответы MMDS и перенаправляли внутренний вывод Logger в управляемый злоумышленниками бакет S3.
Собранные журналы содержали сведения о загрузке платформы, переходах между состояниями жизненного цикла, предоставлении сертификатов TLS, инициализации прокси и обработке вызовов. Из логов исследователи установили, что платформенный прокси построен на основе фреймворка Pingora от Cloudflare. Он завершает входящие соединения и маршрутизирует вызовы в контейнеры агентов.
Прокси получал из MMDS материалы TLS и симметричный ключ подписи. Эти данные использовались при проверке JWT рабочих нагрузок, связанных с доступом к вызовам AgentCore. Прокси проверял только утверждения о сроке действия токена, exp, и идентификаторе группы, gid. Остальные утверждения обрабатывались как метаданные и проверке не подвергались.
Подделка токенов и доступ к контейнерам
Используя ключ подписи из MMDS, исследователи создали минимальные JWT, в которых присутствовали только необходимые утверждения. С такими токенами им удалось вызвать агента через локальный прокси.
В продемонстрированном сценарии злоумышленнику потребовались бы уязвимость SSRF с поддержкой метода POST в среде агента и доступ к MMDS при невозможности извлечения раздела с учётными данными. Подделанный токен мог бы инициировать новые сессии контейнеров напрямую через внутренний прокси-сервер, минуя шлюз API Bedrock и не создавая соответствующего события в CloudTrail.
Прокси также пересылал внутренние заголовки без санитарной обработки. Подделка заголовка x-aws-proxy-ip не влияла на маршрутизацию. Манипуляция заголовком x-aws-proxy-port изменяла адрес конечной точки на стороне сервера и могла приводить к сбоям при установлении соединений.
Путь вызова и изменения в AWS
Исследователи восстановили путь вызова от сервисной ячейки к локальному прокси и контейнеру. Они также зафиксировали проблему конкатенации ответов, связанную с преобразованием HTTP/2 в HTTP/1.1. Практическую эксплуатацию этой уязвимости исследователи не подтвердили.
После этого AWS добавил взаимную аутентификацию TLS для коммуникации с платформенным прокси. Изменение предотвратило прямое использование описанного вектора атаки сессиями контейнеров.
Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.
Ознакомиться подробнее с отчетом можно по ссылке.
