Advanced Request Smuggling

더 높은 수준의 HTTP request smuggling 기술은 물론 존재한다. HTTP/2는 request smuggling의 새로운 영역을 전개하며 기존의 안전한 환경을 위협하고있다.

01. HTTP/2 requeste smuggling

Request smuggling은 근본적으로 서버들의 요청 길이 판단의 불일치로 일어난다. 그리고 HTTP/2는 오랜기간 강력한 메커니즘을 바탕으로 이에 끄떡없다고 여겨졌다. HTTP/2는 요청을 프레임 단위로 나누어 전달하고 이 프레임 길이의 총합이 요청의 길이가 된다. 이론상 이러한 메커니즘은 공격자로 하여금 애매모호한 요청 길이를 보내는 시도조차 하지 못하게 한다. 하지만 현실은 흔하지는 않지만 HTTP/2 downgrading 이라는 위험이 기다리고 있다는 것이다.

1) HTTP/2 downgrading

HTTP/2 downgrading은 HTTP/2 요청을 동등한 내용의 HTTP/1 요청으로 rewriting하는 과정이다. 이는 오직 HTTP/1 형태를 사용하는 back-end 서버와 상호작용하기 위해 웹서버나 리버스 프록시가 주로 사용한다. 물론 back-end에서 발생한 응답에 대해서 front-end는 HTTP/2 형식으로 되돌려 사용자에게 보낸다.

이는 HTTP/1 과 HTTP/2 는 같은 정보에 대해 표현하는 방법만 다를 뿐 거의 동일한 메세지를 담고 있기에 가능하다.

[IMG1] HTTP/1 과 HTTP/2 의 구조

결과적으로 이 덕분에 두 프로토콜간 변환이 자연스러워지는 것이다. 상당수의 리버스 프록시는 HTTP/2 downgrading을 지원하고 있고, 심지어 비활성화 하지 못하는 경우도 있다.

2) H2.CL 취약점

HTTP/2 요청은 특별히 그 길이를 헤더에 명시할 필요가 없다. 이말은 downgrading 과정에서 front-end 서버는 HTTP/1 Content-Length 헤더를 추가한다는 소리다. 또한 HTTP/2는 Content-Length 헤더를 가질 수 있는데 이떄 front-end는 이를 재사용하여 HTTP/1 요청을 만든다.

여기서 문제가 발생한다. Downgrading 과정에서 HTTP/2 가 올바른 길이의 Content-Length 헤더를 가지고 있지 않다면 HTTP/1은 이러한 잘못된 헤더를 그대로 사용하게 된다. 물론 front-end 서버 상에서는 정확한 HTTP/2 길이를 참고하여 요청을 끝내지만, HTTP/1 back-end 서버는 잘못된 헤더를 받게 되는 것이다. 결과적으로 “Desync”가 발생한다.

[IMG2] Front-end (HTTP/2)

[IMG3] Back-end (HTTP/1)

3) H2.TE 취약점

Transfer Encoding 헤더는 front-end 서버 차원에서 전적으로 통하지 않는다. 하지만 downgrading을 통해 Transfer Encoding을 지원하는 HTTP/1 back-end 서버로 간다면 HRS 공격이 가능하다.

[IMG4] Front-end (HTTP/2)

[IMG5] Back-end (HTTP/1)

4) 숨겨진 HTTP/2 지원 환경

브라우저와 기타 클라이언트는 일반적으로 TLS handshake 과정에서 ALPN(Application-Layer Protocol Negotiation)을 통해 서버가 HTTP/2를 지원한다고 명시하는 경우에만 HTTP/2를 사용하여 서버와 통신한다. 하지만 몇몇 서버들은 HTTP/2를 지원 함에도 이를 적절히 표현하지 않는다. 이런 경우, 클라이언트는 기본 옵션에 따라 서버가 HTTP/1.1만을 지원한다고 오해하고, 결과적으로 위에서 살펴본 HTTP/2 공격 가능성을 간과할 수 있다.

02. Response Queue Poisoning

Response queue poisoning은 back-end 서버에서 온 응답을 front-end가 잘못된 요청과 연결짓게 만드는 강력한 HRS 공격이다. 위 환경에서의 모든 사용자들은 지속적으로 누군가가 의도한 응답을 전해받게 되는것이다.

