CynepMyx Jul 22 at 08:29

Письмо, которое ходит за вас: разбираю свежий SSRF в Roundcube на живом стенде

Medium

8 min

5.5K

Information Security * System administration *

Case

Comments 6

CitizenOfDreams Jul 22 at 08:44

А начиналось все с того, что кому-то захотелось писать письма красивыми цветными буковками и шрифтом Comic Sans.

CynepMyx Jul 22 at 16:56

Именно. Каждая фича, которая рендерит что-то из письма, это ещё один парсер над чужим вводом. Хотели Comic Sans, получили SSRF через CSS. Красота требует жертв, обычно чужих.

max9 Jul 22 at 08:52

Разработчики знали про DNS-сервисы, которые резолвят имя вида 10.0.0.1.nip.io в IP 10.0.0.1

чего только не придумают, лишь бы локальный днс не поднимать

CynepMyx Jul 22 at 16:56

И ведь nip.io вещь удобная, для локальной разработки золото. Просто у любого удобного шортката есть тёмная сторона: тут он превратился в готовый обход фильтра приватных адресов. Разработчики Roundcube про nip.io знали и развернули его обратно, а про sslip.io забыли. Одна забытая строчка.

whale3070 Jul 23 at 05:45

Очень основательный разбор. Особенно ценна часть с воспроизведением SSRF в контейнерах и захватом логов — это намного нагляднее, чем просто читать описание CVE. Обход фильтра nip.io через sslip.io — типичный пример: сложность защиты от SSRF именно в том, что поверхность атаки постоянно расширяется с появлением новых сервисов, и чёрный список всегда отстаёт. Подход с мониторингом, описанный в статье, заслуживает внимания: аномальные исходящие запросы от процесса веб-сервера — действительно более фундаментальный сигнал, чем попытка закрыть каждую дыру на уровне приложения. Кстати, вопрос: в облачных средах с IMDS v2 (где для доступа к метаданным нужен токен через PUT-запрос) — такая цепочка эксплуатации SSRF всё ещё проходит?

CynepMyx Jul 23 at 05:45

Спасибо. Вопрос про IMDS по делу, и ответ скорее нет, но с оговоркой.

Вектор в Roundcube умеет только GET через <link rel=stylesheet>: сервер сам ходит по URL из письма. А IMDSv2 так просто не отдаст. Там сначала нужен PUT на /latest/api/token с заголовком X-aws-ec2-metadata-token-ttl-seconds, и только потом GET с полученным токеном в заголовке X-aws-ec2-metadata-token. Из этого SSRF ни метод на PUT не поменять, ни свой заголовок не подставить, поэтому в режиме required прилетит 401. Плюс у ответа на PUT hop-limit по умолчанию 1, это ещё режет проксирование через контейнер. Отдельно: PUT с заголовком X-Forwarded-For вообще отклоняется, специально против SSRF через прокси.

Итог: на инстансе с IMDSv2-only цепочка обрывается. Проходит она если оставлен IMDSv1 (голый GET без токена) или если рядом торчит другой внутренний GET-эндпоинт: метрики, Redis по HTTP, админка без авторизации. Мораль та же, что в статье: приложение латаешь одним, а доступ к 169.254.169.254 закрываешь на уровне egress и настройками самого IMDS.

Честно оговорюсь: стенд у меня был в Docker, без облачного IMDS, так что это разбор протокола по докам AWS, а не то что я поднял живой EC2 и потыкал. Соберу на реальном инстансе, отпишу отдельно.