최근 AWS Application Load Balancer 와 Classic Load Balancer 에 새로운 보안 기능인 HTTP Desync 공격 방어 모드가 추가되었습니다.
HTTP Desync 공격은 Multi Tier 환경(상황에 따라 Single Tier 에서도 악용 가능)에서 HTTP 트래픽을 처리하는 과정에서 발생할 수 있는 취약점을 노린 공격으로 흔히 HTTP Smuggling 기법을 사용하여 공격이 이루어집니다. HTTP Desync 공격에 대한 내용은 Googling 을 해보면 다양한 기술 문서와 동영상을 통해 그 상세한 내용을 접해볼 수 있는데요. 간단하게 HTTP Desync 공격을 정리해보면 아래 그림과 같이 Multi Tier 환경(상황에 따라 Single Tier 에서도 악용 가능)에서 HTTP Request Header 에 Content-Length Header 와 Transfer-Encoding Header 를 모두 삽입하는 방법으로 악의적인 요청이 First Tier 에서 Second Tier 로 전달될 수 있도록 이용하는 방법입니다.
위 그림에서 공격자가 보내온 HTTP 요청은 아래와 같습니다. POST 요청에 “Content-Length” 와 “Transfer-Encoding” Header 를 모두 추가하여 전달하였는데요.
POST /batch/ HTTP/1.1Host: www.example.comConnection: closeContent-Length: 101User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36Accept: */*Accept-Encoding: gzip, deflateTransfer-Encoding: chunkedAbc0x{"rid":"V33K5HMJVZ2BQS13GMZJ","sid":"138-9825740-3732834","mid":"ATVPDKIKX0DER","sn":"www.example.com","reqs":[{"csmcount":{"counter":"baselineCounter2","value":1,"t":4}},0GET /admin.phpHost: 10.100.10.25
이와 같은 요청을 받은 Web Server 가 만일 HTTP Desync 공격에 취약점이 있다면 위 여청에 대해서 아래와 같은 상황이 발생할 수 있습니다.
참고. 10.100.10.25 라는 IP 는 App Server 의 IP 로 이 IP 는 외부에서 직접 확인할 수 있는 방법은 없으나 공격자가 HTTP Desync 공격 등을 이용하여 내부 서버 정보를 획득한 상황에서 추가 공격을 진행하는 과정을 가정하기 위한 임의의 IP 입니다.
최초 Web Server 가 받은 요청은 POST Request 이지만 HTTP Header 에 존재하는 Transfer-Encoding 에 따라 POST 값 중 “0” 으로 끝나는 부분을 POST Request 의 끝부분으로 인식하였고 이후에 유입(POST 요청에 포함되어 있던)된 GET Request 를 다시 처리하기 위해서 Web Server 는 Host Header 에 있는 정보에 기반하여 내부에 위치한 App Server 로 요청을 전달하게 됩니다.
이처럼 HTTP Desync Attack 은 Content-Length 와 Transfer-Encoding 이 동시에 포함하여 최초 트래픽을 수신/처리하는 시스템을 교란하는 목적으로 사용되는 것으로 Content-Length 이후에 Transfer-Encoding 을 처리하도록 하는 CL-TE 형태의 공격과 반대로 Transfer-Encoding 처리 후 Content-Length 를 처리하도록 하는 TE-CL 형태의 공격 방식 등이 있습니다.
AWS 에서는 이와 같은 HTTP Desync Attack 을 방어할 수 있는 기능을 Application Load Balancer 와 Classic Load Balancer 에 새롭게 추가하였는데요. 이 블로그에서는 Application Load Balancer 를 이용하여 HTTP Desync Attack 방어 기능을 사용하는 방법을 살펴보도록 하겠습니다.
AWS 에서 제공하는 HTTP Desync 방어 기능은 HTTP Desync Guardian(https://github.com/aws/http-desync-guardian) 이라는 AWS Open Source 를 기반으로 합니다.
Application Load Balancer 를 생성 후 Attribute 부분을 선택하면 아래와 같이 “Desync Mitigation Mode” 가 있는 것을 확인할 수 있는데요.
Application Load Balancer 는 HTTP 요청이 수신되게 되면 HTTP Desync Guardian 을 이용하여 HTTP 요청을 분류하게 되는데 아래와 같이 RFC 7230 준수 여부와 보안 위협의 유무에 따라 4가지 유형으로 분류하게 됩니다.
- Compliant — Request complies with RFC 7230 and poses no known security threats.
- Acceptable — Request does not comply with RFC 7230 but poses no known security threats.
- Ambiguous — Request does not comply with RFC 7230 but poses a risk, as various web servers and proxies could handle it differently.
- Severe — Request poses a high security risk. The load balancer blocks the request, serves a 400 response to the client, and closes the client connection.
이렇게 분류된 HTTP 요청은 Application Load Balancer 의 Desync Mitigation Mode 설정에 따라 허용되거나 차단될 수 있는데 각각 분류된 HTTP 타입과 Mitigation Mode 의 상관 관계는 아래와 같습니다.
HTTP Desync Attack 은 최근에 소개된 공격은 아니지만 Burp Suite 와 같은 Proxy 도구를 이용하여 간단하고 쉽게 사용할 수 있는 공격 방법 중에 하나입니다. 따라서, 이에 대응할 수 있도록 Web Server 보안에 대해 구성하는 것이 최선이겠지만 AWS ALB 나 CLB 를 이용하는 환경이라면 새롭게 제공되는 HTTP Desync Mitigation 기능을 통해 손쉽게 해당 공격을 차단할 수 있습니다.
감사합니다.