큐가 한번 장악되면, 공격자는 간단히 후속 요청 하나로 다른 사용자의 응답을 가로챌 수 있다. 그 응답속에는 세션 토큰과 같은 민감한 정보가 들어있을수 있다. 부수적인 피해로 같은 TCP 연결을 사용하는 다른 사용자들에게 랜덤과 같은 응답을 보내, 정상적인 일처리를 하지 못하게 할 수 있다.

기존 HRS 공격을 보면, 다른 사용자로 부터 온 다른 요청들은 정상적인 구조를 이루지 못하여 연결이 끊어진다.

[IMG6] Normal HRS attack

서버와의 연결을 유지하며 queue poisoning 공격을 수행하려면 정확히 두 개의 완전한 요청을 하나로 묶어 보내야 한다. 그렇다면 back-end 서버는 모두가 유효한 요청이기에 연결을 끊지않는다.

[IMG7] Response queue poisoning attack

[IMG8] RQP 이해를 위한 그림

이 공격은 HTTP/1과 HTTP/2 downgrading 환경 모두 공격 가능하다. Body 에서의 분할이 아닌, 헤더에서도 가능한데 아래 HTTP/2 Request Splitting에서 다룰 것이다.

03. CRLF 삽입공격을 통한 HRS

많은 웹사이트들이 H2.CL이나 H2.TE 공격을 방어하기 위해 Content-Length 값을 검증하고 Transfer-Encoding 헤더를 제거하는 과정을 거친다. 그럼에도 HTTP/2 환경 속 binary 형식은 신박한 방법으로 front-end의 노력을 무산시킨다.

HTTP/1에서는 가끔 개행문자 “\n”을 이용하여 exploit을 진행할 수 있다. back-end는 이를 기준으로 삼지만, front-end는 그렇지 않을 때 front-end는 그 다음 헤더를 발견하는 것조차 실패할 것이다. CRLF(”\r\n”)는 모든 HTTP/1 서버에서 헤더 종결의 의미를 가지기에 해당되지 않는다.

X: X\\nTransfer-Encoding: chunked

이와 반대로 HTTP/2 메시지들은 text 형식이 아닌, binary 형식이기에 각 헤더의 경계가 명확하다. CRLF와 같은 경계 기호보다 이미 정해진 offset들을 따르기에 CRLF는 더이상 큰 의미를 갖지 않는다. 이는 헤더 값에 포함되어있더라도 front-end는 게의치 않는다는 것을 뜻한다.

X: X\\r\\nTransfer-Encoding: chunked

front-end 서버에서는 별 문제가 되지 않는것처럼 보여도 HTTP/1 back-end 서버는 이를 두 개의 헤더로 인식한다.

X: X
Transfer-Encoding: chunked

04. HTTP/2 Request Splitting

앞서 response queue poisoning에서 하나의 HTTP 요청에서 두 완전한 요청을 back-end로 보내는 과정을 보았다. HTTP/2 downgrading 환경에서 CRLF 삽입공격과 이를 접목하여 헤더 안에서도 두 완전한 요청을 보낼 수 있다.

HTTP/2 request splitting 공격은 GET method를 사용할 때, content-length는 유효하지만, back-end서버는 chunked encoding을 지원하지 않을 때에도 이용할 수 있어 굉장히 유용하다.

[IMG9] HTTP/2 request splitting 예시 헤더

여기서 특별한 조건이 발생할 수도 있다. Front-end 서버에서 downgrading 하는 과정에서 header의 변화를 알아야 한다. 예를들어 Front-end 서버는 주로 “:authority”라는 임시 헤더를 Host로 변환 후 back-end 서버로 보낸다.

[IMG9]를 보면, X 헤더 속 Host 가 끝에 위치하고있다. Front-end 서버는 downgrading을 진행하며 X 헤더 다음에 Host 헤더를 위치시킨다. 결국 “wrapper” 요청은 Host가 없고 “smuggled” 요청은 Host가 두개나 존재하게 된다. 아래와 같은 방법으로 해결 가능하다.

[IMG10] Host 문제 해결 예시

원활한 공격을 위해선 Host 헤더 뿐만 아니라 다른 내부적인 헤더들 또한 신경써야 한다.

05. HTTP Request Tunnelling

