HTTP Response Smuggling / Desync
이 게시물의 기술은 다음 비디오에서 가져왔습니다: 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를 포함합니다.
그런 다음, 초기 요청(파란색)이 처리되고 sleepy 요청(노란색)이 처리되는 동안 피해자로부터 도착한 다음 요청이 반영된 매개변수 바로 뒤에 큐에 추가됩니다:
그런 다음 피해자는 sleepy 요청에 대한 응답을 받게 되며, 그 사이에 공격자가 다른 요청을 보냈다면, 반영된 내용 요청에 대한 응답이 그에게 전송됩니다.
응답 디싱크로나이제이션
지금까지 HTTP 요청 스머글링 공격을 악용하여 클라이언트가 받을 요청을 제어하고, 그 후 피해자를 위해 응답을 탈취하는 방법을 배웠습니다.
그러나 응답을 더욱 더 디싱크로나이즈할 수 있습니다.
HEAD 요청과 같이 응답 본문에 어떤 내용도 포함되어서는 안 되는 흥미로운 요청이 있습니다. 이 요청은 GET 요청인 것처럼 Content-Length을 포함해야 합니다.
따라서 공격자가 이러한 이미지와 같이 HEAD 요청을 주입하면:
그런 다음 파란색 요청이 공격자에게 응답된 후, 다음 피해자 요청이 큐에 추가됩니다:
그런 다음 피해자는 HEAD 요청에 대한 응답을 받게 되며, 이 응답은 Content-Length는 포함하지만 내용이 전혀 없을 것입니다. 따라서 프록시는 이 응답을 피해자에게 보내지 않고 일부 내용을 기다리게 되며, 실제로는 공격자가 주입한 노란색 요청에 대한 응답이 될 것입니다:
내용 혼란
이전 예제를 따라서, 희생자가 받게 될 응답의 본문을 제어할 수 있다는 것과 HEAD 응답이 일반적으로 헤더에 Content-Type과 Content-Length을 포함한다는 것을 알고 있다면, 다음과 같은 요청을 보내 페이지가 XSS에 취약하지 않아도 희생자에게 XSS를 유발시킬 수 있습니다:
캐시 독려
이전에 설명한 응답 비동기화 내용 혼란 공격을 악용하면 캐시가 희생자가 수행한 요청에 대한 응답을 저장하고 이 응답이 XSS를 유발하는 주입된 응답인 경우, 그러면 캐시가 독려된다.
XSS 페이로드를 포함한 악의적인 요청:
캐시에 응답을 저장하도록 지시하는 헤더를 포함하는 희생자에 대한 악의적인 응답:
이 경우 "희생자"가 공격자인 경우 이제 악의적인 응답으로 캐시될 URL을 제어할 수 있기 때문에 임의의 URL에 대해 캐시 독려를 수행할 수 있습니다.
웹 캐시 속임수
이 공격은 이전 공격과 유사하지만 캐시 내에 피해자 정보를 캐싱하는 대신 공격자가 피해자 정보를 캐싱합니다:
응답 분할
이 공격의 목표는 다시 한 번 응답 비동기화를 악용하여 프록시가 100% 공격자가 생성한 응답을 보내도록 하는 것입니다.
이를 달성하기 위해 공격자는 응답 내에서 일부 값을 반영하는 웹 애플리케이션의 엔드포인트를 찾아야 하며 HEAD 응답의 내용 길이를 알아야 합니다.
그는 다음과 같은 exploit을 보낼 것입니다:
첫 번째 요청이 해결되고 공격자에게 다시 보내지면 희생자의 요청이 대기열에 추가됩니다:
희생자는 **HEAD 응답 + 두 번째 요청 응답의 내용(반영된 데이터 일부를 포함)**을 응답으로 받게 될 것입니다:
그러나 반영된 데이터가 HEAD 응답의 Content-Length에 따라 크기가 있었음을 주목하십시오. 이는 응답 대기열에서 유효한 HTTP 응답을 생성했습니다.
따라서 두 번째 희생자의 다음 요청은 공격자가 완전히 조작한 응답을 받게 될 것입니다. 응답이 공격자에 의해 완전히 조작되었기 때문에 프록시가 응답을 캐시할 수도 있습니다.
Last updated
