nginx を搭載した一部のサーバーは、2018 年の Blackhat カンファレンスで提案された Nginx Alias Traversal 手法に対して脆弱なままであり、「alias」ディレクティブで指定されたルート ディレクトリの外側にあるファイルやディレクトリへのアクセスを許可します。 この問題は、「location」ブロック内に「alias」ディレクティブが配置され、そのパラメータが「/」文字で終わらず、「alias」が「/」で終わる構成でのみ発生します。
問題の本質は、alias ディレクティブを持つブロックのファイルが、location ディレクティブのマスクと照合し、このマスクで指定されたパスの一部を切り取った後、要求されたパスを添付することによって提供されることです。 上に示した脆弱な構成の例では、攻撃者はファイル「/img../test.txt」をリクエストすることができ、このリクエストは場所「/img」で指定されたマスクと一致し、その後、残りの末尾「../」が一致します。 test.txt」はエイリアスディレクティブ「/var/images/」からのパスに添付され、その結果ファイル「/var/images/../test.txt」がリクエストされます。 したがって、攻撃者は、「/var/images/」内のファイルだけでなく、「/var」ディレクトリ内の任意のファイルにアクセスできます。たとえば、nginx ログをダウンロードするには、リクエスト「/img../log/」を送信できます。 nginx/access.log」。
エイリアス ディレクティブの値が「/」文字で終わらない構成 (たとえば、「alias /var/images;」) では、攻撃者は親ディレクトリに変更できませんが、/var 内の別のディレクトリを要求できます。構成で指定された名前で始まるもの。 たとえば、「/img.old/test.txt」をリクエストすると、ディレクトリ「var/images.old/test.txt」にアクセスできます。
GitHub 上のリポジトリを分析したところ、問題の原因となった nginx 設定のエラーが実際のプロジェクトでも依然として見つかっていることがわかりました。 たとえば、Bitwarden パスワード マネージャーのバックエンドで問題の存在が検出され、/etc/bitwarden ディレクトリ内のすべてのファイルへのアクセスに使用される可能性があります (/attachments のリクエストは /etc/bitwarden/attachments/ から発行されました)。これには、パスワード「vault.db」で保存されているデータベース、証明書、ログが含まれており、リクエスト「/attachments../vault.db」、「/attachments../identity.pfx」、「/attachments」を送信するだけで十分です。 ../logs/api.log」など。
このメソッドは Google HPC Toolkit でも機能し、/static リクエストは "../hpc-toolkit/community/front-end/website/static/" ディレクトリにリダイレクトされます。 攻撃者は、秘密キーと資格情報を含むデータベースを取得するために、クエリ「/static../.secret_key」および「/static../db.sqlite3」を送信する可能性があります。
出所： オープンネット.ru