Korean - Ht
HackTricks Training Twitter Linkedin Sponsor

Nginx

htARTE (HackTricks AWS Red Team 전문가)로부터 제로에서 영웅까지 AWS 해킹 배우기

HackTricks를 지원하는 다른 방법:

어디서나 실행 가능한 취약점 평가 및 침투 테스트 설정. 20개 이상의 도구 및 기능을 사용하여 recon부터 보고서 작성까지 전체 펜테스트를 실행하세요. 우리는 펜테스터를 대체하지 않습니다 - 우리는 사용자 정의 도구, 탐지 및 공격 모듈을 개발하여 그들에게 더 많은 시간을 깊이 파고들고 쉘을 열고 즐기도록 도와줍니다.

누락된 루트 위치

Nginx 서버를 구성할 때 root 지시문은 파일이 제공되는 기본 디렉토리를 정의하여 중요한 역할을 합니다. 아래 예시를 고려하세요:

server {
root /etc/nginx;

location /hello.txt {
try_files $uri $uri/ =404;
proxy_pass http://127.0.0.1:8080/;
}
}

이 구성에서 /etc/nginx가 루트 디렉토리로 지정되었습니다. 이 설정은 /hello.txt와 같은 지정된 루트 디렉토리 내의 파일에 액세스할 수 있도록 합니다. 그러나 특정 위치(/hello.txt)만 정의되어 있습니다. 루트 위치(location / {...})에 대한 구성이 없다는 점을 주목하는 것이 중요합니다. 이 누락으로 인해 루트 지시문이 전역적으로 적용되어 / 경로에 대한 요청이 /etc/nginx 아래의 파일에 액세스할 수 있게 됩니다.

이 구성에서 발생하는 중요한 보안 고려 사항이 있습니다. /nginx.conf와 같은 간단한 GET 요청은 /etc/nginx/nginx.conf에 위치한 Nginx 구성 파일을 제공함으로써 민감한 정보를 노출시킬 수 있습니다. 루트를 /etc와 같이 민감하지 않은 디렉토리로 설정하면 이 위험을 완화할 수 있지만, 여전히 다른 중요한 파일(다른 구성 파일, 액세스 로그, 심지어 HTTP 기본 인증에 사용되는 암호화된 자격 증명)에 부정한 액세스를 허용할 수 있습니다.

별칭 LFI 잘못된 구성

Nginx의 구성 파일에서 "location" 지시문에 대해 면밀히 검토해야 합니다. "로컬 파일 포함(LFI)"이라고 알려진 취약점은 다음과 유사한 구성을 통해 부주의하게 도입될 수 있습니다:

location /imgs {
alias /path/images/;
}

이 구성은 /imgs../flag.txt와 같은 요청을 서버가 의도된 디렉토리 외부의 파일에 액세스하려는 시도로 해석하여 /path/images/../flag.txt로 해석하기 때문에 LFI 공격에 취약합니다. 이 결함으로 인해 공격자는 웹을 통해 액세스해서는 안 되는 서버 파일을 검색할 수 있습니다.

이 취약점을 완화하기 위해 구성을 다음과 같이 조정해야 합니다:

location /imgs/ {
alias /path/images/;
}

더 많은 정보: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/

Accunetix 테스트:

alias../ => HTTP status code 403
alias.../ => HTTP status code 404
alias../../ => HTTP status code 403
alias../../../../../../../../../../../ => HTTP status code 400
alias../ => HTTP status code 403

안전하지 않은 경로 제한

다음 페이지를 확인하여 다음과 같은 지시문을 우회하는 방법을 배우세요:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}
pageProxy / WAF Protections Bypass

안전하지 않은 변수 사용 / HTTP 요청 분할

취약한 변수 $uri 및 $document_uri를 사용하고 있으며, 이는 $request_uri로 대체하여 해결할 수 있습니다.

정규식도 취약할 수 있습니다:

location ~ /docs/([^/])? { … $1 … } - 취약함

location ~ /docs/([^/\s])? { … $1 … } - 취약하지 않음 (공백 확인)

location ~ /docs/(.*)? { … $1 … } - 취약하지 않음

