WebHacking - HTTP Request Smuggling

HTTP Request Smuggling

Normaltic 작성

 

HTTP Request Smuggling (HRS) 란?

HTTP의 Content-Length 헤더 변수를 조작하여 원하는 데이터 혹은 패킷을 Smuggling(밀수) 몰래 들여보내는 것이다. 이 공격을 통해 웹 서버 앞의 방화벽(F/W)을 우회하거나, 웹 캐시 서버의 Cache-Poisoning 등을 할 수 있다.

 

* 본 자료는 http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf 을 참조하여 작성하였다.

(1) Web Cache Poisoning

  이 공격을 가능하게 하는 취약점은 바로 HTTP의 Post 패킷에 Content-Length 헤더가 2개가 들어있을 때 받아들이는 방식이 웹 캐시 서버(Proxy)와 웹 서버(W/S)가 다르다는 점이다.

 

-> 그렇다면 HTTP Post 패킷에 Content-Length 헤더가 다른 값으로 2개 들어가있으면 서버는 어떻게 처리할까?

이는 서버마다 다 다르다. 예를 들면, SunONE W/S 6.1 (SP1)의 경우 첫 번째의 Content-Length 헤더를 사용한다. 반대로 SunONE Proxy 3.6 (SP4)의 경우 두 번째의 Content-Length 헤더를 사용한다.

 

위와 같은 차이로 인해 악의적인 Web Cache Poisoning이 가능하다. SunONE W/S 6.1 (SP1)의 서버 앞에 SunONE Proxy 3.6 (SP4)가 Proxy 서버로 있으며 SITE라는 DNS 주소를 가진 서버라고 가정하고 공격해보겠다.

< 공격 모습 >

  위와 같은 패킷들이 서버에 전달 되었을 때, Proxy 서버의 경우 1-7 번 라인을 POST Request라고 먼저 인식하게 된다. 그리고 Content-Length 헤더가 두 개 있다는 것을 알게 되는데 여기서 Proxy서버의 경우 첫 번째 Content-Length 헤더를 무시하고 두 번째의 Content-Length 헤더를 사용하여 Body의 길이가 44라고 인식하게 된다. 여기서 8-10 번 라인이 정확하게 44 바이트이다. 그러므로 8-10 번 라인을 첫 번째 POST 패킷의 Body라고 인식하게 되는 것이다. 그 다음으로 Proxy 서버는 11-14 번 라인을 GET Request로 인식한다.

 

  이제 웹서버의 경우를 보자. 웹 서버의 경우 Proxy 서버와 달리 첫 번째 Content-Length 헤더를 사용한다. 그래서 Body 길이가 0이라고 인식한다. 그렇게 되면 8번부터 새로운 GET 요청으로 인식하게 되는 것이다. 여기서 주목할 점은 10번 라인 다음에 CRLF 이 없다는 것이다. 그렇기 때문에 11번 라인이 새로운 GET Request로 인식되지 않고 8번 라인의 GET Request 패킷의 Bla 헤더의 값으로 인식 되는 것이다.

 

  정리해보면 다음 표와 같다.

< 정리 >

  Proxy와 Web 서버에서 둘 모두 2개의 Request가 왔다고 인식한다. 하지만 그 2개의 내용이 다르다. 어떤 2개의 Request인지는 위의 표로 정리하였고 내용은 다음과 같다.

 

  Proxy에서 2번 째 Request는 “http://SITE/page to poison.html”을 요청한다고 인식하였고, Web 서버에서 2번째 Request는 “/poison.html”을 요청한다고 인식하였다. Web 서버는 “/poison.html” 요청의 결과를 돌려주는데 이 때 Proxy 서버가 이를 캐싱해 둔다면 Proxy 서버는 “http://SITE/page to poison.html” 요청과 “/poison.html”의 결과를 매칭시켜 저장하게 된다.

 

* 더 강력하게 효과 보는 경우

  만약 서버가 가상 호스팅하고 있는 경우라면, 효과가 더 강력할 수 있다. IP는 같으므로 HTTP 패킷 안에 host 헤더만 다시 설정하므로써 다른 많은 사이트들에 대해 공격을 할 수 있다.

 

  이를 통해 악의적으로 Web Cache를 조작할 수 있게 된다. 이 것이 Web Cache Poisoning의 공격에 활용 될 수 있는 방법이다.

(2) Firewall/IPS/IDS 우회

 

방화벽이나 IPS, IDS의 경우 특징 기반으로 악성 패킷을 검출한다. 예를 들어 “cmd.exe”라는 문자열이 URL에 들어가 있다거나 하는 특징들이 있다. 혹은 SQL Injection에서 사용하는 특징들을 생각해 볼 수 있다.

 

이 자료에서 보여주는 공격은 IIS/5.0 기반 서버에서 이루어진다. ISS/5.0는 큰 Body를 가진 POST Request를 처리할 때 버그가 일어난다. 바로, Request에 Content-Type헤더에 정해진 타입이 아닌 경우 49,152 Bytes(48K) 만큼 잘라서 읽는다. 그래서 48K + X 의 크기로 보내게 되면 X 만큼의 데이터를 Smuggling할 수 있게 된다.

 

