ファイル操作のセキュリティ - ファイルインクルードの原則

このセクションでは、私のコラム「Web セキュリティの原則と複数の防御方法の解釈」のセクションとして、ファイルに含まれるセキュリティ関連の内容を詳しく紹介します。

ソフトウェア開発の過程では、関数の再利用に伴い、徐々に公開関数が形成され、これらの公開関数は同じファイル内の他の関数から呼び出すことができます。さらに多くのパブリック関数があり、異なるファイルにこれらのパブリック関数の呼び出し要件がある場合、これらのパブリック関数は独立して特定の機能を提供するファイルになります。これらの機能を使用する場合は、このファイルを直接インクルードするだけです。したがって、Java、js、PHP など、多くのプログラミング言語はファイルに含まれる関数を提供します。次のファイルには、jsp、js、php、およびその他の言語の関数が含まれています。

jsp:   include，<jsp:include>
js:require
PHP：include，include_once，require，require_once

ファイルに含まれる抜け穴の原理

このファイルには、関数を再利用するためにプログラミング言語が元々提供していた関数が含まれていることがわかります。しかし、ビジネス開発者は、使用の過程で、ビジネスの柔軟性を高めるために動的変数を含めることがよくありますが、この変数により、制御不能な状態の悪意のあるファイルが組み込まれ、ファイルに含まれる関数が通常実行されます。ファイル封じ込めの抜け穴が形成されます。

通常、これらの関数の入力パラメータはクライアントが制御できる変数であり、クライアントは不正なファイルを実行する悪意のあるリクエストを作成する可能性があります。

ファイルインクルードは通常、ローカルファイルインクルードとリモートファイルインクルードの 2 つのタイプに分けられます。以下の図 1 に示すように、OWASP による LFI と RFI の定義は次のとおりです。
ここに画像の説明を挿入

図 1
ローカルファイルの組み込みは、組み込まれるファイルがローカルホスト上のファイルであることを意味し、リモートファイルの組み込みは、組み込まれるファイルがリモートホスト上のファイルであることを意味します。リモートアテンションにアクセスするにはネットワークを使用する必要があるため、リモートファイルを使用するには通常、言語によって提供される構成項目を有効にする必要があります。通常、脆弱性がファイルインクルードの脆弱性である場合、根本的な原因は、バックエンドコードが上記のファイルインクルード機能 (require) を使用しており、フィルタリングが不足していることです。

ファイルに含まれる脆弱性の例

ファイルインクルードのバグは、かつては PHP で非常に一般的であり、他の言語でも何度も発生しています。フレームワークの普及とセキュリティ意識の向上により、フィルタリングがないことによって引き起こされるファイルインクルードの脆弱性の数は徐々に減少してきました。ただし、ビジネスの複雑さにより、ほとんどのプログラマはファイルインクルードの制限を無視することがよくあります。ここでは、比較的大きな影響を与えるファイルインクルードの脆弱性をいくつか説明します。

CVE-2018-17246

この脆弱性は、kibana 5.0.0 ～ 5.6.13 と 6.0.0 ～ 6.4.3 の間のバージョンに影響します。require 関数がファイルのインクルードのバックグラウンドで使用されるため、HTTP リクエストの apis パラメータを解析するときに、apis パラメータが存在しません。フィルタリングプロセスを実行するには、ファイルを含めるための apis の値を構築できます。これにより、以下の図 2 NVD に示すように、任意のファイルの読み取り、リバウンドシェル、DOS 攻撃などが行われます。
ここに画像の説明を挿入

図 2 は
、NVD が 9.8 という非常に深刻なスコアを与えたことを示しています。詳細なスコアの詳細は、この脆弱性がネットワーク経由で直接悪用するのが比較的簡単であり、前提条件を必要としないことを示しています。Kibana のプロセスレベルとこのファイルを組み合わせると、これを含めると、非常に深刻な抜け穴になります。POC を図 3 に示します。
ここに画像の説明を挿入

画像3

図 3 の POC は js スクリプトです。これは、サーバー側でファイルをインクルードして JS スクリプトを実行し、リバースシェルを作成することを意味します。サーバーのシェルを入手することは理論的には最も危険な結果ですが、もちろん、ファイルに含まれる抜け穴を直接使用して機密情報を入手し、DOS を引き起こす可能性もあります。

