mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/http-connection-request-smuggling.md'] t
This commit is contained in:
Translator
parent
d692ac4b1f
commit
31abe92346
@ -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 <a href="#state" id="state"></a>
|
||||
## Connection-State Attacks <a href="#state" id="state"></a>
|
||||
|
||||
### 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. 공격자는 자신의 페이지에 숨겨진 `<img src="https://internal.company/…">`를 삽입합니다.
|
||||
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}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user