아래 공격 예시는 ISS/5.0 서버이고 앞 단에 Firewall이 설치 되어있는 경우이다. 공격 목적은 Firewall을 우회하여 서버에 “cmd.exe” 문자열이 도착하게 하는 것이다.

< 공격 패킷 >

  위와 같은 모습으로 패킷을 전달하게 되면, Firewall 입장에서는 첫 번째 Request를 49223 Byte 크기의 Body를 가지고 있다고 인식하게 된다. 위에서 보면 10번 라인 까지를 첫 번째 Request로 인식한다. 그 다음 Firewall은 두 번째 Request를 11번 라인부터 인식하게 되는데 주목할 점은 12번 라인이다. 12번 라인 뒤에 CRLF가 없다. 그렇기 때문에 13번라인부터가 두 번째 Request의 Bla헤더의 값에 포함되어 인식되는 것이다. 그렇게 되면 Firewall은 이 2가지 패킷을 막지 않는다. 이유는 URL에 공격 패턴이 없었기 때문이다.

 

  하지만 Firewall을 지나서 서버에 도착하면 상황이 달라진다. IIS/5.0 서버에서 첫 번째 Request를 보면 Content-Type이 없다. 그렇기 때문에 서버는 49152 크기로 Body를 잘라버린다. 그러면 1-6번 라인이 첫 번째 Request로 인식 되는 것이다. 그리고 두 번째 Request로 7번 라인부터 인식이 되는데, Content-Length가 30으로 되어있다. 그래서 Body로 11-12번 라인이 포함된다. 그렇게 되면 서버 입장에서는 다음 Request가 13번부터 받아들이게 되는데 13-15번 라인의 Request를 보면 URL에 “cmd.exe” 문자열이 있는 것을 확인 할 수 있다. 그렇게 되면 서버 입장에서는 “cmd.exe”를 실행되어 공격이 이루어 질 수 있다. 인식하는 Request를 정리해보면 아래 표와 같다.

< 정리 >

(3) Forward VS Backward HRS

 

일반적으로 HRS 공격은 3개의 Request를 보내는데, Content-Length를 조작하여 각각 다른 2개의 Request로 보이게 하는 원리로 공격이 일어난다. 첫 번째 예에서는 req1, req2를 웹 서버가 인식하고, req1, req3을 Proxy가 인식하므로써 공격이 일어났는데, 이러한 경우를 Forward Smuggling이라고 한다.

< Forward Smuggling >

  이와 반대로 Backward Smuggling이 있다.

< Backward Smuggling >

  Forward Smuggling보다 Backward Smuggling 공격이 훨씬 어렵다. 그 이유는 Proxy가 Request를 받고 웹 서버에 전달하는데 그에 대한 응답을 받을 때 까지 다음 Request를 보내지 않기 때문이다. 이럴 경우 Proxy는 첫 번째 Request라고 인식하여 보내고 그에 대한 응답을 기다리는데 웹 서버의 경우 Request가 다 도착하지 않았으므로 기다리게 된다. 그러면 Deadlock에 빠지게 된다. 이렇게 보면 이론적으로 Backward Smuggling이 불가능한 것처럼 보인다. 하지만 예외의 경우가 있다.

  이번 예시는 DeleGate/8.9.2 캐시 서버를 사용한다. 그리고 웹 서버로는 IIS/6.0, Tomcat, SunONE 서버 등을 사용할 수 있다. 이번 트릭은 바로 이 것이다. 우리는 GET Request를 사용할 것이다. 그런데 이 GET Request에 Content-Length 헤더와 값을 넣어서 보낼 것이다. DeleGate는 GET Request의 Content-Length를 0이라고 생각한다. 즉, Body가 없다고 생각하는 것이다. (실제로 GET에는 Body가 없다.) 반대로 웹 서버는 Content-Length 값 만큼의 Body가 있는 Request라고 생각한다. 그렇지만 웹 서버는 Body를 받기 전에 응답을 보내준다. 바로 이 점에서 Backward Smuggling이 가능한 것이다. 웹 서버는 Body가 있는 Request라고 생각하지만, GET 요청이므로 Body부분이 도착하기 전에 응답을 보내는 것이다.

 

  공격 예시는 다음과 같다.

< Backward Smuggling >

  위의 패킷을 보내게 되면, DeleGate는 Content-Length 헤더를 무시한다. 이유는 GET 요청이기 때문이다. 첫 번째 요청을 1-6 번 라인이라고 인식한다. 그 후 7-10번 라인 까지를 두 번째 요청이라고 생각한다. 이유는 8번 라인 다음에 CRLF가 나오지 않았기에 9-10번 라인이 Bla 헤더의 값이라고 생각하기 때문이다. 이와 반대로 웹 서버에서는 첫 번째 요청이 40 바이트 크기의 Body를 가진 요청이라고 생각한다. 그렇기에 1-6번 라인까지 받았을 때 GET이기 때문에 응답은 하되, 나머지 40 바이트 크기의 Body를 기다린다. 그 후 7-8번 라인까지 40 바이트가 들어오면 첫 번째 요청의 Body라고 인식한다. 그 후 9-10번 라인의 요청을 두 번째 요청이라고 생각하는 것이다. 이렇게 악의적으로 인식되는 요청은 3번째(후자) 이므로 Backward Smuggling이 가능하게 되는 것이다. 