脆弱性の履歴の詳細はここで確認できます。以下の図 4 に示すように、脆弱性は脆弱性の履歴コードと組み合わせてさらに分析されます。
ここに画像の説明を挿入

図 4
に示すように、この脆弱性は 2015 年 9 月のコミットで導入されました。図 4 は、name 変数が apis パラメータから取得されていることを示しています。プログラマは、コードのこの部分を追加するときにフィルタリングを考慮しませんでした。ユーザーの入力は次のとおりです。 require 関数ファイルによって直接インクルードされます。この脆弱性は、以下の図 5 に示すように、2018 年 10 月に修正されました。
ここに画像の説明を挿入
図 5 は、
この修復を通じて次の情報を取得できます。

まず、脆弱性の発生から脆弱性の修復までに 3 年かかりましたが、この 3 年間にこの脆弱性が把握されたのは少数の人かどうかは不明であり、このソフトウェアの広範な使用と重大性を考慮すると、未知の損失が多額になる可能性があります。このような重要な基本コンポーネントの場合、このような明白なファイルの組み込みはホワイトボックス監査によって理論的には回避できますが、オープンソースコミュニティ全体のセキュリティ状況は依然として懸念されていることがわかります。さらに、ソフトウェアの脆弱性には、公開前にその影響を評価することが難しいという非常に深刻な問題があります。
次に、図 2 において、NVD が脆弱性を公開した日は 12 月であり、脆弱性のパッチ適用時期は 10 魚粉であり、脆弱性がパッチされた時点から 2 か月後です。公式の Kibana が最初にこの脆弱性を取得し、パッチの適用が完了しましたが、NVD がこの脆弱性に番号を割り当てるために、後で一般に公開されました。一般に、NVD の公開は広く注目を集めますが、その観点からすると、この期間中に、この脆弱性が公開されずに悪用された可能性があり、これも非常に危険です。
最後に、修正は API 内の値をフィルターし、ホワイトリスト内のモジュールとファイルのみを含めることを許可することです。

ホワイトリストを使用することで、この場合のファイルのインクルードによる JS スクリプトの実行を解決し、機密ファイルへのアクセスの問題を解決することができ、特定の問題に対する迅速な解決策となります。ただし、Kibana の require 関数を使用して多数のファイルを含めることに対するすべての解決策があるわけではありません。ファイルのインクルードに require が使用される他の場所でも同様の問題はありますか? 以下の図 6 に示すように、後続の処理では、Kibana が eslint-plugin-import のモジュールも使用して、プロジェクト内で require を使用するすべてのファイルの包含を制限していることがわかります。
ここに画像の説明を挿入

図 6図 7 に示すように、
図 6 の no-dynamic-require の役割をここに示します。
ここに画像の説明を挿入

図 7
では、require の入力パラメータの値が制限されており、式の形式の入力パラメータをフィルタリングすることはできません。

CVE-2018-12613

この脆弱性は、phpMyAdmin 4.8.0 ～ 4.8.2 のバージョンに影響し、ファイルをインクルードするためにバックグラウンドで include 関数が使用されるため、HTTP リクエスト内のターゲットパラメータを解析する際にバイパスエクスプロイトが存在し、任意のファイルの読み取りが実現される可能性があります。以下の図 8 NVD に示すように、ターゲット Get、get Webshell などの値を構築します。
ここに画像の説明を挿入

図 8
には POC が図 9 に示されています。
ここに画像の説明を挿入

図 9 からわかるように、
POC は機密構成情報を取得するために二重エンコーディングを使用していますが、二重エンコーディングの理由については、後の分析を参照してください。

phpMyAdmin はオープンソースプロジェクトです。図 10 の対応するコミットに移動して、その時点で脆弱性を修正したソースコード修復レコードを表示します (図10 を参照)。
ここに画像の説明を挿入

図 10
図 10 からわかるように、インクルード分岐に入るには、空の判定、インデックスで開始できない、ブラックリスト制限など、多くの条件があります。最も重要な判定条件は、図 11 に示すように、checkPageValidity 関数にあります。 :
ここに画像の説明を挿入

