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

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

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

 

개념을 이해했다면 HTTP 스머글링을 찾는 방법과 이를 활용한 공격기법을 알아야한다.

 

HTTP Request Smuggling을 찾는 방법

기본적으로 파이썬으로 제작된 자동화 도구를 이용하여 진단하는 방법과

https://github.com/defparam/smuggler

GitHub - defparam/smuggler: Smuggler - An HTTP Request Smuggling / Desync testing tool written in Python 3

 

버프에서 제공해주는 익스텐더를 설치하여 진단하는 방법이 있다.

수동으로 진단하는 방법은 스머글링 페이로드와 함께 패킷을 서버에 전송 했을 때

응답 시간이 길어지는 것으로 취약 여부를 확인할 수 있다.

해당 페이지의 기본적인 응답시간은 543 ms 

하지만 CL.TE 기법으로

스머글링 페이로드를 전송하게되면 10,541 ms 로 응답시간이 엄청나게 길어져 프록시 에러까지 발생한 것을 볼 수 있다.

위 사진처럼 응답시간이 길어지는 이유는

패킷을 받았을 때 프론트단에서 CL로 판단하여 4바이트(a)까지  확인 후 백엔드에 전송하고

그 후 백엔드에서는 TE를 확인(x) 후 끝나지 않아 다음 내용이 더 있을거라 판단하여 계속 기다리게 된다.

그래서 응답시간이 길어지고 에러가 발생함

POST / HTTP/1.1
Host: 0ade004b04feb342c0693bf900a60007.web-security-academy.net
Transfer-Encoding: chunked
Content-Length: 4

1
a
x

 

TE.CL 기법으로 똑같이 취약 여부를 판단할 수 있다.

프론트단에서 TE는 0에서 끝냈지만 백엔드단에서 CL이 더 많은 메시지가 있을것이라 판단하여 기다리게되는 것

POST / HTTP/1.1
Host: 0ade004b04feb342c0693bf900a60007.web-security-academy.net
Transfer-Encoding: chunked
Content-Length: 4

0

x

 

또한 스머글링을 이용한 요청에 대한 응답이 돌아오는지로 취약 여부를 판단할 수 있다.

처음은 POST 방식으로 메인 페이지를 불러오고

두번째 요청 시 404 페이지가 읽어와지는 것은 스머글링에 취약하다는 반증이 된다.

취약 여부를 점검하고 취약한 것을 알았다면 이제 활용해서 공격을 해야한다.

공격기법은 다양하게 있다

1. 프론트 엔드(Front end) 접근 제어 우회

아래 사진처럼 /admin 페이지 즉 관리자 페이지로 접근을 하면 프론트 단에서 접근을 제어하는 페이지가 있다.

 

여기서 CL.TE 스머글링 공격을 이용하여 메인 페이지와 /admin 의 요청을 보내게되면

백엔드단에서는 둘다 프론트엔드에서 요청을 허락해주고 전송하였다고 판단하여 접근이 가능하게 된다.

 

local user만 이용가능하단 응답을 보고 Host 헤더에 localhost를 추가한 후 접근이 가능한 것을 확인할 수 있다.

 

해당 페이지의 회원 삭제 파라미터를 전송하여 파라미터가 정상적으로 전송되어 삭제까지 이루어지는 것을 볼 수 있다.

 

2. 불특정 타 사용자의 요청 패킷 캡처

요청 패킷 캡처는 글작성을 통해 이뤄질 수 있다.

스머글링 공격은 첫번째 패킷을 보낸 후 백엔드단에서 두번째 요청 시 버퍼에 남아있는 헤더들을 받아들인다는 점에서

버퍼에 남아있는 페이로드들이 

타 사용자가 페이지에 접근하며 실행되면 그 패킷이 그대로 글로 작성되게끔 할 수 있다.

이렇게 댓글을 작성하는 페이지가 있다.

 

댓글 작성 시 요청 패킷은 아래 사진과 같다

 

반응형

위에서 댓글 작성시 요청되는 패킷의 내용을 그대로 스머글링 페이로드로 옮겨서 전송하게 되면,

공격자가 패킷 하나를 전송 직후에 댓글을 작성하는 페이지에 접근하는 사용자의 요청은

POST 메소드로 post/comment  요청으로 가게된다 

이 때, 댓글에 패킷이 담길 수 있도록 내용이 작성되는 파라미터인 comment 파라미터는 제일 마지막으로 빼준후 전송

그러면 comment=test2 바로 뒤에 POST ~~~~ 로 요청패킷이 작성됨

 

그 결과, 페이지에 다시 재접근 하게되면 그 사용자의 요청 패킷이 그대로 댓글에 작성되는 것을 볼 수 있음

 

이 때 사용자의 모든 패킷을 담을 수 있도록 CL 값을 1씩 천천히

증가 또는 감소해주면서 정확한 바이트 길이를 찾아야한다

 

1씩 증가시키면서 정확한 값을 찾게되면 패킷이 정상적으로 캡처되어 작성되는 것을 볼 수 있다.

세션 탈취가 가능함

 

3. 헤더를 이용한 Reflected(반사형) XSS 

스머글링 요청 패킷 전송 직후 다음 사용자가 그 패킷을 그대로 요청한다는 점을 이용하여

반사형 XSS 공격도 노려볼 수 있다.

아래 사진처럼 어떤 게시글에 접근 시 User-Agent 헤더에 스크립트 구문을 삽입하여 전송하게되면

이후 사용자가 9번 게시글에 접근했을 때 스크립트가 동작하는 것을 볼 수 있다.

 

 

실제로 페이지를 조금 살펴보면 스크립트가 삽입된 것을 볼 수 있다.

 

 

이외에도

Web Cache Poisoning 공격

리다이렉션 공격 등등 정말 다양한 활용이 가능하다.