NGINX를 사용하여 HTTPoxy 취약점 완화

2016년 7월 18일, 'HTTPoxy'라는 취약점이 발표되었으며, 이는 일부 FastCGI 구성과 같이 CGI 또는 CGI와 유사한 환경에서 실행되는 일부 서버 측 웹 애플리케이션에 영향을 미칩니다. 지금까지 영향을 받은 것으로 알려진 언어로는 PHP, Python, Go가 있습니다.

특정 언어와 CGI 구현을 포괄하는 여러 CVE가 할당되었습니다.

• 아파치 HTTP 서버 (CVE-2016-5387)
• 아파치 톰캣 (CVE-2016-5388)
• 이동 (CVE-2016-5386)
• PHP (CVE-2016-5385)

취약점을 설명하는 새로운 웹사이트 , CERT 취약점 참고 사항 , 취약점 발견 에 대한 설명이 있습니다. Vend의 오픈소스 웹 개발자인 Dominic Scheirlinck 의 개인 웹사이트에서 추가 정보를 확인할 수 있습니다.

이 게시물에서는 취약점을 설명하고 NGINX 또는 NGINX Plus를 사용하여 서버에서 이 취약점을 악용하려는 시도를 막는 방법을 설명합니다.

이 취약점은 네임스페이스 충돌로 인해 존재합니다. CGI 또는 FastCGI와 같은 인터페이스는 HTTP 요청 매개변수를 기반으로 환경 변수를 설정하고, 이러한 환경 변수는 애플리케이션을 구성하는 데 사용되는 내부 변수를 재정의할 수 있습니다.

현재 이 취약점을 악용하는 것으로 알려진 유일한 사례는 CGI 및 CGI와 유사한 환경에서 실행되는 웹 애플리케이션으로, 특정 HTTP 클라이언트 라이브러리를 사용하여 다른 서비스에 HTTP 요청을 하는 것입니다. 이 경우 공격자는 애플리케이션에서 생성된 내부 요청을 원하는 서버로 리디렉션하여 요청에 포함된 비밀 데이터를 캡처할 수 있습니다(아래 참조).

NGINX 또는 NGINX Plus를 사용하면 이 취약점을 악용하려는 시도를 식별하고 차단할 수 있습니다. 그렇게 하면 모든 공격을 효과적으로 방지하고, 영향을 받은 모든 코드를 감사하고 업데이트할 시간을 확보할 수 있습니다.

HTTPoxy 취약점이 악용되는 방법

이 취약점이 작동하는 방식과 사이트를 이 취약점으로부터 보호하는 방법을 이해하려면 CGI 및 CGI 유사 인터페이스가 환경 변수를 설정하는 방식과 일부 애플리케이션 라이브러리가 환경 변수에 의해 구성되는 방식을 이해해야 합니다.

1 – CGI 및 CGI 유사 인터페이스는 HTTP_*라는 이름의 환경 변수를 정의합니다.

많은 웹 애플리케이션 플랫폼은 CGI 또는 CGI와 유사한 인터페이스를 사용하여 애플리케이션을 웹 서버에 연결합니다. 이러한 인터페이스는 HTTP 요청의 헤더를 HTTP_ 접두사가 붙은 환경 변수로 변환합니다. 그러면 애플리케이션은 환경을 검사하여 요청 헤더(예: User-Agent )의 값을 조회할 수 있습니다.

클라이언트는 적절한 헤더와 함께 요청을 전송하여 애플리케이션 환경에서 임의의 환경 변수( HTTP_ 로 시작)를 생성할 수 있습니다. 예를 들어, 요청 헤더 Foo: bar 는 환경 변수 HTTP_FOO=bar 가 됩니다.

일부 플랫폼은 PHP의 $_SERVER 전역 변수와 같은 환경 변수를 숨기는 추상화 계층을 제공합니다. 그럼에도 불구하고, 이러한 추상화는 환경 변수를 설정하는 표준 CGI 및 FastCGI 관행을 기반으로 구축되었습니다.

예를 들어, FastCGI 모드에서 실행할 때 PHP 애플리케이션은 다음과 같이 요청의 User-Agent 헤더를 결정할 수 있습니다.

// 두 메서드 모두 동일한 결과를 반환합니다.$useragent = getenv( 'HTTP_USER_AGENT' );
$useragent = $_SERVER['HTTP_USER_AGENT'];

2 – 일부 애플리케이션 라이브러리는 환경 변수에서 구성됩니다.

