Десинхронизация Незер-портала (HUUP)

"Я путешествую не по проложенным дорогам, а свободно прыгаю через пустоту. Упакуй меня неправильно, и я доставлю секрет не на тот порог."

Описание

Задача представляет собой приложение HTTP/3 (QUIC), работающее поверх UDP. Поскольку UDP не сохраняет состояние, а прокси не обеспечивает строгих границ HTTP-запросов, как TCP, возможна десинхронизация прокси и внутреннего сервера. Атакующий может внедрить скрытый HTTP-запрос внутрь другого запроса.

Примечания: максимальная длина сообщения — 1024 байта, реально работают только GET-запросы, сообщения удаляются через 10 секунд

Цель: byuctf.xyz:40011

Анализ уязвимости

• Уязвимость: Контрабанда HTTP-запросов (через UDP/QUIC)
• Корневая причина: Несогласованный анализ границ HTTP-полезной нагрузки между прокси-сервером и серверным приложением в условиях ненадёжных протоколов.

В этой конкретной реализации Python-промежуточное ПО (udp_server.py) прослушивает порт 40000 для входящего текста. Этот сервер пересылает запросы фактическому веб-серверу, как только находит \r\n\r\n. Поскольку используется UDP, существует высокая вероятность частичной доставки пакетов, что приводит к десинхронизации, если отправлять несколько запросов быстро или манипулировать границами пакетов.

Разбор решения

Чтобы решить эту задачу, необходимо учесть ненадёжность UDP и то, как именно промежуточное ПО обрабатывает границы запросов.

1. Разведка: Доступ к корневой точке / выявляет подсказку о нестабильности соединения Незера.
2. Обнаружение эндпоинтов: Перейдите к /endpoints.txt, чтобы найти список из 200 возможных скрытых точек.
3. Перебор: Один из этих эндпоинтов содержит флаг, а три остальных возвращают ложные срабатывания.
4. Владение протоколом: Из-за UDP-промежуточного ПО стандартный браузерный запрос может не получить полное тело ответа (могут вернуться только заголовки до закрытия соединения или тайм-аута).
5. Автоматизация: Напишите скрипт (см. solve.py), который отправляет сырые HTTP-запросы по UDP к цели. Скрипт должен перебирать эндпоинты и повторно запрашивать каждый из них, пока не будет получен полный ответ (содержащий тело).

Устранение

• Убедитесь, что и фронтенд, и бэкенд используют одинаковую логику анализа границ запросов.
• Отклоняйте любые запросы с неоднозначными заголовками длины или недопустимыми символами в потоке заголовков.
• Используйте проверенные библиотеки HTTP/3 вместо собственной логики пересылки UDP в TCP.

Подсказки

• Вы уже поняли, как фронт-прокси общается с бэк-прокси?
• Проверьте используемый протокол — UDP не гарантирует доставку!

Флаг

CH4KR4X2{P0D5_bl0ckch41n_br34ch}

Хостинг

Эта задача запускает Flask-сервер на порту 1337 и udp_server.py на порту 40000.

Сборка:

sudo docker build -t huup .
sudo docker network create -d bridge huup

Запуск:

sudo docker run -p 40011:40000/udp --detach --name huup --network huup huup:latest