Nginx
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
あなたのウェブアプリ、ネットワーク、クラウドに対するハッカーの視点を得る
実際のビジネスに影響を与える重大で悪用可能な脆弱性を見つけて報告します。 攻撃面をマッピングし、特権を昇格させるセキュリティ問題を見つけ、重要な証拠を収集するために自動化されたエクスプロイトを使用して、あなたの努力を説得力のある報告書に変えるために、20以上のカスタムツールを使用してください。
Nginxサーバーを構成する際、rootディレクティブは、ファイルが提供される基本ディレクトリを定義する重要な役割を果たします。以下の例を考えてみてください:
この構成では、/etc/nginx がルートディレクトリとして指定されています。この設定により、/hello.txt のような指定されたルートディレクトリ内のファイルにアクセスできます。しかし、特定の場所（/hello.txt）のみが定義されていることに注意することが重要です。ルートの場所（location / {...}）に関する設定はありません。この省略により、ルートディレクティブはグローバルに適用され、ルートパス / へのリクエストが /etc/nginx の下のファイルにアクセスできるようになります。
この構成から生じる重要なセキュリティ上の考慮事項があります。GET /nginx.conf のような単純な GET リクエストは、/etc/nginx/nginx.conf にある Nginx 設定ファイルを提供することで、機密情報を露出させる可能性があります。ルートを /etc のようなあまり機密性の高くないディレクトリに設定することで、このリスクを軽減できますが、それでも他の重要なファイル、他の設定ファイル、アクセスログ、さらには HTTP ベーシック認証に使用される暗号化された資格情報への意図しないアクセスを許可する可能性があります。
Nginx の設定ファイルでは、「location」ディレクティブを注意深く検査する必要があります。Local File Inclusion (LFI) として知られる脆弱性は、次のような構成を通じて意図せず導入される可能性があります：
この設定は、サーバーが /imgs../flag.txt のようなリクエストを意図しないディレクトリの外にあるファイルにアクセスしようとする試みとして解釈するため、LFI攻撃に対して脆弱です。これは実際には /path/images/../flag.txt に解決されます。この欠陥により、攻撃者はウェブを介してアクセスできるべきではないサーバーのファイルシステムからファイルを取得できます。
この脆弱性を軽減するために、設定を次のように調整する必要があります:
More info: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/
Accunetix テスト:
次のページを確認して、次のようなディレクティブをバイパスする方法を学んでください:
脆弱な変数 $uri と $document_uri は、 $request_uri に置き換えることで修正できます。
正規表現も脆弱である可能性があります：
location ~ /docs/([^/])? { … $1 … } - 脆弱
location ~ /docs/([^/\s])? { … $1 … } - 脆弱でない（スペースをチェック）
location ~ /docs/(.*)? { … $1 … } - 脆弱でない
Nginx構成の脆弱性は、以下の例で示されています：
HTTPリクエストにおいて、文字 \r (キャリッジリターン) と \n (ラインフィード) は新しい行の文字を示し、そのURLエンコード形式は %0d%0a として表されます。これらの文字をリクエストに含めること（例: http://localhost/%0d%0aDetectify:%20clrf）は、誤って構成されたサーバーに対して行うと、サーバーが Detectify という新しいヘッダーを発行します。これは、$uri 変数がURLエンコードされた新しい行の文字をデコードするため、レスポンスに予期しないヘッダーが含まれることになります:
CRLFインジェクションとレスポンススプリッティングのリスクについて詳しくは、https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/を参照してください。
また、この技術はこのトークで説明されていますが、いくつかの脆弱な例と検出メカニズムが示されています。例えば、ブラックボックスの観点からこの誤設定を検出するために、次のリクエストを使用できます：
https://example.com/%20X - 任意のHTTPコード
https://example.com/%20H - 400 Bad Request
脆弱な場合、最初のリクエストは「X」として返され、任意のHTTPメソッドが使用され、2番目のリクエストは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
そのトークで示された脆弱な設定のいくつかは次のとおりです：
最終URLで**$uri**がそのまま設定されていることに注意してください。
再度**$uri**がURLに含まれていることに注意してください（今回はパラメータ内です）
現在、AWS S3にいます
ユーザー提供データが特定の状況下でNginx変数として扱われる可能性があることが発見されました。この挙動の原因はやや不明ですが、珍しいことではなく、確認するのも簡単ではありません。この異常はHackerOneのセキュリティレポートで強調されており、こちらで見ることができます。エラーメッセージのさらなる調査により、NginxのコードベースのSSIフィルターモジュール内での発生が特定され、サーバーサイドインクルード（SSI）が根本的な原因であることが明らかになりました。
この誤設定を検出するために、変数の印刷をテストするためにリファラーヘッダーを設定するコマンドを実行できます：
この設定ミスに関するスキャンは、ユーザーによってNginx変数が印刷される複数のインスタンスを明らかにしました。しかし、脆弱なインスタンスの数の減少は、この問題を修正するための努力がある程度成功していることを示唆しています。
Nginxは、バックエンドによって生成されたエラーやHTTPヘッダーを傍受することを可能にするproxy_passを通じて機能を提供し、内部エラーメッセージやヘッダーを隠すことを目的としています。これは、Nginxがバックエンドエラーに応じてカスタムエラーページを提供することによって実現されます。しかし、Nginxが無効なHTTPリクエストに遭遇すると、課題が生じます。そのようなリクエストは、受信した通りにバックエンドに転送され、バックエンドの生のレスポンスはNginxの介入なしにクライアントに直接送信されます。
uWSGIアプリケーションに関する例のシナリオを考えてみましょう：
この管理のために、Nginxの設定で特定のディレクティブが使用されます：
proxy_intercept_errors: このディレクティブは、Nginxがステータスコードが300を超えるバックエンドレスポンスに対してカスタムレスポンスを提供できるようにします。これにより、例として挙げたuWSGIアプリケーションに対して、500 ErrorレスポンスがNginxによってインターセプトされ、処理されることが保証されます。
proxy_hide_header: 名前が示すように、このディレクティブは指定されたHTTPヘッダーをクライアントから隠し、プライバシーとセキュリティを向上させます。
有効なGETリクエストが行われると、Nginxは通常通り処理し、秘密のヘッダーを明らかにすることなく標準のエラーレスポンスを返します。しかし、無効なHTTPリクエストはこのメカニズムをバイパスし、生のバックエンドレスポンスが露出し、秘密のヘッダーやエラーメッセージが含まれる結果となります。
デフォルトでは、Nginxの**merge_slashesディレクティブはonに設定されており、URL内の複数のスラッシュを1つのスラッシュに圧縮します。この機能はURL処理を簡素化しますが、特にローカルファイルインクルージョン（LFI）攻撃に対して脆弱なアプリケーションの背後にあるNginxでの脆弱性を隠す可能性があります。セキュリティ専門家のダニー・ロビンソンとロテム・バー**は、このデフォルトの動作に関連する潜在的なリスクを指摘しています。特にNginxがリバースプロキシとして機能する場合です。
このようなリスクを軽減するために、これらの脆弱性に対して感受性のあるアプリケーションに対して**merge_slashesディレクティブをオフにする**ことが推奨されます。これにより、NginxはURL構造を変更することなくアプリケーションにリクエストを転送し、基盤となるセキュリティ問題を隠さないようにします。
詳細については、ダニー・ロビンソンとロテム・バーを確認してください。
この書き込みに示されているように、ウェブサーバーからのレスポンスに存在する場合、特定のヘッダーが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**の内容を送信します（パストラバーサル）。
Nginxの設定において、mapディレクティブはしばしば認可制御の役割を果たします。一般的な間違いはデフォルト値を指定しないことで、これが無許可のアクセスにつながる可能性があります。例えば：
defaultがない場合、悪意のあるユーザーは/map-poc内の未定義のURIにアクセスすることでセキュリティを回避できます。Nginxマニュアルでは、そのような問題を避けるためにデフォルト値を設定することを推奨しています。
特定の条件下でNginxに対するDNSスプーフィングは可能です。攻撃者がNginxが使用するDNSサーバーを知っていて、そのDNSクエリを傍受できる場合、DNSレコードをスプーフィングできます。ただし、NginxがDNS解決に**localhost (127.0.0.1)**を使用するように設定されている場合、この方法は効果がありません。Nginxでは、次のようにDNSサーバーを指定できます:
proxy_pass と internal ディレクティブproxy_pass ディレクティブは、リクエストを他のサーバーにリダイレクトするために使用されます。内部または外部のいずれかです。internal ディレクティブは、特定の場所が Nginx 内部でのみアクセス可能であることを保証します。これらのディレクティブ自体は脆弱性ではありませんが、その設定はセキュリティの欠陥を防ぐために慎重に検討する必要があります。
nginx サーバーが Upgrade と Connection ヘッダーを渡すように設定されている場合、h2c Smuggling attack を実行して保護された/内部エンドポイントにアクセスすることができます。
この脆弱性により、攻撃者は proxy_pass エンドポイント (http://backend:9999 の場合) との直接接続を確立することができます。その内容は nginx によってチェックされません。
/flag を盗むための脆弱な設定の例は こちら です。
注意してください。proxy_passがhttp://backend:9999/socket.ioのような特定のパスを指していても、接続はhttp://backend:9999で確立されるため、その内部エンドポイント内の他のパスに連絡することができます。したがって、proxy_passのURLにパスが指定されていても関係ありません。
Detectifyは、Dockerを使用してこの記事で説明されているいくつかの誤設定を持つ脆弱なNginxテストサーバーをセットアップできるGitHubリポジトリを作成しました。自分で見つけてみてください！
https://github.com/detectify/vulnerable-nginx
GixyはNginxの設定を分析するツールです。Gixyの主な目的は、セキュリティの誤設定を防ぎ、欠陥の検出を自動化することです。
Nginxpwnerは、一般的なNginxの誤設定や脆弱性を探すためのシンプルなツールです。
あなたのウェブアプリ、ネットワーク、クラウドに対するハッカーの視点を得る
実際のビジネスに影響を与える重大で悪用可能な脆弱性を見つけて報告します。 20以上のカスタムツールを使用して攻撃面をマッピングし、特権を昇格させるセキュリティ問題を見つけ、自動化されたエクスプロイトを使用して重要な証拠を収集し、あなたの努力を説得力のある報告書に変えます。
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
