vladko312/research_successful_errorsエラーベースおよびブールエラーベースのブラインド手法を用いたSSTI（サーバーサイドテンプレートインジェクション）とコードインジェクションに関するホワイトペーパー。6つのプログラミング言語に対応したユニバーサルペイロードと、SSTImapへの統合を含む。
[!NOTE] これは、SSTImap バージョン 1.3.1 をリリースする前に私が発表した結果に基づくホワイトペーパーの第2版です。 さらなる改良は、後日研究のバージョン1.2としてこの形式に適合させます。
脆弱性のカテゴリの中には、一見するとよく知られていて、ある程度明白に思えるものもあります。 それらの脆弱性に対して考えられるすべての手法が知られており、珍しいケースに対するペイロードだけが発見される可能性があるように思えるかもしれません。 サーバーサイドテンプレートインジェクション (SSTI) と コードインジェクション は、しばしばそのようなよく知られたカテゴリと見なされます。
時には、それらの脆弱性に対して、自己説明的な名前を持つ新しい手法が遭遇することがあります。 多くの研究者は、それらの手法もよく知られていると考えたり、あるいは使用したことを覚えていたりするかもしれませんが、 実際には、その手法は共通の名前として存在するだけで、研究や説明、普遍的なペイロードは存在しない場合があります。 非常に特殊なケースに対するペイロードと一緒に数回言及されるかもしれませんが、 テストされることはなく、その手法の真の可能性は何年も発見されないままになる可能性があります。
この研究では、コードインジェクションとSSTIのための2つの新しい手法を紹介します:エラーベース と ブールエラーベースのブラインド。 私は、Python、PHP、Java、Ruby、NodeJS、Elixir の6つのプログラミング言語で、コードインジェクションとSSTIのためのペイロードを提供します。 さらに、ブラインドインジェクションでさえも迅速に検出できる、汎用的な検出ペイロードを提供します。
初期のきっかけから最終的な結論に至るまでの、私の研究の完全なタイムラインを提供します。 また、この研究で言及されていないプログラミング言語やテンプレートのための新しいペイロードを作成するプロセスについても探求します。
この研究では、新しい手法の実用的な応用例を示し、さらなる研究の可能性のある分野を共有します。 提供されるすべてのペイロードは、実際のアプリケーションにおける脆弱性の検出と悪用に使用できます。 さらに、提供されるすべてのペイロードはオープンソースツール SSTImap に追加されており、この研究の結果を実際のターゲットに適用することを容易にします。
サーバーサイドテンプレートインジェクションの脆弱性は、サーバーサイドレンダリングにテンプレートエンジンを使用する動的ウェブサイトにおいて、 信頼できないユーザー入力が、テンプレートエンジンによって処理される前にテンプレートに挿入された場合に発生します。 悪意のある攻撃者は、有効なテンプレート構文を挿入し、ページレンダリング中にテンプレートエンジンによって処理される可能性があります。 多くのテンプレートエンジンは、何らかの形式のコード実行機能を提供しており、これはしばしばターゲットサーバーでの リモートコード実行 (RCE) につながります。 この研究は、悪用された場合にそのような機能を提供するテンプレートエンジンに焦点を当てています。
SSTIの脆弱性は2015年から知られており、その間に情報の窃取、フィルターのバイパス、サンドボックスエスケープを提供する多くのペイロードが発見されました。 それにもかかわらず、ほとんどのペイロードは、結果をページに直接レンダリングするか、コード実行自体の事実に焦点を当てており、そのコードによって生成された結果を破棄しています。
もう一つのよく知られたSSTIの手法は、時間ベースのブラインドであり、実行されたシェルコマンドに遅延を追加することを含みます。 この手法により、注入されたコード実行の成功を判断することができますが、OSコマンド実行のペイロードを推測する必要があり、 研究者にとって未知のテンプレートエンジンでのブラインドSSTIの検出が難しくなります。
SSTIの脆弱性クラスと、既知の悪用手法の両方は、2015年にJames Kettleによって発見されました。 これらの手法は、彼の研究 "Server-Side Template Injection: RCE For The Modern Web App" で非常に詳細に説明されています。[^1] それから10年の間に、新しい悪用手法は文書化されていません。 2023年に、ポリグロットペイロードを使用して複数のテンプレートエンジンを同時にテストする1つの検出手法のみが発見されました。 この手法はMaximilian Hildebrandによって発見され、彼の研究 "Improving the Detection and Identification of Template Engines for Large-Scale Template Injection Scanning" で説明されています。[^2] この手法は、最小限のリクエストでテンプレートエンジンを特定することに焦点を当てていますが、単純なインジェクションコンテキストでのみ機能します。
PHP、NodeJS、Pythonなどのインタプリタ型プログラミング言語に基づくテンプレートエンジンの大部分は、対応するプログラミング言語の式を直接評価することを許可しています。 この機能により、テンプレートタグの正しい形式でラップすることで、より広範なコードインジェクション脆弱性カテゴリのペイロードを使用できます。
コードインジェクションは、SSTIなしでも発生する可能性があり、信頼できないユーザー入力が eval() または同様の危険な関数に到達した場合に発生します。
コードインジェクションの悪用は、対応する言語でのプログラミングに過ぎないと考えられることが多く、
そのため、手法やペイロードは特定の脆弱性の例についてのみ文書化されており、ターゲットアプリケーションに合わせたコードの調整が必要です。
コードインジェクションとSSTIのためのより普遍的な検出手法が欠如しているため、ブラインドコードインジェクションとテンプレートインジェクションのブラックボックススキャンが非効率的になっています。
この研究では、コードインジェクションとSSTIのための2つの新しい手法と、6つのプログラミング言語のペイロード、および汎用的な検出ペイロードを提供します。 提供される手法は、ブラインドSSTIの悪用の能力を拡張し、注入されたコードのプログラミング言語を推測することなく、ブラインドコードインジェクションとSSTIのスキャンを可能にします。
この研究で提供されるペイロードは、実際のウェブアプリケーションの実践的なペネトレーションテストを目的としています。 提示されたすべてのペイロードは、SSTIとコードインジェクションを検出するためのオープンソースツール SSTImap のモジュールにも組み込まれています。[^3] 2つの新しい手法と対応するペイロードのサポートは、バージョン 1.3.0 で追加されました。 この研究で提供される、新しい手法の実用的な応用のためのより汎用的でない、より具体的なペイロードは、 "extra" モジュール専用のリポジトリにある、追加のSSTImapモジュールに組み込まれています。[^4]
SSTImapモジュールのペイロードを開発している際、私はこの研究で提示する手法につながる、きっかけとなる制約と発見に遭遇しました。 既存の手法を使用して、注入されたコードから出力を取得することが不可能な、さまざまなSSTIおよびコードインジェクションのシナリオに遭遇しました。 そのような制約に直面したとき、私は出力を取得するためのさまざまなアイデアをテストし、最終的にこの研究で文書化された2つの新しい手法の発見につながりました。
潜在的な制限を示す最初のきっかけは、Dust.JS テンプレートエンジンのペイロードを更新しているときに遭遇しました。 このエンジンは時代遅れと見なされ、放棄されているように見えますが、コード実行は2015年の古いバージョンの dustjs-helpers でのみ可能でした。 このエンジンのSSTImapモジュールは Tplmap のコードベースから継承されており、[^5] 改良は優先度の低いタスクでしたが、単純なロジックレスのテンプレートエンジンの場合、多くの誤検出を引き起こしていました。
問題を修正するためにペイロードを改良しましたが、このテンプレートエンジンとそのペイロードが私の注意を引きました。
コードインジェクションは if ブロックの条件内で可能であり、直接 eval() に渡されていました。[^6]
結果はページに表示されなかったため、リフレクテッドSSTIの場合でもRCEは常にブラインドであると考えられました。
当時、時代遅れのテンプレートエンジンを調査して新しいペイロードを作成することは、私の優先順位リストで非常に低かったため、出力を取得する可能性のある方法を調査しないことにしました。
2番目のきっかけは、Twig テンプレートエンジンの新しいバージョン用のペイロードを開発しているときに遭遇しました。 初期のバージョン用のペイロードはすでに修正されていたため、更新されたペイロードを持つ新しいモジュールを作成することにしました。 Twigを悪用するためのより現代的な方法を探しているうちに、CVE-2022-23614を発見しました。これは、現代のバージョンで一般的なペイロードの1つを使用してサンドボックスバイパスを可能にするものです。[^7]
新しいSSTImapモジュールでは、そのサンドボックスバイパスの悪用が可能なペイロードを使用することにしました。これは、現代のペイロードで悪用可能なほぼすべてのTwigバージョンで機能するためです。
サンドボックスバイパスは、PHP関数名を含む文字列を |sort フィルターのパラメーターとして渡すことで可能になり、
テンプレートがその関数を2つの配列要素を引数として呼び出す原因となります。
Dust.JSの場合と同様に、関数の出力は内部的に条件（この場合は配列のソート）として使用されるため、テンプレートコンテキストに戻されません。
この制限は悪用を妨げるものではなく、PHPの system() 関数はOSコマンド実行の結果をウェブページに直接出力するため、テンプレートエンジンをバイパスして出力を取得できます。
テンプレートエンジン内で出力を取得する可能性について、何らかのバイパスや新しいSSTI悪用手法の一部としての潜在的な応用のために、好奇心を持ちました。 Twig用の新しいモジュールを作成するためには必要ではなかったため、テンプレート内でのインジェクション結果へのアクセスのための新しいペイロードを開発するための時間を割り当てないことにしました。
Node.JS モジュール JSONPath Plus のバージョン 10.3.0 以前における CVE-2025-1302 の脆弱性により、jsonpath の拡張条件構文内で関数コンストラクタにアクセスすることで、任意のJavaScriptコードの注入が可能になります。[^8] サーバーサイドのjsonpathインジェクションの場合のCVE-2025-1302の自動検出と悪用のために、新しい追加のSSTImapモジュールを作成することにしました。
Dust.JSと同様に、コードインジェクションは条件内でのみ可能であったため、出力を取得してページにレンダリングする直接的な方法はありませんでした。 それにもかかわらず、私は出力を抽出する可能性を研究することにしました。これにより、最終的にこの研究で議論される発見を引き起こした3番目のきっかけにつながりました。
