HTTPoxy 취약점 NGINX로 완화하기
일부 FastCGI 구성과 같이 CGI 또는 CGI와 유사한 환경에서 실행되는 일부 서버 측 웹 애플리케이션에 영향을 미치는 HTTPoxy 라는 취약점이 발표되었습니다. 현재까지 영향을 받는 것으로 알려진 언어로는 PHP, Python, Go 등이 있습니다.
특정 언어와 CGI 구현을 다루는 여러 CVE가 지정되었습니다.
Apache HTTP Server (CVE-2016-5387)
Apache Tomcat (CVE-2016-5388)
Go (CVE-2016-5386)
PHP (CVE-2016-5385)
취약점을 설명하는 새로운 웹 사이트, CERT 취약점 노트 및 취약점 발견에 대한 설명이 있습니다. Vend의 Open Source 웹 개발자인 Dominic Scheirlinck의 개인 웹사이트에 추가 정보가 있습니다.
이 포스트에서는 이 취약점에 대해 설명하고 서버에서 이 취약점을 악용하려는 시도를 무력화하기 위해 NGINX 또는 NGINX Plus를 사용하는 방법을 설명합니다.
이 취약점은 Namespace 충돌로 인해 존재합니다. CGI 또는 FastCGI와 유사한 인터페이스는 HTTP 요청 매개변수를 기반으로 환경 변수를 설정하며, 이러한 환경 변수는 애플리케이션을 구성하는 데 사용되는 내부 변수를 재정의할 수 있습니다.
현재 알려진 이 취약점의 유일한 악용 사례는 특정 HTTP 클라이언트 라이브러리를 사용하여 다른 서비스에 HTTP 요청을 하는 CGI 및 CGI 유사 환경에서 실행되는 웹 애플리케이션입니다. 이 경우 공격자는 아래 그림과 같이 애플리케이션에서 생성된 내부 요청을 원하는 서버로 리다렉션하여 요청에 포함된 모든 Secret 데이터를 캡처할 수 있습니다.

