HTTP Response Smuggling / Desync
이 게시물의 기술은 다음 비디오에서 가져왔습니다: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
HTTP 요청 큐 비동기화
우선, 이 기술은 HTTP 요청 스머글링 취약점을 악용하므로, 그것이 무엇인지 알아야 합니다:
이 기술과 일반 HTTP 요청 스머글링의 주요 차이점은 희생자의 요청에 접두사를 추가하여 공격하는 대신, 우리는 희생자가 받는 응답을 유출하거나 수정할 것입니다. 이는 HTTP 요청 스머글링을 악용하기 위해 1.5개의 요청을 보내는 대신, 프록시 응답 큐를 비동기화하기 위해 2개의 완전한 요청을 보냅니다.
이는 우리가 응답 큐를 비동기화할 수 있기 때문에 희생자의 정당한 요청의 응답이 공격자에게 전송되거나, 희생자에게 응답하는 내용에 공격자가 제어하는 콘텐츠를 주입할 수 있기 때문입니다.
HTTP 파이프라인 비동기화
HTTP/1.1은 이전 요청을 기다릴 필요 없이 다양한 리소스를 요청할 수 있습니다. 따라서, 중간에 프록시가 있다면, 프록시의 작업은 백엔드에 전송된 요청과 그로부터 오는 응답을 동기화된 상태로 유지하는 것입니다.
그러나 응답 큐를 비동기화하는 데 문제가 있습니다. 공격자가 HTTP 응답 스머글링 공격을 보내고 초기 요청과 스머글된 요청에 대한 응답이 즉시 응답되면, 스머글된 응답은 희생자 응답의 큐에 삽입되지 않고 단순히 오류로 폐기됩니다.
따라서, 스머글된 요청이 백엔드 서버에서 처리되는 데 더 많은 시간이 걸리도록 해야 합니다. 따라서 스머글된 요청이 처리될 때, 공격자와의 통신은 종료될 것입니다.
특정 상황에서 희생자가 요청을 보냈고 스머글된 요청이 정당한 요청보다 먼저 응답되면, 스머글된 응답이 희생자에게 전송됩니다. 따라서 공격자는 희생자가 "수행한" 요청을 제어하게 됩니다.
게다가, 공격자가 요청을 수행하고 희생자 요청에 대한 정당한 응답이 공격자의 요청보다 먼저 응답되면, 희생자에 대한 응답이 공격자에게 전송되어, 희생자에 대한 응답을 훔치게 됩니다 (예를 들어, Set-Cookie 헤더를 포함할 수 있습니다).
다중 중첩 주입
일반 HTTP 요청 스머글링과의 또 다른 흥미로운 차이점은, 일반 스머글링 공격에서는 목표가 희생자의 요청 시작 부분을 수정하여 예기치 않은 작업을 수행하게 하는 것입니다. HTTP 응답 스머글링 공격에서는 전체 요청을 보내기 때문에, 하나의 페이로드에 수십 개의 응답을 주입할 수 있습니다. 이는 수십 명의 사용자가 주입된 응답을 받게 되는 비동기화를 초래합니다.
정당한 사용자에게 수십 개의 익스플로잇을 더 쉽게 배포할 수 있을 뿐만 아니라, 이는 서버에 DoS를 유발하는 데도 사용될 수 있습니다.
익스플로잇 조직
앞서 설명한 바와 같이, 이 기술을 악용하기 위해서는 서버에 스머글된 첫 번째 메시지가 처리되는 데 많은 시간이 걸리도록 해야 합니다.
이 시간 소모 요청은 우리가 희생자의 응답을 훔치려는 경우에 충분합니다. 그러나 더 복잡한 익스플로잇을 수행하려면, 이는 익스플로잇의 일반적인 구조가 될 것입니다.
우선 HTTP 요청 스머글링을 악용하는 초기 요청, 그 다음 시간 소모 요청, 그리고 희생자에게 전송될 응답을 포함하는 1개 이상의 페이로드 요청입니다.
HTTP 응답 큐 비동기화 악용
다른 사용자의 요청 캡처
HTTP 요청 스머글링으로 알려진 페이로드를 사용하여, 희생자의 요청을 훔칠 수 있습니다. 단, 이 경우 응답에 반영된 콘텐츠를 보내기만 하면 되며, 지속적인 저장소는 필요하지 않습니다.
우선, 공격자는 반영된 매개변수를 포함한 최종 POST 요청을 포함하는 페이로드를 보내고, 큰 Content-Length를 설정합니다.
그런 다음, 초기 요청(파란색)이 처리되고 수면 중인 요청이 처리되는 동안(노란색), 희생자로부터 도착하는 다음 요청이 반영된 매개변수 바로 뒤에 큐에 추가됩니다:
그 후, 희생자는 수면 중인 요청에 대한 응답을 받게 되고, 그 사이에 공격자가 또 다른 요청을 보냈다면, 반영된 콘텐츠 요청의 응답이 그에게 전송됩니다.
응답 비동기화
지금까지 우리는 HTTP 요청 스머글링 공격을 악용하여 클라이언트가 받을 응답을 제어하는 방법과, 그 후 희생자를 위한 응답을 훔치는 방법을 배웠습니다.
하지만 여전히 응답을 더 비동기화할 수 있습니다.
HEAD 요청과 같은 흥미로운 요청이 있으며, 이는 응답 본문에 아무 콘텐츠도 포함하지 않아야 하며, GET 요청인 것처럼 요청의 Content-Length를 포함해야 합니다.
따라서 공격자가 HEAD 요청을 주입하면, 다음과 같은 이미지와 같이:
그런 다음, 파란색 요청이 공격자에게 응답되면, 다음 희생자의 요청이 큐에 추가됩니다:
그 후, 희생자는 HEAD 요청의 응답을 받게 되며, 이는 Content-Length를 포함하지만 콘텐츠는 전혀 포함하지 않습니다. 따라서 프록시는 이 응답을 희생자에게 전송하지 않고, 어떤 콘텐츠를 기다리게 되며, 이는 실제로 노란색 요청에 대한 응답(공격자가 주입한 것)입니다:
콘텐츠 혼란
이전 예제를 따라, 희생자가 받을 응답의 본문을 제어할 수 있고, HEAD 응답이 일반적으로 Content-Type과 Content-Length를 헤더에 포함한다는 것을 알고 있다면, 다음과 같은 요청을 보내 희생자에게 XSS를 유발할 수 있습니다. 페이지가 XSS에 취약하지 않더라도:
캐시 오염
이전에 언급한 응답 비동기화 콘텐츠 혼란 공격을 악용하면, 캐시가 희생자가 수행한 요청에 대한 응답을 저장하고 이 응답이 XSS를 유발하는 주입된 것이라면, 캐시는 오염됩니다.
XSS 페이로드를 포함한 악의적인 요청:
희생자에게 응답하는 악의적인 응답은 캐시에게 응답을 저장하라고 지시하는 헤더를 포함합니다:
이 경우 "희생자"가 공격자라면, 그는 이제 임의의 URL에서 캐시 오염을 수행할 수 있습니다. 왜냐하면 그는 악의적인 응답으로 캐시될 URL을 제어할 수 있기 때문입니다.
웹 캐시 기만
이 공격은 이전 공격과 유사하지만, 공격자가 캐시 내부에 페이로드를 주입하는 대신, 희생자 정보를 캐시에 저장합니다:
응답 분할
이 공격의 목표는 다시 응답 비동기화를 악용하여 프록시가 100% 공격자가 생성한 응답을 전송하게 만드는 것입니다.
이를 달성하기 위해 공격자는 응답 내에서 일부 값을 반영하는 웹 애플리케이션의 엔드포인트를 찾아야 하며, HEAD 응답의 콘텐츠 길이를 알아야 합니다.
그는 다음과 같은 익스플로잇을 보낼 것입니다:
첫 번째 요청이 해결되고 공격자에게 전송된 후, 희생자의 요청이 큐에 추가됩니다:
희생자는 **HEAD 응답 + 두 번째 요청 응답의 콘텐츠(반영된 데이터의 일부 포함)**를 응답으로 받게 됩니다:
그러나 반영된 데이터가 HEAD 응답의 Content-Length에 따라 크기가 조정되어 응답 큐에서 유효한 HTTP 응답을 생성했다는 점에 유의하십시오.
따라서 두 번째 희생자의 다음 요청은 공격자가 완전히 제작한 응답을 받게 됩니다. 응답이 공격자에 의해 완전히 제작되었기 때문에, 그는 또한 프록시가 응답을 캐시하도록 만들 수 있습니다.
Last updated