Nginx 구성에서의 취약점은 아래 예제로 설명됩니다:

location / {
return 302 https://example.com$uri;
}

HTTP 요청에서 \r (복귀) 및 \n (개행) 문자는 새 줄 문자를 나타내며, URL 인코딩된 형식은 %0d%0a로 표시됩니다. 이러한 문자를 요청에 포함시키면 (예: http://localhost/%0d%0aDetectify:%20clrf), 설정이 잘못된 서버에서 Detectify라는 새 헤더가 발급됩니다. 이는 $uri 변수가 URL 인코딩된 새 줄 문자를 디코딩하기 때문에 응답에서 예상치 못한 헤더가 생성되기 때문에 발생합니다:

HTTP/1.1 302 Moved Temporarily
Server: nginx/1.19.3
Content-Type: text/html
Content-Length: 145
Connection: keep-alive
Location: https://example.com/
Detectify: clrf

CRLF 주입 및 응답 분할의 위험에 대해 자세히 알아보세요.

또한 이 기술은 이 토크에서 설명됩니다 취약한 예와 탐지 메커니즘을 포함하여. 예를 들어, 블랙박스 관점에서 이 구성 오류를 감지하려면 다음 요청을 사용할 수 있습니다:

  • https://example.com/%20X - 임의의 HTTP 코드

  • https://example.com/%20H - 400 Bad Request

취약하다면, 첫 번째는 "X"가 임의의 HTTP 메서드이기 때문에 반환되고 두 번째는 H가 유효한 메서드가 아니기 때문에 오류가 발생합니다. 따라서 서버는 다음과 같은 내용을 수신하게 됩니다: GET / H HTTP/1.1 이는 오류를 발생시킵니다.

다른 감지 예시는 다음과 같습니다:

  • http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x - 임의의 HTTP 코드

  • http://company.tld/%20HTTP/1.1%0D%0AHost:%20x - 400 Bad Request

해당 토크에서 발견된 취약한 구성 사례는 다음과 같습니다:

  • **$uri**가 최종 URL에 그대로 설정되어 있는 것에 주목하세요

location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}

  • 다시 한 번 URL에 **$uri**가 있는지 주목하세요 (이번에는 매개변수 내부에 있습니다)

location ~ ^/dna/payment {
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
proxy_pass http://$back;

  • 이제 AWS S3에서

location /s3/ {
proxy_pass https://company-bucket.s3.amazonaws.com$uri;
}

임의 변수

특정 상황에서 사용자 제공 데이터가 Nginx 변수로 처리될 수 있다는 것이 발견되었습니다. 이러한 동작의 원인은 다소 애매하지만 드물거나 간단히 확인할 수 없는 것은 아닙니다. 이 이상현상은 HackerOne의 보안 보고서에서 강조되었으며 여기에서 확인할 수 있습니다. 오류 메시지에 대한 추가 조사를 통해 이러한 현상이 Nginx의 코드베이스 중 SSI 필터 모듈 내에서 발생한다는 것을 확인하여 Server Side Includes (SSI)를 근본 원인으로 확인했습니다.

이 구성 오류를 감지하기 위해 다음 명령을 실행할 수 있습니다. 이 명령은 referer 헤더를 설정하여 변수 출력을 테스트하는 것을 포함합니다:

$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’

시스템 전체에서 이 구성 오류에 대한 스캔 결과, Nginx 변수가 사용자에 의해 출력될 수 있는 여러 인스턴스가 발견되었습니다. 그러나 취약한 인스턴스 수의 감소는 이 문제를 수정하기 위한 노력이 어느 정도 성공적이었음을 시사합니다.

백엔드 응답의 원시 데이터 읽기

Nginx는 proxy_pass를 통해 백엔드에서 생성된 오류 및 HTTP 헤더를 가로챌 수 있는 기능을 제공하며, 내부 오류 메시지와 헤더를 숨기려고 합니다. 이는 Nginx가 백엔드 오류에 대한 응답으로 사용자 정의 오류 페이지를 제공함으로써 달성됩니다. 그러나 Nginx가 잘못된 HTTP 요청을 만나면 도전이 발생합니다. 이러한 요청은 받은 대로 백엔드로 전달되고, 백엔드의 원시 응답이 Nginx의 개입 없이 직접 클라이언트로 전송됩니다.

uWSGI 애플리케이션을 사용한 예시 시나리오를 고려해보겠습니다:

def application(environ, start_response):
start_response('500 Error', [('Content-Type', 'text/html'), ('Secret-Header', 'secret-info')])
return [b"Secret info, should not be visible!"]

다음을 관리하기 위해 Nginx 구성에서 특정 지시문이 사용됩니다:

http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}

  • proxy_intercept_errors: 이 지시문은 Nginx가 상태 코드가 300을 초과하는 백엔드 응답에 대해 사용자 정의 응답을 제공하도록 하는 것입니다. 예를 들어 uWSGI 애플리케이션의 경우 500 오류 응답이 Nginx에 의해 가로채지고 처리되도록 합니다.

  • proxy_hide_header: 이름에서 알 수 있듯이, 이 지시문은 특정 HTTP 헤더를 클라이언트로부터 숨겨 개인 정보 보호와 보안을 강화합니다.

