[Web] HTTP Request Smuggling을 이용한 다양한 웹 해킹 기법(개념)

HTTP Smuggling(HTTP 스머글링)은 꽤 예전에(2005년?) 발견되었지만 최근 버그바운티를 통해

PayPal에서 취약점이 발견되면서 대응하기도 어렵고 해서 다시 이슈가 된 듯하다.

스머글링 공격은 메인 웹서버의 과부하를 막기위한 프론트단에서의

리버스 프록시 서버 사용 또는 로드 밸런서 사용 시 CL(Content-Length)과 TE(Transfer-Encoding)의 처리를

프론트 엔드(Front-End)와 백 엔드(Back-End)에서 다르게 한다는 점을 이용한 공격 기법이다.

이 공격을 통해 프론트엔드의 보안을 우회하거나 다른 사용자의 패킷을 캡처하는 등 다양한 연계 공격이 가능하다.

처음보면 내용이 조금 어렵지만 여러 글들을 참고하고 실습을 거친 후 다시 정독하면 이해하기 쉽다.

최대한 쉽게 풀어서 포스팅함

 

일반적으로 HTTP 패킷을 서버에서 받으면

패킷의 헤더가 시작되는 부분과 끝 부분을 CL(Content-Length)과 TE(Transfer-Encoding)를 통해서 명확하게 구분짓는데 이 구분을 건드려서 애매하게 하는 원리이다.

스머글링 공격은 크게 3가지로 구분되어 사용되는데

• CL.TE : Front-end 서버가 Content-Length로 판단하고 Back-end 서버는 Transfer-Encoding으로 판단할 때
• TE.CL : Front-end 서버가 Transfer-Encoding로 판단하고 Back-end 서버는 Content-Length로 판단할 때
• TE.TE : 프론트 엔드 서버와 백엔드 서버 둘 다 Transfer-Encoding으로 판단하고 둘 중 하나가 헤더를 처리하지 못할 때

 

기본적인 CL.TE 부터 살펴보면 일단 웹페이지에 접근해서 패킷을 캡처한다.

 

위 페이지는 GET 메소드 POST 메소드가 아닐 때 아래 사진과 같은 응답값을 주는데 스머글링 공격으로 POST 메소드를 전송하지만

백엔드단에서 판단하기에는 GPOST 메소드를 전송하는 것 처럼 보이게 한다.  

 

패킷 캡처

 

스머글링 공격을 위한 헤더를 제외하고 불필요한건 가시성을 위해 다 삭제

 

Transfer-Encoding 헤더를 추가해서 CL.TE 공격을 하면 아래 사진과같이 POST 메소드를 전송하였음에도

끝에 G가 붙어서 GPOST로 인식하는 것을 볼 수 있다.

반응형

위 패킷 내용은 아래와 같은데 

프론트 엔드는 Content-Length 헤더를 처리하면서 끝(G)까지 10바이트의 길이가 맞는지 확인한다.

근데 백 엔드서버는 Transfer-Encoding 헤더를 처리하기 때문에 (chunked 인코딩은 0이 발견될 때 종료한 것으로 처리)

0 이후에 나오는 G라는 문자에 대해서는 처리되지 않고 버퍼에 남아있게 되는데

이 남은 쩌리 G는 다음 패킷에 첫 시작으로 붙여져서

POST 메소드 앞에 G가 따라붙게 되는것이다.

그래서 사용자가 페이지에 접근하게되면 GPOST 메소드가 전송됨

POST / HTTP/1.1
Host: 0a3c007e03312c9ac0190af000f80091.web-security-academy.net
Content-Length: 10
Transfer-Encoding: chunked
 
0
 
G

 

그 다음 공격 방법인 TE.CL은 그 반대이고 원리는 동일하다.

마찬가지로 패킷 캡처후 필요없는 헤더는 모두 삭제

 

TE.CL 공격 패킷은 다음과 같다

 

일단 프론트 엔드서버는 TE 헤더를 사용하여 판단하는데 다 첫 TE의 길이가 5c

여기서 5c가 의미하는건 Hex값이다 Length가 92바이트란 말인데 GPOST부터 제일 아래 0 까지의 길이를 말함 chunked가 16진수를 이용해서 길이를 판단하기 때문에 16진수값으로 표기를 해준다.

어쨋든 0이 될 때 chunked가 종료되고 이 요청을 백엔드로 전송한다.

이번엔 백엔드가 CL 헤더를 사용하여 판단하기 때문에 (이때 공격자는 CL값을 4로 고정해주었음) CL의 길이가 다음 요청까지 4가 맞는지 확인한다 

개행문자을 포함해서 /r/n 5c 까지 확인

5c까지 4바이트가 맞으니까 종료한 후

그 다음 GPOST의  CL 끝까지를 처리하지 못하고 버퍼에 남겨진다

그럼 이 남겨진 애들은 다음 요청 패킷으로 시작하게된다.

POST / HTTP/1.1
Host: 0ab400510451d4e9c020102500880021.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
 
5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
 
x=1
0

 

좀 어려운데 패킷을 조금 바꿔서 전송하면

첫 CL을 4에서 5로 늘리고 

chunked 값은 5c(92)에서 5d(93)으로 1씩 늘려서 전송했을 때

GPOST 에서 1바이트가 늘어난 GPOST1 이 되어 총 93바이트가 프론트엔드단에서 전송되고

기존에 백엔드단에서는 기존 5D 까지만 해서 4바이트로 처리한 후 다음 GPOST 전부를 다음 패킷으로 보냈지만

CL이 4에서 5로 1바이트 늘었기 때문에 5D G 까지 처리한다음 POST1부터 다음 패킷을 요청하여

응답이 POST1로 날아온다

 

이런 HTTP 스머글링 공격을 이용한 다양한 공격들이 있다.

두번째 포스팅에서 정리 예정