このセクションでは、私のコラム「Webセキュリティの原則と複数の防御方法の解釈」の一部として、ディレクトリトラバーサルの内容を詳しく説明します。
Linux システムでは、./ はカレント ディレクトリを示し、.../ は上位ディレクトリを示します。Linux システムでのこれらの文字の使用法は次のとおりです。
図1
Linux では、すべてがファイルです。各フォルダーの下に、現在のファイル ディレクトリと上位レベルのファイル ディレクトリを表す 2 つのファイル ./ と .../ があることがわかります。この2つの文字を編集するコマンドで操作します。
ディレクトリトラバーサルの脆弱性原理
ディレクトリ トラバーサルの定義に関して、CWE の定義は図 2 のようになります。
図 2
Web サービスでは、URL はファイルにアクセスするためのパス識別子であり、図 3 に示すように、バックグラウンド Web サーバー上のファイル パスと対応する関係があります。
図 3
では、packetstormsecurity.com は Web サービスの WAN アドレス (IP アドレスに相当) であり、IP サーバーを見つけた後、URL に従って対応するディレクトリ内の対応するファイルを検索します。/files/164418/ は、外部に表示されるファイル ディレクトリです。サーバー バックグラウンドの実際の絶対パスは、/var/www/html/files/164418/ のように、Web ディレクトリ +/files/164418/ になります。入力 URL が制限されていない場合、特別に構築された URL パスが存在し、特定のサーバー ディレクトリへのマッピングがアクセスのバックトラッキングにつながり、最も一般的な結果は任意のファイル アクセスを引き起こすことです。
ディレクトリトラバーサルの脆弱性の例
ディレクトリ トラバーサルの脆弱性は以前は非常に一般的でしたが、フレームワークの普及とセキュリティ意識の向上により、フィルタリングがないことが原因で発生するディレクトリ トラバーサルの脆弱性はますます少なくなりました。しかし、大多数のプログラマーには攻撃者の視点が欠けており、ファイル ディレクトリ トラバーサルの保護は依然として一部のフレームワークが提供するメカニズムに依存しているため、フレームワーク自体の取り扱いを誤ると重大な結果を招く可能性があります。現時点では、フレームワークにおけるディレクトリ トラバーサルの脆弱性の原因は、いくつかの微妙な過失により焦点が当てられています。以下に、典型的なディレクトリ トラバーサルの脆弱性について説明します。
CVE-2021-41773
この脆弱性は、バージョン 2.4.49 に存在する Apache HTTP SERVER の脆弱性です。HTTP リクエスト内のファイル パスを解析する際、ファイル パスの正規化処理関数 ap_normalize_path がよく考えられていないため、エンコードによってファイル パスを構築して任意のファイルへのアクセスを実現できますが、Apache HTTP サーバーでは通常 CGI 設定が有効になっているため、この脆弱性により、任意のコマンドが実行される可能性もあります。図 4 NVDの概要は次のとおりです。
図 4
本脆弱性は、基本サービスソフトウェアに属する Apache http サーバーの脆弱性であるため、Apache サーバーを使用するすべての Web サイトに影響を与えると言えます。これは非常に深刻な脆弱性です。以下は、公開されたエクスプロイトと Apache によって修復されたパッチに基づいた脆弱性の詳細な分析です。このうち、exp (この脆弱性のエクスプロイト プログラム) を図 5 に示します。 図 5 には、エクスプロイトの 2 つの例が示されています。2 番目の点が %2e で URL エンコードされている限り、URL 標準化が行われていることがわかります。プロセスを
バイパス
2 つの例は 2 つの結果をもたらします。1 つは任意のファイル読み取り (/etc/passwd の読み取り) を実行すること、もう 1 つは CGI を開くことです (CGI を使用すると、Web サーバーは外部プログラムを実行し、その出力を Web ブラウザーに送信できます)。デバイスの場合）、任意のコマンドの実行を実現します（つまり、/bin/sh 内の whoami コマンドを実行します）。以下の図 6 に示すように、脆弱性パッチの内容を比較してください。 図
6
はパッチを比較しており、注記は、修正前のバージョンでは標準化中に .../ などの文字のみがスキップされたのに対し、修正後のバージョンではスキップされたことを示しています。この.%2e/シチュエーションの処理に文字を追加しました。この修復方法は非常に典型的な処理方法であり、脆弱性が露呈した後、その脆弱性を可能な限り修復するためにPOC、つまり図4のエクスプロイトを修復し、使用を制限するというものです%2e。ビジネス開発者は攻撃と防御の知識を持っていないことが多いため、修復の結果は症状を治療するだけで、根本原因は解決しないことがよくあります。そのため、バージョン 2.4.50 の修復が完了した後、すぐに修復されたバージョンに対する新たなエクスプロイトが登場し、同じ問題を対象としたものであったものの、ソフトウェアのバージョンが異なるため、脆弱性番号 CVE-2021-42013 が付与されました。 。
CVE-2021-42013
上記の図 5 では、CVE-2021-41773 のパッチ修復が十分に完了しておらず、以下の図 7 NVD の導入部分に示されているように、依然としてバイパス状況が存在することにも言及されています。 図 7 この脆弱性のエクスプロイト
プログラム
以下の図 8 に示します。
図 8 との比較 図 8
の脆弱性悪用プログラムと、図 5 の悪用プログラムである CVE-2021-41773 は、脆弱性の原因、つまり状況を理解しやすいです。次の図 9 は、脆弱性 CVE-2021 -42013 パッチ修復の状況を示しています。
図 9 図
9 のパッチの比較から、二重エンコードが発生した場合は、URL の標準化が失敗したことを示す 0 (不正なエンコード) が直接返されることがわかります。この場合、URL は正常に処理されません。により、二重エンコーディングが回避されます。
CVE-2021-41773 と CVE-2021-42013 には 2 つの異なる番号が割り当てられていますが、実際にはこの 2 つの脆弱性は非常に関連性のある脆弱性であると言え、問題は同じ機能で発生しますが、影響を受けるのはバージョンが異なるだけです。歴史上、POC 指向の修復が不完全な修復に終わり、同じ問題に対して複数の脆弱性番号が連続して割り当てられることが何度もありました。この根本的な原因は、ソフトウェア開発者の大多数がセキュリティの知識に欠けており、ビジネス機能のセキュリティを攻撃と防御の観点から体系的に検討できないことです。したがって、現在でも、ソフトウェア セキュリティ全体では、ブラック ボックス テスト、ホワイト ボックス監査、POC の公開を通じてソフトウェアのビジネス セキュリティを推進しています。ブラックボックス、ホワイトボックス、およびホワイトボックス監査ではすべての脆弱性を 100% カバーすることはできないため、脆弱性の詳細をできるだけ早期に発見することはソフトウェア修復とセキュリティ防御にとって非常に重要です。
上記のディレクトリトラバーサル脆弱性は、脆弱性POCおよびソースコードレベルから導入されており、この脆弱性の影響をより深く体験したい場合は、Apache 2.4.50のリリース環境を使用して自身で検証することをお勧めします。 vulhub 環境の図 10 に示されているように、脆弱性についての理解:
図 10
ディレクトリトラバーサルの潜在的な危険性
前のセクションでは、ディレクトリ トラバーサルについて原理と例の 2 つの側面から簡単に説明しましたが、ディレクトリ トラバーサルによってどのような結果が生じるのでしょうか? 脆弱性が異なれば影響も異なります。以下に、ディレクトリ トラバーサルの脆弱性による潜在的な害をリストします。
- 任意のファイル アクセス、これはディレクトリ トラバーサルの脆弱性の最も一般的な結果です。たとえば、図 8 の POC はディレクトリ トラバーサルを使用して、/etc/passwd などの主要なファイルを読み取ります。
- 情報漏洩、このタイプの結果は、任意のファイル アクセスよりも影響が小さくなります。複雑なソフトウェアでは、さまざまなブラック リストとホワイト リストの制限により、ディレクトリ トラバーサルによるファイルへのアクセスが制限されます (たとえば、アクセス権は WEB 空間ディレクトリにのみ存在します)。このとき、一部の機密設定ファイルが漏洩する可能性があります。
- リモート コマンド実行。一般に、このタイプの脆弱性の総称としてリモート コマンド実行を指しますが、この記事の脆弱性 (図 8 の POC の例など) では、CGI が有効になっている場合にも、ディレクトリ トラバーサルによりリモート コマンドが実行されることが原因です。
この記事は CSDN の村の若者によるオリジナルの記事であり、許可なく複製することはできません。ブロガーのリンクはここにあります。