hacktricks/network-services-pentesting/pentesting-web/nginx.md

Nginx

htARTE (HackTricks AWS Red Team 전문가)로부터 AWS 해킹을 처음부터 전문가까지 배우세요!

HackTricks를 지원하는 다른 방법:

• 회사가 HackTricks에 광고되길 원하거나 HackTricks를 PDF로 다운로드하고 싶다면 구독 요금제를 확인하세요!
• 공식 PEASS & HackTricks 스왜그를 구매하세요
• The PEASS Family를 발견하세요, 당사의 독점 NFTs 컬렉션
• 💬 Discord 그룹 또는 텔레그램 그룹에 가입하거나 트위터 🐦 @carlospolopm을 팔로우하세요.
• 해킹 요령을 공유하고 싶다면 HackTricks 및 HackTricks Cloud github 저장소에 PR을 제출하세요.

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

{% embed url="https://pentest-tools.com/" %}

Missing root location

Nginx 루트 디렉토리 구성의 기본 사항

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" 지시문을 면밀히 검토해야 합니다. Local File Inclusion (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;
}

{% content-ref url="../../pentesting-web/proxy-waf-protections-bypass.md" %} proxy-waf-protections-bypass.md {% endcontent-ref %}

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

{% hint style="danger" %} 취약한 변수 $uri 와 $document_uri 는 $request_uri로 대체하여 해결할 수 있습니다.

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

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

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

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

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 Error 응답이 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를 확인하십시오.

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";
}
}

Without a `default`, a **악의적 사용자** can bypass security by accessing an **undefined URI** within `/map-poc`. [The Nginx manual](https://nginx.org/en/docs/http/ngx\_http\_map\_module.html) advises setting a **default value** to avoid such issues.

### **DNS Spoofing Vulnerability**

DNS spoofing against Nginx is feasible under certain conditions. If an attacker knows the **DNS server** used by Nginx and can intercept its DNS queries, they can spoof DNS records. This method, however, is ineffective if Nginx is configured to use **localhost (127.0.0.1)** for DNS resolution. Nginx allows specifying a DNS server as follows:

resolver 8.8.8.8;

proxy_pass 및 internal 지시문

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

proxy_set_header Upgrade 및 Connection

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

{% hint style="danger" %} 이 취약점을 통해 공격자는 proxy_pass 엔드포인트(http://backend:9999 이 경우)와 직접 연결을 설정할 수 있으며, 해당 내용은 nginx에서 확인되지 않을 것입니다. {% endhint %}

여기에서 /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;
}

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

직접 시도해보세요

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

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

정적 분석 도구

GIXY

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

Nginxpwner

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

참고 자료

• https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/
• http://blog.zorinaq.com/nginx-resolver-vulns/
• https://github.com/yandex/gixy/issues/115

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

{% embed url="https://pentest-tools.com/" %}

제로부터 AWS 해킹을 전문가로 학습하세요 htARTE (HackTricks AWS Red Team Expert)와 함께!

HackTricks를 지원하는 다른 방법:

• 회사를 HackTricks에서 광고하거나 HackTricks를 PDF로 다운로드하려면 구독 요금제를 확인하세요!
• 공식 PEASS & HackTricks 스왜그를 얻으세요
• The PEASS Family를 발견하세요, 저희의 독점 NFTs 컬렉션
• 💬 디스코드 그룹에 가입하거나 텔레그램 그룹에 가입하거나 트위터 🐦 @carlospolopm를 팔로우하세요.
• HackTricks 및 HackTricks Cloud 깃허브 저장소에 PR을 제출하여 해킹 트릭을 공유하세요.