대다수의 HRS 공격은 front-end 와 back-end 사이의 동일한 연결이 다수의 요청을 처리하기에 가능하다. 이와같이 연결을 재사용하는 서버도 있지만, 더 엄격한 정책을 가진 서버도 존재한다. 예를들어 동일한 IP 끼리만 요청을 묶는 경우가 있다. 소켓 poisoning을 통해 타 이용자의 요청에 간섭하는 기본적인 HRS 공격이 통하지 않을 것이다.

하지만 하나의 요청속에 다른 요청을 숨겨 back-end로 전하는 방법은 여전히 가능하다. 이는 요청을 숨기고 front-end 에서 응답을 재 매칭하여 받을 수 있다는 소리다. 특정 요청을 막는 front-end 보안 정책을 우회하여 접근을 시도할 수 있다.

[IMG11] HTTP request tunnelling

많은 서버들은 HRS를 막기 위해 다양한 메커니즘을 구현해놨다. 하지만 request tunnelling을 막기엔 부족한게 현실이다.

1) HTTP/2 환경의 Request Tunnelling

Request tunnelling은 HTTP/1과 HTTP/2 두 환경모두 가능하지만 HTTP/1 만을 사용하는 환경에서는 발견하기 힘들다. HTTP/1 에서 연결을 지속하는 속성(keep-alive) 때문에 두 응답을 전해받아도 성공적으로 smuggle 되었는지 알기가 어렵다.

반면, HTTP/2는 각 “stream”상 하나의 요청과 응답만을 포함한다. 이때문에 만일 HTTP/2 응답 body 속에 HTTP/1 처럼보이는 응답이 들어있다면 tunnelling을 성공적으로 진행했다고 확신할 수 있다.

2) 내부 헤더 유출

HTTP/2 downgrading 상황속 request tunnelling을 통해 내부 헤더를 유출할 수 있다. 내부 헤더를 back-end 에서 body가 될 숨겨긴 요청 뒤에 오게하는 방법이다.

[IMG12] Leaking internal headers

Front-end는 우리가 주입한 형식을 헤더의 일부로 받아들이고 새로운 내부적인 헤더를 “q=”다음에 위치시킨다. 반면 back-end는 “\r\n\r\n”을 헤더의 끝으로 판단하여 “q=”부터의 추가 헤더를 body의 일부로 받아들인다. 이렇게 내부적인 헤더를 확인할 수 있게 된다.

POST /search HTTP/1.1
Host: kortsec1.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 200

q=Secret-Header: kanyewestContent-Length: 3
x=x

3) Request Tunnelling using HEAD

어떤 경우에는 front-end에서 응답을 클라이언트에게 전달하는 과정에서 Content-Length 헤더 속 명시된 bytes 만큼 보내기에 tunnelled 요청에 대한 응답을 볼 수 없을 수도 있다. Blind request tunnelling이 바로 이런 것이다.

하지만, HEAD를 이용하여 non-blind request tunnelling으로 바꾸는 방법이 존재한다. HEAD method 요청에 대한 응답은 본인의 body가 없더라도 주로 같은 요청을 GET으로 보냈을 때의 응답 자원 길이를 content-length 헤더속에 포함시킨다.

[IMG13] HEAD Request

[IMG14] HEAD Response

[IMG14]의 예시 처럼 tunnelled 요청의 결과가 HEAD의 Content-Length 보다 길다면, 짤린 상태로 결과를 받아 원하는 정보를 얻기 어려울 수 있다. 반대로, tunnelled 요청의 결과가 HEAD의 Content-Length 보다 짧다면, front-end 서버는 추가적인 정보를 기다리다 timeout 에러를 보내게 된다. 이 두 경우를 고려해 HEAD 요청이나 tunnelled 요청 속 적절한 reflected input을 추가해 길이를 조정해야 한다.

05. 참고

https://portswigger.net/web-security/request-smuggling/advanced

https://portswigger.net/web-security/request-smuggling/advanced/request-tunnelling

https://portswigger.net/web-security/request-smuggling/advanced/http2-exclusive-vectors

https://portswigger.net/web-security/request-smuggling/advanced/response-queue-poisoning

https://portswigger.net/web-security/request-smuggling/advanced/http2-downgrading

https://www.youtube.com/watch?v=w-eJM2Pc0KI