(4) Request Hijacking ( HTTP Request Smuggling Through a Proxy Server )

  HTTP Request Smuggling 공격을 통해 XXS 공격과 비슷한 결과를 만들 수 있다. XXS 공격이란 간단히 설명하면 클라이언트(피해자) 컴퓨터에서 악성 스크립트가 실행되도록 하는 공격이다. 비슷한 결과를 만들지만 XXS 공격보다 훨씬 더 성능이 좋다. 그 이유는 HttpOnly Cookie 정보나 HTTP 인증 정보들을 직접 가져갈 수 있기 때문이다. ( Cross Site Tracing이 필요없다. )

 

(* 참고 : Cross Site Tracing : HTTP의 TRACE 방식을 지원 할 때 가능. )

 

  Request Hijacking의 선행 조건

 

    1. 서버 앞단에 Proxy 서버가 존재해야한다. ( Web Cache Poisoning과 달리 캐싱기능은 없어도 된다. )

    2. 해당 웹 서버에 XXS 취약점이 존재해야한다.

< Request Hijacking 원리 >

  공격 예시는 위와 같다. 위 데이터를 보내게 되면, Proxy 서버에서는 두 번째 Content-Length로 인식하고 위 전체 내용이 하나의 요청으로 전달된다. 하지만 서버에 도착해서 서버가 해석하기를 첫 번째 Content-Length로 인식하여 1-7번 라인(this=that까지) 의 요청으로 인식하고 응답한다. 그 뒤 데이터를 POST 요청으로 인식한다. 여기서 Content-Length를 95로 잡아주었는데 여기서 94 바이트만 제공되어있다. 그러면 나머지 한 바이트를 서버는 기다리게 된다. 이 때 피해자가 GET 방식으로 요청을 했다고 가정하자. 그렇게 되면 한 바이트를 기다리면 요청이 있는데 여기에 데이터의 맨 앞 ‘G’라는 문자가 소모된다. 

< 완성되는 요청 >

 

  그렇게 되면 위와 같은 요청이 완성된다. 이 요청에 대한 응답으로 cookie를 출력하는 스크립트가 피해자에게 전송되는 것이고 그렇게 피해자의 컴퓨터에서 임의의 스크립트가 실행되는 것이다.

 

  그런데, 이는 HTTP Request Smuggling을 통해 어떻게 악성 스크립트가 실행되는지를 확인한 것이다. 이를 이용해 세션정보가 있는 cookie와 인증 정보를 탈취하기 위해서는 약간의 트릭이 필요하다.

< 자바 스크립트 >

  위 자바 스크립트는 document의 텍스트 정보들을 단일 문자열로 concat한 후, 앞에서부터 300바이트를 잘라내는 동작을 한다. 이를 이용해 다음과 같은 공격 패킷들을 구성했다고 해보자.

< 스크립트를 추가한 패킷모습 >

  param1 변수부터 시작되는 body의 길이는 277바이트만 제공하였다. 이렇게 되면 나머지 300바이트를 웹 서버는 기다리게 된다. 피해자가 보낸 요청으로부터의 300바이트를 사용하게 된다. 이 상태의 응답이 클라이언트(피해자)에게 전송되고 피해자의 브라우저에서 해당 응답이 로딩될 때, 삽입한 스크립트가 실행된다. document의 텍스트 부분 앞에서 300바이트를 잘라내는데 이 안에 보통 Cookie와 인증 정보 헤더가 담겨있다. 또한 이와 함께 URL도 담겨있는데 이를 활용해 해당 사이트의 인증 정보와 쿠키를 Hijacking 할 수 있다.

(5) Request Credential Hijacking ( HTTP Request Smuggling Through a Proxy Server )

 

  클라이언트의 크리덴셜을 가지고 특정 스크립트를 실행시키는 또 다른 방법이 있다. 이 방법은 클라이언트의 크리덴셜을 가지고 악성 스크립트를 실행한다는 것으로 CSRF(Cross-Site Request Forgery) 공격과 비슷하다. 그러나 CSRF보다 훨씬더 효과가 좋다. 그 이유는 클라이언트(피해자)와 상호작용할 필요가 없기 때문이다.

< 공격 패킷 >

  이 때 피해자가 아래와 같은 요청을 했다고 가정하자.

< 피해자의 요청 >

  그렇게 되면 위 공격 패킷의 빨간 부분(GET 요청)에 최종적으로 아래와 같은 패킷이 만들어지게 된다. 

< 만들어진 위조된 요청 >

이 요청은 ‘/some_page.jsp’의 페이지에서 피해자의 크리덴셜을 가지고 요청이 되는 것이다. 그렇게 되면 CSRF와 비슷한 효과를 낼 수 있다. 만약 이 ‘/some_page.jsp’ 페이지가 비밀번호 변경 페이지라던가, 큰 돈을 전송하는 페이지였다면 피해가 컸을 것이다.