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 요청 매개변수를 기반으로 환경 변수를 설정하고, 이는 애플리케이션을 구성하는 데 사용되는 내부 변수를 재정의할 수 있습니다.

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

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다음과 같이 요청의 헤더를 결정할 수 있습니다.

// both methods return the same result$useragent = getenv( 'HTTP_USER_AGENT' );
$useragent = $_SERVER['HTTP_USER_AGENT'];

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

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

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

3 – 취약성의 특성

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

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

공격자는 헤더가 있는 요청을 보내면 이를 수행할 수 있으며 Proxy, CGI 또는 FastCGI 인터페이스는 HTTP_PROXY해당 애플리케이션 호출에 대해 명명된 환경 변수를 순종적으로 생성합니다. 가짜 Proxy헤더가 포함된 요청만 직접 영향을 받는다는 점에 유의하세요.

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

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

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

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

fastcgi_param HTTP_PROXY "";

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

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

proxy_set_header Proxy "";

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

Proxy표준 HTTP 헤더가 아니므 로 이 헤더를 포함하는 모든 요청은 의심스러운 것으로 간주될 수 있습니다. NGINX 또는 NGINX Plus를 사용하여 이러한 의심스러운 요청을 전용 액세스 로그에 기록할 수 있으며, 여기서는 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;

참고 : 이 지시문을 배치하는 구성 컨텍스트에서는 access_logNGINX 구성의 상위 수준에서 정의된 모든 액세스 로깅이 재정의됩니다.

결론

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