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

# Nginx

<details>

<summary><strong>제로부터 영웅이 될 때까지 AWS 해킹을 배우세요</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

HackTricks를 지원하는 다른 방법:

* **회사가 HackTricks에 광고되길 원하거나** **PDF 형식의 HackTricks를 다운로드**하려면 [**구독 요금제**](https://github.com/sponsors/carlospolop)를 확인하세요!
* [**공식 PEASS & HackTricks 굿즈**](https://peass.creator-spring.com)를 구매하세요
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)를 발견하세요, 당사의 독점 [**NFTs**](https://opensea.io/collection/the-peass-family) 컬렉션
* **💬 [**Discord 그룹**](https://discord.gg/hRep4RUj7f)에 가입하거나 [**텔레그램 그룹**](https://t.me/peass)에 가입하거나 **트위터** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**를 팔로우**하세요.
* **해킹 트릭을 공유하려면 PR을** [**HackTricks**](https://github.com/carlospolop/hacktricks) **및** [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) **깃허브 저장소에 제출**하세요.

</details>

<figure><img src="../../.gitbook/assets/image (14).png" alt=""><figcaption></figcaption></figure>

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

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

## 누락된 루트 위치 <a href="#missing-root-location" id="missing-root-location"></a>

Nginx 서버를 구성할 때 **root 지시문**은 파일이 제공되는 기본 디렉토리를 정의하여 중요한 역할을 합니다. 아래 예시를 고려하세요:
```bash
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 잘못된 구성 <a href="#alias-lfi-misconfiguration" id="alias-lfi-misconfiguration"></a>

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/](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
```
## 안전하지 않은 경로 제한 <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>

다음 페이지를 확인하여 다음과 같은 지시문을 우회하는 방법을 배우세요:
```plaintext
location = /admin {
deny all;
}

location = /admin/ {
deny all;
}
```
{% content-ref url="../../pentesting-web/proxy-waf-protections-bypass.md" %}
[proxy-waf-protections-bypass.md](../../pentesting-web/proxy-waf-protections-bypass.md)
{% endcontent-ref %}

## 안전하지 않은 변수 사용 / HTTP 요청 분할 <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>

{% 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://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/)에 대해 자세히 알아보세요.

또한 이 기술은 [**이 토크에서 설명됩니다**](https://www.youtube.com/watch?v=gWQyWdZbdoY\&list=PL0xCSYnG\_iTtJe2V6PQqamBF73n7-f1Nr\&index=77) 취약한 예제 및 탐지 메커니즘이 함께 제공됩니다. 예를 들어, 블랙박스 관점에서 이 구성 오류를 감지하려면 다음 요청을 사용할 수 있습니다:

* `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의 보안 보고서에서 강조되었으며 [여기](https://hackerone.com/reports/370094)에서 확인할 수 있습니다. 오류 메시지에 대한 추가 조사를 통해 이 이상현상이 Nginx의 코드베이스의 [SSI 필터 모듈](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx\_http\_ssi\_filter\_module.c#L365) 내에서 발생한다는 것을 확인하였으며, 이는 Server Side Includes (SSI)가 원인임을 밝혔습니다.

**이 구성 오류를 감지**하기 위해 다음 명령을 실행할 수 있습니다. 이 명령은 referer 헤더를 설정하여 변수 출력을 테스트하는 것을 포함합니다:
```bash
$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’
```
시스템 전체에서 이 구성 오류를 스캔한 결과, 여러 경우에서 Nginx 변수가 사용자에 의해 출력될 수 있음을 확인했습니다. 그러나 취약한 인스턴스 수의 감소는 이 문제를 수정하기 위한 노력이 어느 정도 성공했음을 시사합니다.

## 백엔드 응답의 원본 읽기

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

uWSGI 애플리케이션을 사용한 예시 시나리오를 고려해보겠습니다:
```python
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**](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_intercept\_errors): 이 지시문은 Nginx가 상태 코드가 300을 초과하는 백엔드 응답에 대해 사용자 정의 응답을 제공하도록 하는 것입니다. 예를 들어 uWSGI 애플리케이션의 경우 `500 Error` 응답이 Nginx에 의해 가로채지고 처리되도록 합니다.
* [**proxy\_hide\_header**](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#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](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d)를 확인하십시오.

### **Maclicious Response Headers**

[**이 설명서**](https://mizu.re/post/cors-playground)에 표시된대로, 웹 서버에서 응답에 특정 헤더가 포함되어 있으면 Nginx 프록시의 동작이 변경됩니다. 이를 [**문서에서**](https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/) 확인할 수 있습니다:

* `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` 지시문은 종종 **인가 제어**에 역할을 합니다. 일반적인 실수는 **기본** 값을 지정하지 않는 것인데, 이는 미인가된 액세스로 이어질 수 있습니다. 예를 들어:
```yaml
http {
map $uri $mappocallow {
/map-poc/private 0;
/map-poc/secret 0;
/map-poc/public 1;
}
}
```

```yaml
server {
location /map-poc {
if ($mappocallow = 0) {return 403;}
return 200 "Hello. It is private area: $mappocallow";
}
}
```
```markdown
`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 서버를 지정할 수 있습니다:
```
```yaml
resolver 8.8.8.8;
```
### **`proxy_pass` 및 `internal` 지시문**

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

## proxy\_set\_header Upgrade 및 Connection

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

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

[여기](https://bishopfox.com/blog/h2c-smuggling-request)에서 `/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](https://github.com/detectify/vulnerable-nginx)

## 정적 분석 도구

### [GIXY](https://github.com/yandex/gixy)

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

### [Nginxpwner](https://github.com/stark0de/nginxpwner)

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

## 참고 자료

* [**https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/**](https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/)
* [**http://blog.zorinaq.com/nginx-resolver-vulns/**](http://blog.zorinaq.com/nginx-resolver-vulns/)
* [**https://github.com/yandex/gixy/issues/115**](https://github.com/yandex/gixy/issues/115)

<figure><img src="../../.gitbook/assets/image (14).png" alt=""><figcaption></figcaption></figure>

**취약점 평가 및 침투 테스트를 위한 즉시 사용 가능한 설정**. 20개 이상의 도구 및 기능을 사용하여 재해부터 보고서 작성까지 전체 펜테스트를 어디서든 실행하세요. 우리는 펜테스터를 대체하지 않습니다 - 그들이 더 심층적으로 파고들고, 쉘을 열고, 즐길 수 있도록 사용자 정의 도구, 탐지 및 악용 모듈을 개발합니다.

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

<details>

<summary><strong>제로부터 영웅이 될 때까지 AWS 해킹을 배우세요</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

HackTricks를 지원하는 다른 방법:

* **회사를 HackTricks에서 광고하거나 PDF로 다운로드하고 싶다면** [**구독 요금제**](https://github.com/sponsors/carlospolop)를 확인하세요!
* [**공식 PEASS & HackTricks 스웨그**](https://peass.creator-spring.com)를 얻으세요
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)를 발견하세요, 우리의 독점 [**NFTs**](https://opensea.io/collection/the-peass-family) 컬렉션
* **💬 [디스코드 그룹](https://discord.gg/hRep4RUj7f)에 가입하거나 [텔레그램 그룹](https://t.me/peass)에 참여하거나** **트위터** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**를 팔로우하세요.**
* **해킹 트릭을 공유하려면** [**HackTricks**](https://github.com/carlospolop/hacktricks) 및 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github 저장소로 PR을 제출하세요.

</details>