From 31abe92346b79ab2e765c5fb31928a2813d8ce4c Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 12 Jul 2025 22:08:14 +0000 Subject: [PATCH] Translated ['src/pentesting-web/http-connection-request-smuggling.md'] t --- .../http-connection-request-smuggling.md | 77 +++++++++++++++---- 1 file changed, 63 insertions(+), 14 deletions(-) diff --git a/src/pentesting-web/http-connection-request-smuggling.md b/src/pentesting-web/http-connection-request-smuggling.md index d481de53f..62f50190c 100644 --- a/src/pentesting-web/http-connection-request-smuggling.md +++ b/src/pentesting-web/http-connection-request-smuggling.md @@ -2,33 +2,82 @@ {{#include ../banners/hacktricks-training.md}} -**이것은 게시물의 요약입니다** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks) +**이 페이지는** [Browser-Powered Desync Attacks](https://portswigger.net/research/browser-powered-desync-attacks)에 대한 PortSwigger의 기초 연구를 요약, 확장 및 업데이트합니다. 또한 HTTP/2 연결 상태 남용에 대한 후속 작업을 다룹니다. 이 페이지는 **TCP/TLS 연결당 한 번만 원본이 결정되는** 취약점에 초점을 맞추고 있으며, 이를 통해 공격자는 채널이 설정된 후 다른 내부 호스트로 요청을 “밀어넣을” 수 있습니다. -## Connection State Attacks +## Connection-State Attacks ### First-request Validation -요청을 라우팅할 때, 리버스 프록시는 **Host header**에 의존하여 목적지 백엔드 서버를 결정할 수 있으며, 종종 접근이 허용된 호스트의 화이트리스트에 의존합니다. 그러나 일부 프록시에서는 화이트리스트가 연결의 초기 요청에만 적용되는 취약점이 존재합니다. 따라서 공격자는 먼저 허용된 호스트에 요청을 한 다음 동일한 연결을 통해 내부 사이트를 요청함으로써 이를 악용할 수 있습니다: -``` +요청을 라우팅할 때, 리버스 프록시는 **Host** (또는 HTTP/2의 **:authority**) 헤더에 의존하여 목적지 백엔드 서버를 결정할 수 있으며, 종종 접근이 허용된 호스트의 화이트리스트에 의존합니다. 그러나 여러 프록시에서 화이트리스트가 **연결의 첫 번째 요청에서만 적용되는** 취약점이 존재합니다. 결과적으로, 공격자는 허용된 요청을 먼저 전송한 후 동일한 기본 연결을 재사용하여 내부 가상 호스트에 접근할 수 있습니다: +```http GET / HTTP/1.1 -Host: [allowed-external-host] +Host: allowed-external-host.example -GET / HTTP/1.1 -Host: [internal-host] +GET /admin HTTP/1.1 +Host: internal-only.example ``` ### First-request Routing -일부 구성에서 프론트엔드 서버는 **첫 번째 요청의 Host 헤더**를 사용하여 해당 요청의 백엔드 라우팅을 결정한 다음, 동일한 클라이언트 연결의 모든 후속 요청을 동일한 백엔드 연결로 지속적으로 라우팅할 수 있습니다. 이는 다음과 같이 설명할 수 있습니다: -``` +많은 HTTP/1.1 리버스 프록시는 **전달하는 첫 번째 요청에만 기반하여** 아웃바운드 연결을 백엔드 풀에 매핑합니다. 동일한 프론트엔드 소켓을 통해 전송되는 모든 후속 요청은 Host 헤더와 관계없이 조용히 재사용됩니다. 이는 비밀번호 재설정 중독 또는 [웹 캐시 중독](https://portswigger.net/web-security/web-cache-poisoning)과 같은 고전적인 [Host 헤더 공격](https://portswigger.net/web-security/host-header)과 결합되어 다른 가상 호스트에 대한 SSRF와 유사한 접근을 얻을 수 있습니다: +```http GET / HTTP/1.1 -Host: example.com +Host: public.example POST /pwreset HTTP/1.1 -Host: psres.net +Host: private.internal ``` -이 문제는 [Host header attacks](https://portswigger.net/web-security/host-header)와 결합될 수 있으며, 예를 들어 비밀번호 재설정 중독 또는 [web cache poisoning](https://portswigger.net/web-security/web-cache-poisoning)과 같은 방식으로 다른 취약점을 악용하거나 추가 가상 호스트에 대한 무단 액세스를 얻을 수 있습니다. +> [!TIP] +> Burp Suite Professional ≥2022.10에서 **HTTP Request Smuggler → Connection-state probe**를 활성화하여 이러한 취약점을 자동으로 감지할 수 있습니다. -> [!NOTE] -> 이러한 취약점을 식별하기 위해 HTTP Request Smuggler의 'connection-state probe' 기능을 활용할 수 있습니다. +--- + +## 2023-2025의 새로운 내용 – HTTP/2/3 연결 집합 남용 + +현대 브라우저는 인증서, ALPN 프로토콜 및 IP 주소가 일치할 때 HTTP/2 및 HTTP/3 요청을 단일 TLS 연결로 **집합**합니다. 프론트엔드가 첫 번째 요청만 승인하는 경우, 이후의 모든 집합 요청은 해당 승인을 상속받습니다 – **호스트/:authority가 변경되더라도**. + +### 악용 시나리오 +1. 공격자는 `evil.com`을 제어하며, 이는 대상 `internal.company`와 동일한 CDN 엣지 노드로 해석됩니다. +2. 피해자의 브라우저는 이미 `evil.com`에 대한 열린 HTTP/2 연결을 가지고 있습니다. +3. 공격자는 자신의 페이지에 숨겨진 ``를 삽입합니다. +4. 연결 매개변수가 일치하므로 브라우저는 **기존** TLS 연결을 재사용하고 `internal.company`에 대한 요청을 다중화합니다. +5. CDN/라우터가 첫 번째 요청만 검증했다면 내부 호스트가 노출됩니다. + +Chrome/Edge/Firefox에 대한 PoC는 James Kettle의 발표 *“HTTP/2: The Sequel is Always Worse”* (Black Hat USA 2023)에서 확인할 수 있습니다. + +### 도구 +* **Burp Suite 2023.12**는 자동으로 집합 및 TE/CL 기술을 시도하는 실험적 **HTTP/2 Smuggler** 삽입 지점을 도입했습니다. +* **smuggleFuzz** (https://github.com/microsoft/smugglefuzz) – HTTP/2 및 HTTP/3에서 프론트엔드/백엔드 비동기 벡터를 무차별 대입하기 위해 2024년에 출시된 Python 프레임워크입니다. + +### 완화 조치 +* 항상 **모든 요청에서 Host/:authority를 재검증**하고, 연결 생성 시에만 검증하지 마십시오. +* CDN/로드 밸런서 계층에서 **원본 집합**을 비활성화하거나 엄격하게 범위를 지정하십시오 (예: NGINX에서 `http2_origin_cn` 끄기). +* 브라우저가 합법적으로 집합할 수 없도록 내부 및 외부 호스트 이름에 대해 별도의 인증서 또는 IP 주소를 배포하십시오. +* 가능한 경우 각 요청 후에 **connection: close** 또는 `proxy_next_upstream`을 선호하십시오. + +--- + +## 실제 사례 (2022-2025) + +| 연도 | 구성 요소 | CVE | 비고 | +|------|-----------|-----|-------| +| 2022 | AWS Application Load Balancer | – | 호스트 헤더는 첫 번째 요청에서만 검증됨; 규칙 엔진 패치로 수정됨 (SecurityLabs에 의해 공개됨). | +| 2023 | Apache Traffic Server < 9.2.2 | CVE-2023-39852 | `CONFIG proxy.config.http.parent_proxy_routing_enable`가 설정되었을 때 HTTP/2 연결 재사용을 통한 요청 스머글링 허용. | +| 2024 | Envoy Proxy < 1.29.0 | CVE-2024-2470 | 첫 번째 스트림 이후 :authority의 부적절한 검증으로 공유 메쉬에서 크로스 테넌트 요청 스머글링 가능. | + +--- + +## 탐지 요약 + +1. **동일한** TCP/TLS 연결에서 서로 다른 Host 또는 :authority 헤더로 두 개의 요청을 보냅니다. +2. 두 번째 응답이 첫 번째 호스트(안전)에서 발생하는지 아니면 두 번째 호스트(취약)에서 발생하는지 관찰합니다. +3. Burp에서: `Repeat → keep-alive → Send → Follow`. +4. HTTP/2를 테스트할 때, 무해한 호스트에 대해 **전용** 스트림(ID 1)을 열고, 내부 호스트에 대해 두 번째 스트림(ID 3)을 다중화하여 응답을 찾습니다. + +--- + +## 참고 문헌 + +* PortSwigger Research – *HTTP/2: The Sequel is Always Worse* (Black Hat USA 2023) +* Envoy Security Advisory CVE-2024-2470 – 부적절한 권한 검증 {{#include ../banners/hacktricks-training.md}}