복잡한 웹 애플리케이션은 외부 라이브러리에서 기능을 가져옵니다. 예를 들어, 때때로 애플리케이션은 다른 서비스에 HTTP 요청을 해야 하며(마이크로서비스와 유사한 방식으로) 이를 위해 일반적인 타사 라이브러리 중 하나를 사용할 수 있습니다. 이러한 라이브러리는 종종 HTTP 프록시 라는 기능을 지원하는데, 이는 HTTP 요청을 전달하는 데 사용되는 중개 서버입니다.

이와 같이 라이브러리를 구성하는 쉬운 방법 중 하나는 환경 변수를 통해 구성을 정의하는 것입니다. 널리 사용되는 PHP Guzzle 라이브러리는 HTTP_PROXY 라는 환경 변수에 의해 부분적으로 구성되며, 이 변수는 프록시 서버의 주소로 설정됩니다. HTTP_PROXY가 이런 식으로 설정되면 라이브러리는 생성된 모든 HTTP 요청을 프록시 서버의 주소로 전달합니다. Go의 net/http 패키지와 Python의 Requests 모듈도 HTTP_PROXY 환경 변수를 같은 방식으로 신뢰하고 해석합니다.

3 – 취약점의 특성

항목 2에 설명된 라이브러리는 CGI 또는 CGI와 유사한 인터페이스를 염두에 두고 설계되지 않았으며, 이들이 신뢰하는 HTTP_PROXY 환경 변수는 항목 1에서 설명한 CGI 및 FastCGI 인터페이스에서 사용하는 HTTP_ 네임스페이스와 겹칩니다.

공격자는 HTTP_PROXY 환경 변수의 값을 원하는 주소로 설정하여 애플리케이션에서 생성된 내부 HTTP 요청을 리디렉션하고 캡처할 수 있습니다. 이러한 요청에는 인증 키, 개인 데이터와 같은 민감한 정보가 포함될 수 있으며, 악용될 수 있는 추가 API 및 엔드포인트에 대한 정보가 공개될 수도 있습니다.

공격자는 프록시 헤더가 포함된 요청을 보내면 CGI나 FastCGI 인터페이스가 해당 애플리케이션 호출에 대해 HTTP_PROXY 라는 환경 변수를 자동으로 생성합니다. 가짜 프록시 헤더를 포함하는 요청만 직접적으로 영향을 받습니다.

NGINX 및 NGINX Plus를 사용하여 공격 물리치기

HTTPoxy 취약점은 NGINX에 직접적인 영향을 미치지 않지만 NGINX 및 NGINX Plus를 사용하면 이 취약점을 이용한 공격을 차단할 수 있습니다.

업스트림 FastCGI 애플리케이션과 통신

NGINX를 사용하여 HTTP_PROXY FastCGI 매개변수를 빈 문자열로 설정하여 애플리케이션의 입력을 "정리"할 수 있습니다. 이렇게 하면 FastCGI 요청에서 매개변수가 완전히 제거됩니다.

fastcgi_param HTTP_PROXY "";

HTTP 트래픽 로드 밸런싱 및 프록시

HTTP 요청을 업스트림 애플리케이션으로 프록시할 때, 업스트림 애플리케이션이 취약한 플랫폼에서 실행되는 경우를 대비해 모든 Proxy 헤더를 빈 문자열로 설정하는 것이 좋습니다.

proxy_set_header 프록시 "";

취약점을 악용하려는 시도 감지

프록시 는 표준 HTTP 헤더가 아니므로 이 헤더가 포함된 모든 요청은 의심스러운 것으로 간주될 수 있습니다. NGINX 또는 NGINX Plus를 사용하면 이러한 의심스러운 요청을 badactor.log 라는 이름의 전용 액세스 로그에 기록할 수 있습니다.

# http{} 컨텍스트에서 'proxylog' 형식을 정의합니다:log_format proxylog '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$http_proxy"';

# 'proxylog' 형식을 사용하여 프록시 헤더로 요청을 기록합니다.
access_log /var/log/nginx/badactor.log proxylog if=$http_proxy;

메모 : 이 access_log 지시문을 배치하는 구성 컨텍스트에서 해당 지시문은 NGINX 구성의 상위 수준에서 정의된 모든 액세스 로깅을 재정의합니다.

안전히 계세요

NGINX와 NGINX Plus는 HTTPoxy 공격을 모니터링하고 차단하는 효과적인 방법을 제공합니다. 위에서 설명한 기술을 사용하여 코드를 감사, 업데이트, 테스트하여 취약점을 제거하는 동안 애플리케이션을 보호하세요.

궁금한 점이 있으면 이 게시물에 댓글을 남겨주세요. NGINX Plus 구독자이신 경우 지원팀 에 문의해 주시기 바랍니다.