HTTPoxy 는 Namespace 중첩을 사용하여 내부 서버 트래픽에 액세스합니다.
NGINX 또는 NGINX Plus를 사용하여 이 취약점을 악용하려는 시도를 식별하고 무력화할 수 있습니다. 이렇게 하면 공격을 효과적으로 방지할 수 있으며, 영향을 받는 코드를 감사하고 업데이트할 시간을 확보할 수 있습니다.
목차
1. HTTPoxy 취약점이 악용되는 방법
1-1. CGI 및 CGI 유사 인터페이스는 HTTP_*라는 이름의 환경 변수를 정의합니다.
1-2. 일부 애플리케이션 라이브러리는 환경 변수를 통해 구성됩니다.
1-3. 취약점의 특성
2. NGINX 및 NGINX Plus를 사용하여 공격 방어하기
2-1. Upstream FastCGI 애플리케이션과 통신하기
2-2. Load Balancing 및 HTTP 트래픽 Proxy 처리
2-3. 취약점을 악용하려는 시도 탐지하기
3. HTTPoxy 결론
1. HTTPoxy 취약점이 악용되는 방법
이 취약점이 어떻게 작동하는지, 그리고 이 취약점으로부터 사이트를 보호하는 방법을 이해하려면 CGI 및 CGI 유사 인터페이스가 환경 변수를 설정하는 방법과 일부 애플리케이션 라이브러리가 환경 변수에 의해 구성되는 방식을 이해해야 합니다.
1-1. CGI 및 CGI 유사 인터페이스는 HTTP_* 라는 이름의 환경 변수를 정의합니다.
많은 웹 애플리케이션 플랫폼은 애플리케이션을 웹 서버에 연결하기 위해 CGI 또는 CGI와 유사한 인터페이스를 사용합니다. 이러한 인터페이스는 HTTP 요청의 헤더를 HTTP_가 접두사로 붙은 환경 변수로 변환합니다. 그러면 애플리케이션은 환경을 검사하여 요청 헤더(예: User-Agent)의 값을 조회할 수 있습니다.
클라이언트는 적절한 헤더와 함께 요청을 전송하여 애플리케이션의 환경에서 임의의 환경 변수(HTTP_로 시작)를 생성할 수 있습니다. 예를 들어, 요청 헤더 Foo: bar는 환경 변수 HTTP_FOO=bar가 됩니다.
일부 플랫폼은 PHP의 $_SERVER 전역 변수와 같이 환경 변수를 숨기는 추상화 계층을 제공합니다. 하지만 이러한 추상화 계층은 환경 변수를 설정하는 표준 CGI 및 FastCGI 관행을 기반으로 구축됩니다.
예를 들어 FastCGI 모드에서 실행하는 경우 PHP 애플리케이션은 다음과 같이 요청의 User-Agent 헤더를 확인할 수 있습니다.
// both methods return the same result
$useragent = getenv( 'HTTP_USER_AGENT' );
$useragent = $_SERVER['HTTP_USER_AGENT'];
1-2. 일부 애플리케이션 라이브러리는 환경 변수를 통해 구성됩니다.
복잡한 웹 애플리케이션은 외부 라이브러리에서 기능을 가져옵니다. 예를 들어, 애플리케이션이 Microservices와 같은 방식으로 다른 서비스에 HTTP 요청을 해야 하는 경우가 있는데, 이때 일반적인 타사 라이브러리 중 하나를 사용할 수 있습니다. 이러한 라이브러리는 HTTP 요청을 중계하는 데 사용되는 중개 서버인 HTTP Proxy라는 기능을 지원하는 경우가 많습니다.
이와 같은 라이브러리를 구성하는 쉬운 방법 중 하나는 환경 변수를 통해 구성을 정의하는 것입니다. 널리 사용되는 PHP Guzzle 라이브러리는 Proxy 서버의 주소로 설정되는 HTTP_PROXY라는 환경 변수로 부분적으로 구성됩니다. HTTP_PROXY가 이런 식으로 설정되면 라이브러리는 생성하는 모든 HTTP 요청을 Proxy 서버의 주소로 전달합니다. Go의 net/http 패키지와 Python의 Requests 모듈도 동일한 방식으로 HTTP_PROXY 환경 변수를 신뢰하고 해석합니다.
1-3. 취약점의 특성
항목 2에 설명된 라이브러리는 CGI 또는 CGI와 유사한 인터페이스를 염두에 두고 설계되지 않았으며, 해당 라이브러리가 신뢰하는 HTTP_PROXY 환경 변수는 항목 1에서 설명한 것처럼 CGI 및 FastCGI 인터페이스에서 사용하는 HTTP_ Namespace와 겹칩니다.
공격자는 HTTP_PROXY 환경 변수의 값을 자신이 선택한 주소로 설정하여 애플리케이션에서 생성된 내부 HTTP 요청을 리다이렉션하고 캡처할 수 있습니다. 이러한 요청에는 인증 키 및 개인 데이터와 같은 민감한 정보가 포함될 수 있으며, 악용될 수 있는 추가 API 및 Endpoint에 대한 정보가 드러날 수 있습니다.
공격자는 Proxy 헤더가 포함된 요청을 보내면 CGI 또는 FastCGI 인터페이스가 해당 애플리케이션 호출을 위해 HTTP_PROXY라는 환경 변수를 순순히 생성합니다. 가짜 Proxy 헤더가 포함된 요청만 직접 영향을 받습니다.
2. NGINX 및 NGINX Plus를 사용하여 공격 방어하기
HTTPoxy 취약점은 NGINX에 직접적인 영향을 미치지는 않지만, NGINX 및 NGINX Plus를 사용하여 이 취약점을 기반으로 하는 공격을 차단할 수 있습니다.
2-1. Upstream FastCGI 애플리케이션과 통신하기
NGINX를 사용하여 HTTP_PROXY FastCGI 매개 변수를 빈 문자열로 설정하여 애플리케이션에 대한 입력을 “Sanitize”할 수 있습니다. 이렇게 하면 FastCGI 요청에서 매개변수가 완전히 제거됩니다:
fastcgi_param HTTP_PROXY "";
2-2. Load Balancing 및 HTTP 트래픽 Proxy 처리
HTTP 요청을 Upstream 애플리케이션으로 Proxy 할 때는 Upstream 애플리케이션이 취약한 플랫폼에서 실행되는 경우 Proxy 헤더를 빈 문자열로 설정하는 것이 좋습니다:
proxy_set_header Proxy "";
2-3.HTTPoxy 취약점을 악용하려는 시도 탐지하기
Proxy는 표준 HTTP 헤더가 아니므로 이 헤더가 포함된 모든 요청은 의심스러운 것으로 간주할 수 있습니다. NGINX 또는 NGINX Plus를 사용하여 이러한 의심스러운 요청을 전용 Access Log(여기서는 badactor.log
)에 기록할 수 있습니다.
# define 'proxylog' format in the http{} context:
log_format proxylog '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$http_proxy"';
# log requests with a Proxy header using the 'proxylog' format
access_log /var/log/nginx/badactor.log proxylog if=$http_proxy;
Note: 이 access_log 지시문을 배치하는 구성 컨텍스트에서 이 지시문은 NGINX 구성의 상위 수준에서 정의된 모든 Access Log를 재정의합니다.
3. HTTPoxy 결론
NGINX와 NGINX Plus는 HTTPoxy 공격을 효과적으로 모니터링하고 방어할 수 있는 방법을 제공합니다. 위에서 설명한 기술을 사용하여 취약점을 제거하기 위해 코드를 감사, 업데이트 및 테스트하는 동안 애플리케이션을 보호하세요.
NGINX Plus를 직접 사용해 보거나 테스트해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.
댓글을 달려면 로그인해야 합니다.