図11

図 11 の左側に見られるように、修復前のこの関数のロジックは、ターゲットがホワイトリスト内のファイルであるかどうかを判断し、そうである場合は true を返し、ホワイトリストにない場合は true を返します。の場合は false を返します。同時に、目標が通過する可能性があることを考慮しますか？いくつかのパラメータを導入します。したがって、図 11 の左側の赤枠では、疑問符の前半を切り取ることでブラックリストが判定されます。

図 9 の POC と組み合わせると、リクエストターゲットの値はであることがわかりますdb_sql.php%253f/../../../../../../windows/wininit.ini。URL$_REQUEST['target']に対応する値を取得した後、URL は一度デコードされるため、$_REQUEST['target']値はになりますdb_sql.php%3f/../../../../../../windows/wininit.ini。checkPageValidity関数では、ホワイトリスト$_pageに存在するURLを再度urldecodeでデコードしてdb_sql.phpを取得するのでtrueを返します。$whitelistインクルードファイルに含まれるファイルの名前は$_REQUEST['target']、その値はですdb_sql.php%3f/../../../../../../windows/wininit.ini。ファイル名に疑問符は使用できませんが、現時点では疑問符は %3f としてエンコードされているため、ファイル名は正当です (二重エンコードが使用されていない場合、ファイル名の検証で問題が発生する可能性があります)。同時に、PHP がファイルのインクルードを処理するとき、db_sql.php%3f ファイルが実際に存在するかどうかはチェックしませんが、db_sql.php%3f/../../../../../../対応するディレクトリ全体を直接検索します。そのため、指定されたディレクトリ内のファイルはディレクトリを介してトラバースできます。横断。

ここでの根本的な原因は、ファイルのインクルードに include を使用する場合、ブラック/ホワイトリストフィルタリングがあるにもかかわらず、依然としてバイパスされるケースがあることであることがわかります。この脆弱性は、ブラックリストとホワイトリストのチェックをバイパスするために二重にエンコードされています。

この脆弱性は典型的な脆弱性シナリオでもあります。つまり、ファイルのアップロード、ディレクトリのトラバーサル、ファイルのインクルードなどの特定の種類の脆弱性については、ブラックリストとホワイトリストなどのさまざまなオープンソースフレームワークで従来の修復提案が採用されています。 , などがありますが、ビジネスを書くプログラマーにとって攻撃者の視点で問題を考えることは難しいため、近年でもこれらの一般的な脆弱性は依然として頻繁に発生しており、その多くはバイパスの形で出現します。防御するのは難しいです。

文書に含まれる潜在的な危険性

前のセクションでは、ファイルインクルードの脆弱性について原理と例から簡単に説明しましたが、ファイルインクルードの脆弱性によってどのような被害が生じるのでしょうか? 特定の脆弱性ごとに影響の度合いは異なりますが、共通する危険性は冒頭の図 1 に示されており、その説明は次のとおりです。

サーバーコードが実行されてシェルを取得します。たとえば、CVE-2018-17246 の脆弱性により、サーバー上で js スクリプトが実行され、リバースシェルが形成される可能性があります。各言語が提供するファイルインクルード機能の主な目的は関数の再利用であるため、ファイルインクルードはインクルードされたファイルの実行を伴うのが一般的です。このとき含まれるファイルが、jsなどのスクリプトなど、あらかじめ実行用に用意されたスクリプトであれば、リバースシェルを構築することができます。
/etc/passwd などの機密情報の漏洩は、ローカルファイルインクルードの脆弱性による最も一般的な影響です。ファイルインクルードの本質は、変更されたファイルを読み取って実行することですが、実行できないファイルの場合は、多くの場合、読み取られるだけで、例外エラーまたはログの形式で記録されます。
DOS のサービス拒否は、上記と同様にファイルの実行を伴い、実行されたファイルに終了操作がある場合、サービスが起動されます。ただし、現代の攻撃は利益を得ることを主な目的としており、DOS 攻撃は通常、特殊な場合にのみ発生します。

この記事は CSDN の村の若者によるオリジナルの記事であり、許可なく複製することはできません。ブロガーのリンクはここにあります。