mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-29 16:10:54 +00:00
130 lines
9.3 KiB
Markdown
130 lines
9.3 KiB
Markdown
# HTTP 응답 스머글링 / 디싱크
|
|
|
|
<details>
|
|
|
|
<summary><strong>htARTE (HackTricks AWS Red Team Expert)</strong>를 통해 AWS 해킹을 처음부터 전문가까지 배워보세요<strong>!</strong></summary>
|
|
|
|
HackTricks를 지원하는 다른 방법:
|
|
|
|
* **회사를 HackTricks에서 광고하거나 HackTricks를 PDF로 다운로드**하려면 [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)를 확인하세요!
|
|
* [**공식 PEASS & HackTricks 스웨그**](https://peass.creator-spring.com)를 얻으세요.
|
|
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)를 발견하세요. 독점적인 [**NFT**](https://opensea.io/collection/the-peass-family) 컬렉션입니다.
|
|
* 💬 [**Discord 그룹**](https://discord.gg/hRep4RUj7f) 또는 [**텔레그램 그룹**](https://t.me/peass)에 **참여**하거나 **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**를** **팔로우**하세요.
|
|
* **Hacking 트릭을 공유하려면** [**HackTricks**](https://github.com/carlospolop/hacktricks) 및 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github 저장소에 PR을 제출하세요.
|
|
|
|
</details>
|
|
|
|
**이 게시물의 기술은 다음 비디오에서 가져왔습니다: [https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)**
|
|
|
|
|
|
## HTTP 요청 큐 디싱크
|
|
|
|
먼저, 이 기술은 **HTTP 요청 스머글링 취약점**을 악용하므로 이를 알아야 합니다:
|
|
|
|
이 기술과 일반적인 HTTP 요청 스머글링의 **주요 차이점**은 **피해자의 요청에 접두사를 추가하여 공격하는 대신, 피해자가 받는 응답을 유출하거나 수정**한다는 것입니다. 이를 위해 HTTP 요청 스머글링을 악용하기 위해 1개의 요청과 반 개를 보내는 대신, **2개의 완전한 요청을 보내어 프록시 응답 큐를 디싱크시킵니다**.
|
|
|
|
이는 응답 큐를 **디싱크시킬 수 있기 때문에 피해자의 정당한 요청의 응답이 공격자에게 전송**되거나, 응답에 공격자가 제어하는 내용을 피해자에게 **주입**할 수 있게 됩니다.
|
|
|
|
### HTTP 파이프라인 디싱크
|
|
|
|
HTTP/1.1은 **이전 요청을 기다리지 않고도 다른 리소스를 요청**할 수 있도록 합니다. 따라서, **프록시**가 **중간에 있는 경우**, 백엔드로 보내는 요청과 그에 대한 응답을 **동기화된 매치로 유지**하는 것이 프록시의 역할입니다.
|
|
|
|
그러나 응답 큐를 디싱크시키는 문제가 있습니다. 공격자가 HTTP 응답 스머글링 공격을 보내고 **초기 요청과 스머글링된 요청의 응답이 즉시 도착하는 경우**, 스머글링된 응답은 피해자 응답 큐에 **삽입되지 않고 오류로 처리**됩니다.
|
|
|
|
![](<../.gitbook/assets/image (635) (1) (1) (1).png>)
|
|
|
|
따라서, 스머글링된 요청이 처리되는 데 **더 많은 시간이 필요**합니다. 따라서, 스머글링된 요청이 처리될 때까지 공격자와의 통신은 끝나게 됩니다.
|
|
|
|
이 특정 상황에서 **피해자가 요청을 보낸 경우**와 **스머글링된 요청이 먼저 응답된 경우**, **스머글링된 응답이 피해자에게 전송**됩니다. 따라서, 공격자는 피해자가 "수행한" 요청을 **제어**하게 됩니다.
|
|
|
|
또한, **공격자가 요청을 수행**하고 **피해자** 요청에 대한 **정당한 응답**이 **공격자의 요청보다 먼저 응답**되는 경우, **피해자에 대한 응답이 공격자에게 전송**되어 피해자의 응답(예: **Set-Cookie** 헤더)을 **훔칠 수 있습니다**.
|
|
|
|
![](<../.gitbook/assets/image (658) (1).png>)
|
|
|
|
![](<../.gitbook/assets/image (655) (1) (1) (1).png>)
|
|
|
|
### 다중 중첩 주입
|
|
|
|
일반적인 HTTP 요청 스머글링과의 **흥미로운 차이점**은, 일반적인 스머글링 공격에서는 **피해자의 요청의 시작 부분을 수정**하여 예상치 못한 동작을 수행하도록 하는 것입니다. **HTTP 응답 스머글링 공격**에서는 **전체 요청을 보내므로 여러 응답을 한 번에 주입**할 수 있으며, 이는 **여러 사용자를 디싱크시키는 데 사용**될 수 있습니다.
|
|
|
|
합법적인 사용자들에게 **여러 개의 악용을 쉽게 분배**할 수 있을 뿐만 아니라 서버에서 **DoS**를 일으킬 수도 있습니다.
|
|
|
|
### 공격 구성
|
|
|
|
이전에 설명한 대로, 이 기술을 악용하기 위해서는 **첫 번째 스머글링된 메시지**가 서버에서 **처리되는 데 많은 시간이 필요**합니다.
|
|
|
|
이 **시간 소모적인 요청은 피해자의 응답을 훔치려는 경우에는 충분**합니다. 그러나 더 복잡한 악용을 수행하려는 경우에는 이것이 악용의 일반적인 구조가 될 것입니다.
|
|
|
|
먼저 **HTTP 요청 스머글링을 악용한 초기 요청**, 그 다음 **시간 소모적인 요청**, 그리고 **1개 이상의 페이로드 요청**이 피해자에게 전송될 응답입니다.
|
|
|
|
## HTTP 응답 큐 디싱크 악용
|
|
|
|
### 다른 사용자의 요청 캡처 <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
|
|
|
HTTP 요청 스머글링 알려진 페이로드와 마찬가지로, **피해자의 요청을 훔칠 수** 있지만 한 가지 중요한 차이점이 있습니다: 이 경우 **응답에 반영될 내용을 보내기만 하면 되며, 영구적인 저장소는 필요하지 않습니다**.
|
|
|
|
먼저, 공격자는 **마지막 POST 요청에 반영된 매개변수**와 큰 Content-Length를 포함하는 페이로드를 보
|
|
### 내용 혼동
|
|
|
|
이전 예제를 따라가면, 희생자가 받을 응답의 **본문을 제어**할 수 있고, **HEAD** 응답은 일반적으로 헤더에 **Content-Type과 Content-Length**를 포함하고 있다는 것을 알고 있다면, 다음과 같은 요청을 보내서 페이지가 XSS에 취약하지 않은 상태에서도 희생자에게 XSS를 유발시킬 수 있습니다:
|
|
|
|
![](<../.gitbook/assets/image (654) (1) (1) (1) (1).png>)
|
|
|
|
### 캐시 독점
|
|
|
|
이전에 언급한 응답 비동기화 콘텐츠 혼동 공격을 악용하여, **캐시가 희생자가 수행한 요청에 대한 응답을 저장하고 이 응답이 XSS를 유발하는 주입된 응답인 경우, 캐시가 독점당한다**.
|
|
|
|
XSS 페이로드를 포함한 악성 요청:
|
|
|
|
![](<../.gitbook/assets/image (644) (1).png>)
|
|
|
|
캐시에 응답을 저장하도록 캐시에 알려주는 헤더를 포함한 희생자에게 보내는 악성 응답:
|
|
|
|
![](<../.gitbook/assets/image (629) (1).png>)
|
|
|
|
{% hint style="warning" %}
|
|
이 경우에는 **"희생자"가 공격자**인 경우에만 주목하세요. 이제 그는 악성 응답으로 캐시될 URL을 **제어**할 수 있으므로 **임의의 URL에 대해 캐시 독점**을 수행할 수 있습니다.
|
|
{% endhint %}
|
|
|
|
### 웹 캐시 속임수
|
|
|
|
이 공격은 이전 공격과 유사하지만, **캐시 내에 희생자 정보를 캐싱하는 대신 공격자가 희생자 정보를 캐시에 저장**합니다:
|
|
|
|
![](<../.gitbook/assets/image (643) (1) (1).png>)
|
|
|
|
### 응답 분리
|
|
|
|
이 공격의 **목표**는 다시 한 번 **응답 비동기화**를 악용하여 **프록시가 100% 공격자 생성 응답을 보내도록 하는 것**입니다.
|
|
|
|
이를 달성하기 위해 공격자는 응답 내에서 **일부 값을 반영하는 웹 애플리케이션의 엔드포인트를 찾고 HEAD 응답의 콘텐츠 길이를 알아야 합니다**.
|
|
|
|
그는 다음과 같은 **exploit**을 보냅니다:
|
|
|
|
![](<../.gitbook/assets/image (649) (1) (1) (1).png>)
|
|
|
|
첫 번째 요청이 해결되고 공격자에게 다시 전송된 후, 희생자의 요청이 대기열에 추가됩니다:
|
|
|
|
![](<../.gitbook/assets/image (661) (1) (1) (1).png>)
|
|
|
|
희생자는 응답으로 **HEAD 응답 + 두 번째 요청 응답의 내용(반영된 데이터의 일부를 포함)**을 받게 됩니다:
|
|
|
|
![](<../.gitbook/assets/image (633) (1).png>)
|
|
|
|
그러나 **반영된 데이터는 HEAD 응답의 Content-Length에 따라 크기가 있었으며, 응답 대기열에서 유효한 HTTP 응답을 생성**했습니다.
|
|
|
|
따라서 **두 번째 희생자의 다음 요청**은 **공격자에 의해 완전히 조작된 응답**을 **수신**하게 됩니다. 응답이 공격자에 의해 완전히 조작되었으므로 공격자는 또한 **프록시가 응답을 캐시**하도록 할 수 있습니다.
|
|
|
|
|
|
<details>
|
|
|
|
<summary><strong>htARTE (HackTricks AWS Red Team Expert)</strong>를 통해 AWS 해킹을 처음부터 전문가까지 배워보세요<strong>!</strong></summary>
|
|
|
|
HackTricks를 지원하는 다른 방법:
|
|
|
|
* **회사를 HackTricks에서 광고**하거나 **PDF로 HackTricks를 다운로드**하려면 [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)를 확인하세요!
|
|
* [**공식 PEASS & HackTricks 스웨그**](https://peass.creator-spring.com)를 얻으세요.
|
|
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)를 발견하세요. 독점적인 [**NFTs**](https://opensea.io/collection/the-peass-family) 컬렉션입니다.
|
|
* 💬 [**Discord 그룹**](https://discord.gg/hRep4RUj7f) 또는 [**텔레그램 그룹**](https://t.me/peass)에 **참여**하거나 **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**를** 팔로우하세요.
|
|
* **HackTricks**와 **HackTricks Cloud** github 저장소에 PR을 제출하여 **당신의 해킹 기교를 공유**하세요.
|
|
|
|
</details>
|