Cloud Metadata Attack 보안 NGINX로 방어


Cloud Metadata Attack 은 클라우드 컴퓨팅 환경에서 발생하는 특정한 유형의 보안 위협입니다. 이런 공격은 공격자가 클라우드 서비스에서 사용하는 메타데이터를 이용하여 시스템의 취약점을 찾고 이를 이용해 민감한 정보를 도출하거나 시스템을 공격하는 것을 의미합니다. 메타데이터는 시스템에 대한 중요한 정보를 제공하기 때문에, 이 정보를 악용하면 시스템 전반의 보안에 심각한 위협을 초래할 수 있습니다. 이러한 위협을 완화하기 위해서는 클라우드 환경에서의 메타데이터 관리와 보안이 중요합니다.

가끔 우리는 NGINX Open Source와 NGINX Plus 사용자가 직면할 수 있는 흥미롭거나 중요한 보안 문제를 강조하고자 합니다. 애플리케이션 스택은 복잡하며, 일반적인 기능이 어떻게 악용될 수 있는 애매하거나 예상치 못한 방법을 간과하기 매우 쉽습니다. NGINX와 NGINX Plus는 이러한 기능에 대한 액세스를 제공하면서 액세스를 제한하는 강력한 방법입니다. 부주의하거나 무의식적인 설정은 공격자를 위한 문을 열어둘 수 있습니다.

이전에는 HTTP 헤더를 이용한 공격에 대해 다루었던 적이 있습니다. HTTPoxy 공격에서는 공격자가 HTTP 프록시 헤더를 이용하여 애플리케이션에서 생성된 내부 HTTP 요청을 캡처하며, Apache Struts 취약점에서는 조작된 Content-Type 헤더를 사용하여 command injection을 수행합니다. 이 두 가지 공격은 모두 애플리케이션 환경에서 잘 알려지지 않은 기능을 악용하며, 의심스러운 요청을 가로채는 방식으로 대응할 수 있습니다.

가장 최근에, 레드락(RedLock)의 Michael Higashi는 특정 구성을 사용하여 일부 클라우드 공급자가 노출한 내부 “인스턴스 메타데이터” API에 액세스하는 공격 방법을 공개했습니다. 다시 한번 말하자면, 잘 알려지지 않은 보안 기능은 교묘한 공격자에게 노출됩니다.

레드락(RedLock)의 기사에서는 NGINX 구성을 예로 들었지만, Reverse Proxy 서비스를 운영하는 모든 사용자들은 이 공격 방법과 사용자 입력을 믿는 것이 가져올 수 있는 일반적인 의미를 알고 있어야 합니다.

목차

1. 과도하게 권한이 있는 프록시 만드는 방법
2. Cloud Metadata Attack의 특성
3. Cloud Metadata Attack 차단
4. 결론

1. 과도하게 권한이 있는 프록시 만드는 방법

문제의 핵심은 NGINX 및 NGINX Plus에 대한 다음과 같은 프록시 서버에서 허술한 구성이 있다는 것입니다.

# 절대 이렇게 'proxy_pass'를 사용하지 마세요!
location / {
    proxy_pass http://$host; # 반복: 이렇게  구성하지 마세요!
}

이 간단한 구성은 HTTP 요청을 처리하고, HTTP 요청의 Host 헤더에서 식별된 서버($host 변수로 캡처됨)로 전달합니다. 이것은 HTTP reverse proxy를 생성하는 매우 쉬운 방법이지만, 이는 일반적인 forward proxy로도 사용할 수 있습니다.

이러한 구성은 악용당할 가능성이 상당합니다. 원격 사용자는 이 구성을 사용하여 Host 헤더에 지정한 임의의 서버에 대해 NGINX에게 HTTP 요청을 보내도록 요청할 수 있습니다. NGINX는 결과를 사용자에게 Return합니다. 만약 NGINX가 DMZ와 같은 권한 위치에서 실행 중이면, 원격 사용자는 직접 액세스할 수 없는 서버에 액세스할 수 있게 됩니다.

