Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 06:30:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-response-smuggling-desync.md
Translator workflow 1d9d380da0 Translated to Korean
2024-02-10 21:30:13 +00:00

9.3 KiB
Raw Blame History

HTTP 응답 스머글링 / 디싱크

htARTE (HackTricks AWS Red Team Expert)를 통해 AWS 해킹을 처음부터 전문가까지 배워보세요!

HackTricks를 지원하는 다른 방법:

이 게시물의 기술은 다음 비디오에서 가져왔습니다: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s

HTTP 요청 큐 디싱크

먼저, 이 기술은 HTTP 요청 스머글링 취약점을 악용하므로 이를 알아야 합니다:

이 기술과 일반적인 HTTP 요청 스머글링의 주요 차이점은 피해자의 요청에 접두사를 추가하여 공격하는 대신, 피해자가 받는 응답을 유출하거나 수정한다는 것입니다. 이를 위해 HTTP 요청 스머글링을 악용하기 위해 1개의 요청과 반 개를 보내는 대신, 2개의 완전한 요청을 보내어 프록시 응답 큐를 디싱크시킵니다.

이는 응답 큐를 디싱크시킬 수 있기 때문에 피해자의 정당한 요청의 응답이 공격자에게 전송되거나, 응답에 공격자가 제어하는 내용을 피해자에게 주입할 수 있게 됩니다.

HTTP 파이프라인 디싱크

HTTP/1.1은 이전 요청을 기다리지 않고도 다른 리소스를 요청할 수 있도록 합니다. 따라서, 프록시가 중간에 있는 경우, 백엔드로 보내는 요청과 그에 대한 응답을 동기화된 매치로 유지하는 것이 프록시의 역할입니다.

그러나 응답 큐를 디싱크시키는 문제가 있습니다. 공격자가 HTTP 응답 스머글링 공격을 보내고 초기 요청과 스머글링된 요청의 응답이 즉시 도착하는 경우, 스머글링된 응답은 피해자 응답 큐에 삽입되지 않고 오류로 처리됩니다.

따라서, 스머글링된 요청이 처리되는 데 더 많은 시간이 필요합니다. 따라서, 스머글링된 요청이 처리될 때까지 공격자와의 통신은 끝나게 됩니다.

이 특정 상황에서 피해자가 요청을 보낸 경우와 스머글링된 요청이 먼저 응답된 경우, 스머글링된 응답이 피해자에게 전송됩니다. 따라서, 공격자는 피해자가 "수행한" 요청을 제어하게 됩니다.

또한, 공격자가 요청을 수행하고 피해자 요청에 대한 정당한 응답이 공격자의 요청보다 먼저 응답되는 경우, 피해자에 대한 응답이 공격자에게 전송되어 피해자의 응답(예: Set-Cookie 헤더)을 훔칠 수 있습니다.

다중 중첩 주입

일반적인 HTTP 요청 스머글링과의 흥미로운 차이점은, 일반적인 스머글링 공격에서는 피해자의 요청의 시작 부분을 수정하여 예상치 못한 동작을 수행하도록 하는 것입니다. HTTP 응답 스머글링 공격에서는 전체 요청을 보내므로 여러 응답을 한 번에 주입할 수 있으며, 이는 여러 사용자를 디싱크시키는 데 사용될 수 있습니다.

합법적인 사용자들에게 여러 개의 악용을 쉽게 분배할 수 있을 뿐만 아니라 서버에서 DoS를 일으킬 수도 있습니다.

공격 구성

이전에 설명한 대로, 이 기술을 악용하기 위해서는 첫 번째 스머글링된 메시지가 서버에서 처리되는 데 많은 시간이 필요합니다.

이 시간 소모적인 요청은 피해자의 응답을 훔치려는 경우에는 충분합니다. 그러나 더 복잡한 악용을 수행하려는 경우에는 이것이 악용의 일반적인 구조가 될 것입니다.

먼저 HTTP 요청 스머글링을 악용한 초기 요청, 그 다음 시간 소모적인 요청, 그리고 1개 이상의 페이로드 요청이 피해자에게 전송될 응답입니다.

HTTP 응답 큐 디싱크 악용

다른 사용자의 요청 캡처

HTTP 요청 스머글링 알려진 페이로드와 마찬가지로, 피해자의 요청을 훔칠 수 있지만 한 가지 중요한 차이점이 있습니다: 이 경우 응답에 반영될 내용을 보내기만 하면 되며, 영구적인 저장소는 필요하지 않습니다.

먼저, 공격자는 마지막 POST 요청에 반영된 매개변수와 큰 Content-Length를 포함하는 페이로드를 보

내용 혼동

이전 예제를 따라가면, 희생자가 받을 응답의 본문을 제어할 수 있고, HEAD 응답은 일반적으로 헤더에 Content-Type과 Content-Length를 포함하고 있다는 것을 알고 있다면, 다음과 같은 요청을 보내서 페이지가 XSS에 취약하지 않은 상태에서도 희생자에게 XSS를 유발시킬 수 있습니다:

캐시 독점

이전에 언급한 응답 비동기화 콘텐츠 혼동 공격을 악용하여, 캐시가 희생자가 수행한 요청에 대한 응답을 저장하고 이 응답이 XSS를 유발하는 주입된 응답인 경우, 캐시가 독점당한다.

XSS 페이로드를 포함한 악성 요청:

캐시에 응답을 저장하도록 캐시에 알려주는 헤더를 포함한 희생자에게 보내는 악성 응답:

{% hint style="warning" %} 이 경우에는 "희생자"가 공격자인 경우에만 주목하세요. 이제 그는 악성 응답으로 캐시될 URL을 제어할 수 있으므로 임의의 URL에 대해 캐시 독점을 수행할 수 있습니다. {% endhint %}

웹 캐시 속임수

이 공격은 이전 공격과 유사하지만, 캐시 내에 희생자 정보를 캐싱하는 대신 공격자가 희생자 정보를 캐시에 저장합니다:

응답 분리

이 공격의 목표는 다시 한 번 응답 비동기화를 악용하여 프록시가 100% 공격자 생성 응답을 보내도록 하는 것입니다.

이를 달성하기 위해 공격자는 응답 내에서 일부 값을 반영하는 웹 애플리케이션의 엔드포인트를 찾고 HEAD 응답의 콘텐츠 길이를 알아야 합니다.

그는 다음과 같은 exploit을 보냅니다:

첫 번째 요청이 해결되고 공격자에게 다시 전송된 후, 희생자의 요청이 대기열에 추가됩니다:

희생자는 응답으로 **HEAD 응답 + 두 번째 요청 응답의 내용(반영된 데이터의 일부를 포함)**을 받게 됩니다:

그러나 반영된 데이터는 HEAD 응답의 Content-Length에 따라 크기가 있었으며, 응답 대기열에서 유효한 HTTP 응답을 생성했습니다.

따라서 두 번째 희생자의 다음 요청은 공격자에 의해 완전히 조작된 응답을 수신하게 됩니다. 응답이 공격자에 의해 완전히 조작되었으므로 공격자는 또한 프록시가 응답을 캐시하도록 할 수 있습니다.

htARTE (HackTricks AWS Red Team Expert)를 통해 AWS 해킹을 처음부터 전문가까지 배워보세요!

HackTricks를 지원하는 다른 방법: