HTTP Smuggling

HTTP request smuggling 취약점은 HTTP/1 version에서 발생한다.
해당 취약점은 Front-end와 Back-end에서 http request를 해석하고 처리하는 방식에 따라 
응답이 달라지게 되는 점을 활용한 취약점이다.
이를 알려면 Content-Length와 Transfer-Encoding 헤더에 대한 개념을 파악해야한다.
 
 
- Cotent-Length header
해당 헤더는 Request packet의 body message의 크기를 표기한다.
만약, content-length 값이 10bytes인데 entity body에서 5bytes 값만 있다면
server 입장에서는 data가 아직 들어오지 않았다고 판단하여 기다릴 것이다.
이 때, request가 추가적으로 들어오지 않으면 timeout이 되는 매커니즘을 갖고 있다.
 
 
- Transfer-Encoding
HTTP/1.1에서 data 전송 매커니즘 중 하나로 content-length를 모를 경우 해당 헤더를 사용하여 
중간중간에 계속 data를 전송할 수 있도록 하기 위해 사용한다.
만약 data를 더이상 줄 것이 없다면 마지막에 0 \r\n 을 보내게 된다.
여기서 다룰 encoding 방식은 chunked 방식이다.
 
 

---

 
 

공격 종류

 
1. CL.TE 취약점
 
Front-End에서 Content-Length를 통해 packet 길이를 계산하고
Back-End에서 Transfer-Encoding을 통해 packet 길이를 계산하는 case
 
밑의 사진을 예시로 확인하면 다음과 같이 packet을 처리한다.
 

 
 
- Front-End에서 packet의 smuggling 문자열을 끝까지 읽고 Back-End로 전송
- Back-End에서 Transfer-Encoding: chunked 헤더를 통해 packet을 읽어들임
- 0을 만나면 Back-End는 해당 packet의 끝으로 인식
- 뒤에 있는 smuggling 문자열은 다음 새로운 packet의 시작으로 간주
 
 
 
 
 
2. TE.CL 취약점
 
Front-End에서 Transfer-Encoding 을 통해 packet 길이를 계산하고
Back-End에서 Content-Length를 통해 packet 길이를 계산하는 case
 
먼저 밑의 내용처럼 request packet을 작성 후 server로 처음 pacekt을 전송하면 500 error가 반환되는 것을 볼 수 있다.
 

POST / HTTP/1.1
Host: 0a640086040c633081bb3efd006c00d0.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 6
Transfer-Encoding: chunked

0

X

 
 

 
왜 500 timeout error가 발생할까?
packet을 전송하고 server에서 반환하는 매커니즘이 다음과 같이 동작하기 때문이다.
 

 
Front-end에서 Transfer-Encoding의 chunked를 해석하여 0\r\n\r\n을 처리하고 
Back-end에서 Content-Length의 6 bytes를 해석하게 되는데 
현재 전달하는 packet의 body 크기가 6byte이상이 아니다!
0\r\n\r\n = 5byte

따라서 6byte 크기만큼 data가 오지 않은 상황이니
기다려도 data 크기만큼 packet이 오지 않아
timeout error를 반환한 것이다.
 
 
 
그렇다면 해당 server에 http smuggling이 가능한지
확인하기 위해 2개의 packet을 전송하여 
server의 반응을 확인해보도록 하자.
먼저 공격 packet으로 다음과 같이 request를 전송하면 server에서는 정상적인 응답을 한다.
 

 
 
그 다음 일반 사용자가 Content-Length에 맞는 packet즉, 정상적인 packet을 전송하면 다음과 같이 응답한다.
 

 
 
G0POST가 응답 패킷에 포함되어 있는 이유는
attack request packet의 body 부분에 들어간 값이
buffer에 아직 저장되어 있기 때문이다.
이를 다음과 같은 그림으로 매커니즘을 이해해 볼 수 있다.
 

 
 
Back-End에서 처리하지 못한
"나머지 data = (G\r\n\0\r\n\r\n)" 
해당 data가 바로 다음 사용자가 request를 전송했을 때 정상적인 packet이 Front-End에서 처리 후
Back-End로 넘어갈 때 이전에 남은 data가 buffer에 남아있기 때문에
남은 data가 Back-End로 전달되는 정상 packet에 붙어위와 같은 smuggling이 발생한 것을 볼 수 있다.
 
 
위의 예제를 통해 다음과 같이 http smuggling 공격을 시도해볼 수 있다.
공격 request packet을 다음과 같이 작성해봤다.
 

POST / HTTP/1.1
Host: 0a640086040c633081bb3efd006c00d0.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

56
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 6

0

 
 
위의 request packet으로 설정하고 server로 전송하면 첫 응답은 정상적으로 돌아온다.
그러나 buffer에 처리되지 않은 body 부분의 data가
남아있기 때문에 해당 data들은  다음 정상 packet에
이어서 처리된다.
 

 

 
 
http smuggling의 기본적인 공격 매커니즘은 여기까지!
실제 공격은 어떻게 이뤄지는지는 다음에 이어서 해보자!