이 forward-proxy 구성은 요청의 Source IP 주소를 숨기는 데 사용할 수 있습니다. 이를 통해 사용자는 요청이 NGINX 서버에서 발생한 것으로 보이도록 하면서 원격 서비스에 액세스 할 수 있습니다.

2. Cloud Metadata Attack의 특성

일부 클라우드 제공 업체들은 가상 머신에서 실행 중인 서비스가 “인스턴스 메타데이터”를 조회할 수 있는 서비스(API)를 제공합니다. 이 인스턴스 메타데이터는 인증 자격 증명과 같은 민감한 데이터를 포함할 수 있습니다.

이러한 서비스의 위험성은 다른 곳에서 이미 논의되었습니다. 클라우드 가상 머신 내에서 실행되는 모든 프로세스는 API에 액세스하여 민감한 데이터를 검색하고 저장할 수 있습니다. 그러나 이러한 메타데이터 서비스를 라우팅할 수 없는 내부 IP 주소(위에서 언급한 제공 업체들은 모두 169.254.169.254를 사용)로 공개함으로써, 제공 업체들은 이러한 서비스가 외부로부터 안전하다고 가정했습니다.

실제로, 지나치게 권한이 부여된 프록시 구성으로 인해 AWS API를 사용한 이 예에서와같이 내부 IP 주소에 쉽게 액세스할 수 있습니다.

$ curl http://remote-ip-address/latest/meta-data/ -H "Host: 169.154.169.254"
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
iam/
instance-action
instance-id
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/

RedLock은 “팀이 이러한 프록시를 찾는 데 사용할 수 있는 작은 스크립트를 작성하고, 그 결과 수십 개의 취약한 서버를 찾았다.” 라고 설명했습니다.

3. Cloud Metadata Attack 차단

NGINX팀의 간단한 조언은 “Don’t do this!” 입니다. Host 헤더에 지정된 서버로 요청을 프록시하는 것(proxy_pass http://$host)은 사용자의 입력을 지나치게 신뢰하는 대표적인 예시이며, 범하기 쉬운 실수입니다.

NGINX는 일반적인 Forward Proxy로 설계되지 않았습니다. 이러한 종류의 구성을 보호하는 것은 어려운 일입니다.

저희의 조언은 미리 선택한 알려진 upstream 서버로만 프록시 트래픽을 전달하는 것입니다. 가장 안전한 방법은 IP주소나 DNS 이름으로 서버를 식별하는 것입니다. 이것은 proxy_pass 지시문의 인수로 직접 입력하거나 트래픽이 전달되는 명명된 upstream 블록의 server 지시문에 입력할 수 있습니다. 정적 DNS 이름을 사용하는 경우, 공격자가 임의의 IP주소를 삽입하여 DNS 확인 프로세스를 위조하지 못하도록 보호해야 합니다.

4. 결론

봇(Bot) 트래픽의 추정치는 인터넷 HTTP 트래픽의 40%에서 50% 이상까지 다양합니다. Disitil Networks(NGINX를 사용하여 고객을 악성 봇으로부터 보호하는 회사)는 인터넷 트래픽의 20% 이상이 ‘나쁜 봇(Bad Bot)’에서 발생하며, 이들 중 일부는 취약한 시스템을 찾기 위한 스캐너 및 정찰 도구라고 보고합니다.

NGINX는 여러분을 도와드리겠습니다. NGINX Plus는 가장 많은 테스트를 거친 NGINX 릴리스이며, NGINX의 전문 서비스팀은 세계적인 웹 사이트 및 브랜드를 위한 NGINX Plus 구성 보안에서 많은 경험을 보유하고 있습니다. 도움이 필요하시다면 언제든지 연락해주십시오.

NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.

사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.