Эндпоинты метаданных в облаке: скрытая поверхность атаки

Каждый крупный облачный провайдер предоставляет виртуальным машинам на своей платформе сервис метаданных инстанса, обычно доступный по link-local-адресу 169.254.169.254. Изнутри инстанса простой HTTP-запрос к этому адресу может вернуть конфигурацию инстанса, сетевые параметры и, во многих конфигурациях по умолчанию, временные учётные данные для роли или идентификатора, назначенных этому инстансу.

Почему опасно именно сочетание с SSRF

Эндпоинт метаданных должен быть доступен только с самого инстанса и не выставляется в публичный интернет. Но если серверный процесс удаётся обманом заставить отправить HTTP-запрос на адрес, выбранный атакующим (классическая SSRF), и этим адресом оказывается эндпоинт метаданных, сервер сам получает собственные облачные учётные данные и отдаёт их в ответе. Прямой сетевой доступ к эндпоинту метаданных снаружи не нужен: запрос выполняет уязвимый сервер от имени атакующего.

• 169.254.169.254 входит в более широкий link-local-диапазон 169.254.0.0/16, который ни в коем случае нельзя считать допустимой целью публичного DNS-разрешения.
• Некоторые провайдеры перешли на версию сервиса метаданных с токеном, чтобы затруднить простые SSRF-атаки, но полная блокировка адреса на уровне приложения остаётся более надёжной защитой.
• Именно поэтому link-local-адреса должны входить в тот же чёрный список, что и приватные и loopback-диапазоны, в любом инструменте, который разрешает домены, введённые пользователем: это не отдельная и не менее серьёзная категория риска.

Практический вывод

Любая система, которая разрешает и запрашивает URL по поручению пользователя, должна считать адрес 169.254.169.254 и весь link-local-диапазон, в котором он находится, строго запрещённым. Проверять это нужно в момент самого запроса и каждый раз, независимо от того, как был получен адрес: введён напрямую или достигнут через DNS-запись, которая указывает прямо на него.

Проблема не ограничена одним облачным провайдером

Адрес 169.254.169.254 — это соглашение AWS, Google Cloud и Azure, но сам принцип (link-local-адрес, который открывает идентификатор и учётные данные инстанса только ему самому) в том или ином виде встречается практически на всех крупных облачных и контейнерных платформах: иногда по тому же адресу, иногда по адресу, специфичному для провайдера. В кластерах Kubernetes обычно есть собственные внутренние эндпоинты, похожие на метаданные и доступные изнутри пода. Конкретный адрес стоит запомнить для распространённых облачных провайдеров, но по-настоящему универсален общий принцип: любой эндпоинт в стиле метаданных должен быть закрыт для всего, что разрешает и запрашивает URL, введённый пользователем, на какой бы платформе оно ни работало.

IMDSv2: реальная защита, а не просто фильтр

Ответом AWS на годы именно такой эксплуатации стала вторая версия сервиса метаданных, IMDSv2. Она требует получить токен сессии специальным PUT-запросом, прежде чем можно будет прочитать какие-либо метаданные, и, что принципиально, такой PUT-запрос нельзя воспроизвести простым GET-запросом, который чаще всего и выполняют уязвимые участки кода при SSRF.

Это ощутимое улучшение, но на многих аккаунтах оно включается по желанию ради обратной совместимости и защищает только сам эндпоинт метаданных: для всех остальных приватных и внутренних адресов, до которых SSRF всё равно может добраться, оно ничего не делает. Фильтрация разрешённых адресов на уровне приложения остаётся необходимой независимо от того, какая версия сервиса метаданных используется.