유효한 GET 요청이 수신되면 Nginx는 일반적으로 처리하여 비밀 헤더를 노출하지 않는 표준 오류 응답을 반환합니다. 그러나 잘못된 HTTP 요청은 이 메커니즘을 우회하여 비밀 헤더와 오류 메시지를 포함한 원시 백엔드 응답이 노출됩니다.

merge_slashes set to off

기본적으로 Nginx의 merge_slashes 지시문은 **on**으로 설정되어 있어 URL에서 여러 슬래시를 단일 슬래시로 압축합니다. 이 기능은 URL 처리를 간소화하지만 특히 Nginx 뒤의 애플리케이션에서 로컬 파일 포함 (LFI) 공격에 취약한 경우에는 취약점을 숨길 수 있습니다. 보안 전문가 Danny Robinson과 Rotem Bar는 특히 Nginx가 리버스 프록시로 작동할 때 이러한 기본 동작과 관련된 잠재적인 위험성을 강조했습니다.

이러한 위험을 완화하기 위해 이러한 취약점에 취약한 애플리케이션에 대해 merge_slashes 지시문을 끄는 것이 권장됩니다. 이렇게 하면 Nginx가 URL 구조를 변경하지 않고 요청을 애플리케이션으로 전달하여 기존의 보안 문제를 숨기지 않습니다.

자세한 내용은 Danny Robinson and Rotem Bar를 확인하십시오.

Maclicious Response Headers

이 설명서에 표시된대로, 웹 서버의 응답에 특정 헤더가 포함되어 있으면 Nginx 프록시의 동작이 변경됩니다. 이를 문서에서 확인할 수 있습니다:

  • X-Accel-Redirect: Nginx에게 요청을 지정된 위치로 내부적으로 리디렉션하도록 지시합니다.

  • X-Accel-Buffering: Nginx가 응답을 버퍼링해야 하는지 여부를 제어합니다.

  • X-Accel-Charset: X-Accel-Redirect를 사용할 때 응답의 문자 집합을 설정합니다.

  • X-Accel-Expires: X-Accel-Redirect를 사용할 때 응답의 만료 시간을 설정합니다.

  • X-Accel-Limit-Rate: X-Accel-Redirect를 사용할 때 응답의 전송 속도를 제한합니다.

예를 들어, X-Accel-Redirect 헤더는 Nginx에서 내부 리디렉션을 발생시킵니다. 따라서 **root /**와 같은 nginx 구성 및 웹 서버의 응답에 **X-Accel-Redirect: .env**가 포함되어 있으면 nginx가 **/.env**의 내용을 보냅니다 (경로 탐색).

Map 지시문의 기본 값

Nginx 구성에서 map 지시문은 종종 인가 제어에 역할을 합니다. 일반적인 실수는 기본 값을 지정하지 않는 것인데, 이는 미인가된 액세스로 이어질 수 있습니다. 예를 들어:

http {
map $uri $mappocallow {
/map-poc/private 0;
/map-poc/secret 0;
/map-poc/public 1;
}
}
server {
location /map-poc {
if ($mappocallow = 0) {return 403;}
return 200 "Hello. It is private area: $mappocallow";
}
}
`default`가 없으면 **악의적 사용자**가 `/map-poc` 내의 **정의되지 않은 URI**에 액세스하여 보안을 우회할 수 있습니다. [Nginx 매뉴얼](https://nginx.org/en/docs/http/ngx_http_map_module.html)은 이러한 문제를 피하기 위해 **기본값**을 설정하는 것을 권장합니다.

### **DNS Spoofing 취약점**

일부 조건에서 Nginx에 대한 DNS 스푸핑이 가능합니다. 공격자가 Nginx가 사용하는 **DNS 서버**를 알고 있고 해당 DNS 쿼리를 가로챌 수 있다면 DNS 레코드를 스푸핑할 수 있습니다. 그러나 Nginx가 DNS 해결을 위해 **localhost (127.0.0.1)**를 사용하도록 구성된 경우 이 방법은 효과가 없습니다. Nginx는 다음과 같이 DNS 서버를 지정할 수 있습니다:
resolver 8.8.8.8;

proxy_pass 및 internal 지시문

proxy_pass 지시문은 요청을 다른 서버로 리디렉션하는 데 사용됩니다. 내부적으로든 외부적으로든 다른 서버로 요청을 보낼 수 있습니다. internal 지시문은 특정 위치가 Nginx 내에서만 접근 가능하도록 보장합니다. 이러한 지시문 자체로는 취약점이 아니지만, 그 구성은 보안 결함을 방지하기 위해 신중히 조사되어야 합니다.

proxy_set_header Upgrade 및 Connection

만약 nginx 서버가 Upgrade 및 Connection 헤더를 전달하도록 구성되어 있다면 h2c 스머글링 공격이 수행되어 보호된/내부 엔드포인트에 액세스할 수 있습니다.

이 취약점은 공격자가 proxy_pass 엔드포인트(http://backend:9999인 경우)와 직접 연결을 설정할 수 있게 해줍니다. 이 경우 nginx에서 확인되지 않을 내용이 포함될 수 있습니다.

여기에서 /flag를 탈취하기 위한 취약한 구성 예시:

server {
listen       443 ssl;
server_name  localhost;

ssl_certificate       /usr/local/nginx/conf/cert.pem;
ssl_certificate_key   /usr/local/nginx/conf/privkey.pem;

location / {
proxy_pass http://backend:9999;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
}

location /flag {
deny all;
}

proxy_pass가 특정 경로를 가리키고 있더라도(http://backend:9999/socket.io와 같은) 연결은 http://backend:9999로 설정되므로 해당 내부 엔드포인트 내의 다른 경로에 연락할 수 있습니다. 따라서 proxy_pass의 URL에 경로가 지정되어 있더라도 상관없습니다.

직접 시도해보세요

Detectify는 이 기사에서 논의된 몇 가지 구성 오류가 있는 취약한 Nginx 테스트 서버를 설정할 수 있는 Docker를 사용할 수 있는 GitHub 저장소를 만들었습니다. 이를 통해 스스로 문제를 찾아보세요!

https://github.com/detectify/vulnerable-nginx

정적 분석 도구

GIXY

Gixy는 Nginx 구성을 분석하는 도구입니다. Gixy의 주요 목표는 보안 구성 오류를 방지하고 결함 탐지를 자동화하는 것입니다.

Nginxpwner

Nginxpwner는 일반적인 Nginx 구성 오류와 취약점을 찾기 위한 간단한 도구입니다.

참고 자료

취약성 평가 및 침투 테스트를 위한 즉시 사용 가능한 설정. 20개 이상의 도구 및 기능을 통해 리콘부터 보고서 작성까지 전체 펜테스트를 어디서든 실행하세요. 우리는 펜테스터를 대체하지 않습니다 - 깊이 파고들고 쉘을 열고 즐기기 위해 사용자 정의 도구, 탐지 및 공격 모듈을 개발합니다.

제로부터 AWS 해킹 전문가가 되기 위한 방법을 배우세요 htARTE (HackTricks AWS Red Team Expert)!

HackTricks를 지원하는 다른 방법:

PreviousMoodleNextPHP Tricks

Last updated