下界传送门失步 (HUUP)

"我并非行走于既定道路，而是自由跃迁于虚空。若将我打包错误，我会将秘密送往错误的门槛。"

描述

该挑战展示了一个基于 UDP 的 HTTP/3 (QUIC) 应用层程序。由于 UDP 是无状态的，且代理不像 TCP 那样强制执行严格的 HTTP 请求边界，因此可能导致代理与后端服务器之间失步。攻击者可以在一个请求内部隐藏另一个 HTTP 请求。

注意：最大消息长度为 1024 字节，只有 GET 请求真正有效，消息在 10 秒后会被丢弃

目标: byuctf.xyz:40011

漏洞分析

• 漏洞: HTTP 请求走私（基于 UDP/QUIC）
• 根本原因: 在不可靠协议下，前端代理与后端应用程序对 HTTP 载荷边界解析不一致。

在此具体实现中，一个 Python 中间件（udp_server.py）在端口 40000 监听传入文本。该服务器一旦发现 \r\n\r\n，便将请求转发给实际的 Web 服务器。由于使用 UDP，数据包部分到达的概率很高，如果快速发送多个请求或操纵数据包边界，就会导致失步。

解答步骤

要解决此挑战，需要考虑 UDP 的不可靠性以及中间件处理请求边界的具体方式。

1. 侦察：访问根 / 端点会得到关于下界连接不稳定的提示。
2. 端点发现：导航到 /endpoints.txt 可找到 200 个可能的隐藏端点列表。
3. 暴力破解：其中某个端点包含 flag，另外三个端点会返回误报。
4. 协议精通：由于 UDP 中间件的存在，标准浏览器请求可能无法接收到完整的响应体（可能在连接关闭或超时之前只返回了头部）。
5. 自动化：编写脚本（参见 solve.py）通过 UDP 向目标发送原始 HTTP 请求。脚本需遍历所有端点并重复请求每个端点，直到收到完整响应（包含响应体）。

缓解措施

• 确保前端和后端使用完全相同的逻辑解析请求边界。
• 拒绝任何包含歧义长度头部或头部流中含有非法字符的请求。
• 使用成熟的 HTTP/3 库，而非自定义的 UDP 到 TCP 转发逻辑。

提示

• 你是否已弄清楚前端代理与后端代理如何通信？
• 检查所使用的协议——UDP 不保证交付！

Flag

CH4KR4X2{P0D5_bl0ckch41n_br34ch}

部署

该挑战在端口 1337 运行一个 Flask 服务器，并在端口 40000 运行 udp_server.py。

构建：

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