Statアナライザーの夢を見る

この10年間で最も一般的なアプリケーションセキュリティの傾向の1つは、仮想パッチ（VP）テクノロジーです。これにより、Webアプリケーションファイアウォールレベル（Webアプリケーションファイアウォール、以下）で既知の脆弱性を悪用することからWebアプリケーションを保護できます。 WAFとは、外部ネットワークへのゲートウェイとWebサーバーの間の別個のノードで動作する専用ソリューションを意味します）。 VPテクノロジーは、静的アプリケーションセキュリティテスト（SAST）ツールの結果に基づいたWAF側でのHTTP要求フィルタリングルールの構築に基づいています。 ただし、SASTおよびWAFツールはさまざまなアプリケーションプレゼンテーションモデルとさまざまな意思決定方法に依存しているという事実により、市場での統合のための真に効果的なソリューションはまだありません。 SAST内では、アプリケーションでの作業はホワイトボックスモデルに従って実行され、原則として、コード内の脆弱性を検索するために正式なアプローチが使用されます。 WAFの場合、アプリケーションはブラックボックスであり、攻撃を検出するためにヒューリスティックが使用されます。 これにより、脆弱性の悪用条件が単純なスキーム `http_parameter = plain_text_attack_vector`を超える場合に、VPを効果的に使用して攻撃から保護することはできません。



しかし、SASTを使用して取得されたアプリケーションの内部デバイスに関する情報がWAF側で利用可能になり、発見された脆弱性への攻撃を推測せずに、攻撃の事実を証明できるように、SASTとWAFを「友達にする」としたらどうでしょうか？

伝統的なVPの素晴らしさと貧困

Webアプリケーションの仮想パッチの作成を自動化する従来のアプローチは、SASTを使用して発見されたすべての脆弱性に関するWAF情報を提供することです。

• 脆弱性クラス。
• Webアプリケーション（URLまたはその一部）への脆弱なエントリポイント。
• 攻撃が可能になるHTTPリクエストの追加パラメーターの値。
• 脆弱なパラメーターの値-攻撃ベクトルのキャリア。
• 多くの文字または単語（トークン）。脆弱なパラメーターに出現すると、脆弱性の悪用につながります。

HTTP要求パラメーターの値のセットと脆弱なパラメーターの危険な要素を決定するには、すべての可能な要素と生成関数（通常は正規表現に基づく）の単純な列挙を使用できます。 XSS攻撃に対して脆弱なASP.NETページコードスニペットについて考えます。

01 var condition = Request.Params["condition"]; 02 var param = Request.Params["param"]; 03 04 if (condition == null || param == null) 05 { 06 Response.Write("Wrong parameters!"); 07 return; 08 } 09 10 string response; 11 if (condition == "secret") 12 { 13 response = "Parameter value is `" + param + "`"; 14 } 15 else 16 { 17 response = "Secret not found!"; 18 } 19 20 Response.Write("<b>" + response + "</b>");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

攻撃ベクトルに対するこのコードの分析の結果、その値の条件付きセットのシンボリック式が導出されます。



{condition = "secret" ⇒ param ∈ { XSShtml-text }}, XSShtml-text — XSS- TEXT, HTML.







この式から、エクスプロイトと仮想パッチの両方を推測できます。 仮想パッチ記述子に基づいて、WAFはすべてのHTTP要求をブロックするフィルタリングルールを生成します。その実行により、発見された脆弱性が悪用される可能性があります。



もちろん、このアプローチでは、特定の攻撃セットから防御することができますが、次のような重大な欠点もあります。

• 脆弱性の存在を証明するために、SASTツールは、脆弱性に対する攻撃ベクトルの1つを単に検出します。 脆弱性を効果的に排除するには、すべてのベクトルを防御する必要があります。ベクトルは無限であるだけでなく、攻撃ベクトルの不規則な文法により正規表現で表現できないことが多いため、WAF側に報告することは困難です。
• 同じことが、追加のすべてのクエリパラメータの値に当てはまり、脆弱性の悪用が可能になります。
• 脆弱なパラメーターの危険な要素に関する情報は、エントリポイントから脆弱な実行ポイントへの途中で、攻撃ベクトルがその文法または文法全体（たとえば、Base64、URLまたはHTMLエンコーディング、文字列変換など）のコンテキストを変更する中間変換を受ける場合、役に立ちません）

これらの欠点は、特殊なケースに対する保護に焦点を当てたVPテクノロジーでは、SASTツールを使用して発見された脆弱性に対するすべての可能な攻撃に対する効果的な保護を許可しないという事実につながります。 さらに、この方法で構築されたトラフィックフィルタリングルールは、通常のHTTP要求をブロックし、保護されたアプリケーションの動作を混乱させることがよくあります。 脆弱なコードを少し変更します。

 01 var condition = Request.Params["condition"]; 02 var param = Request.Params["param"]; 03 04 if (condition == null || param == null) 05 { 06 Response.Write("Wrong parameters!"); 07 return; 08 } 09 10 string response; 11 // CustomDecode    base64-URL-base64 12 if (CustomDecode(condition).Contains("secret")) 13 { 14 response = "Parameter value is `" + CustomDecode(param) + "`"; 15 } 16 else 17 { 18 response = "Secret not found!"; 19 } 20 21 Response.Write(response);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

前の例との唯一の違いは、両方のクエリパラメーターが何らかの変換を受け、サブストリングが含まれる前に「secret」パラメーターの条件が緩和されることです。 このコードの分析の結果としての攻撃ベクトルの分析は、次の形式を取ります。



(String.Contains (CustomDecode (condition)) ("secret")) ⇒ param ∈ (CustomDecode { XSShtml-text })







同時に、対応するCompFG頂点のCustomDecode関数について、アナライザーはBase64-URL-Base64変換チェーンを記述する式を導出します。



(Base64Decode (UrlDecode (Base64Decode argument)))







このタイプの式を使用すると、エクスプロイトを構築することも可能です（以前の記事のいずれかで詳細に説明しました）が、仮想パッチの構築に従来のアプローチを適用することはできなくなりました。

• 脆弱性の悪用は、デコードされた要求パラメーター「condition」に部分文字列「secret」が含まれる場合にのみ可能ですが、そのようなパラメーターの値のセットは非常に大きく、不規則なデコード機能のために正規表現で表現することは困難です;
• 攻撃ベクトルである要求パラメーターもデコードされ（14行目）、SASTツールがWAFの危険な要素の多くを生成するのを防ぎます。

従来のVPの問題はすべて、ホワイトボックスモデルに従ってWAFレベルでアプリケーションを操作できないことから発生するため、それらを排除するには、この機会を実装し、次のようにアプローチを改善する必要があることは明らかです。

• SASTツールは、脆弱なパラメーターと、エントリポイントから脆弱なポイントへの途中で成功した攻撃の条件が受けるすべての変換に関する完全な情報をWAFに提供しました。
• 攻撃を検出するために使用されたのはヒューリスティックではなく、特定の脆弱性の限定的なセットではなく、特定のステートメントの厳密な証拠に基づいて、各特定の脆弱性の動作条件の一般的なケースをカバーする正式な方法です

そして、ランタイムの仮想パッチングのテクノロジーが生まれました。

ランタイム仮想パッチ

ランタイム仮想パッチ（RVP）テクノロジは、ソースコードアナライザーのPT Application Inspector（PT AI）で使用される計算フローグラフ（CompFG）と呼ばれる調査対象のアプリケーションのモデルに基づいています。 このモデルは、PHDays VIIのAppSecスラムワークショップの一部として詳細に説明されました。 CompFGは、従来の記号計算と同様に、セマンティクスでのコードの抽象的な解釈の結果として、アプリケーションの分析中に構築されます。 このグラフの頂点には、対応する実行ポイントに存在するすべてのデータストリームの許容値のセットを指定するターゲット言語の生成式が含まれています。 これらのスレッドは、実行ポイント引数と呼ばれます。 たとえば、CompFGの上記の例の脆弱な実行ポイントの上部は次のようになります。







CompFGのプロパティの1つは具体性です。これは、すべての入力パラメーターの値を設定することにより、アプリケーション実行の任意の時点ですべての引数の特定の値のセットを計算する機能です。



RVPワークフローは、アプリケーションライフサイクルの段階に対応する2つの段階-展開（ステップD）と実行（ステップR）に分かれています。

展開フェーズ

アプリケーションの次のバージョンをデプロイする前に、PT AIを使用して分析します。その結果、CompFGの各頂点から脆弱な実行ポイントを記述する3つの式が導き出されます。

• ポイント自体の到達可能性条件。
• すべての引数の値の到達可能性の条件。
• すべての引数とそれらが対応する文法の値のセット。

すべての式のセットは、脆弱性がWebアプリケーションへの特定のエントリポイントの制御フローに属するという事実によってグループ化されます。 エントリポイント自体の概念は、サポートされている各PT AI Webフレームワークに固有であり、アナライザーナレッジベースで定義されています。



その後、検出された脆弱性と関連する式を含むレポートが、S式の構文に基づいた特別なドメイン言語のコードの形式でダウンロードされ、ターゲット言語に依存しない形式でCompFG式を記述できます。 以前に検討されたコード例の脆弱性の引数値の式は次のとおりです。



(+ ("Parameter value is `") (FromBase64Str (UrlDecodeStr (FromBase64Str (GetParameterData (param))))) ("`")),







そして、その到達可能性の条件の公式：



(Contains (FromBase64Str (UrlDecodeStr (FromBase64Str (GetParameterData (condition))))) ("secret")).







結果のレポートはPT Application Firewall（PT AF）にアップロードされ、それに基づいてバイナリモジュールが生成され、そこに存在するすべての式を計算できます。 考慮された例の脆弱点の到達可能性条件を計算するための逆コンパイルされたコードは次のようになります。







フォーミュラの計算を可能にするために、PT AF側で（選択する）必要があります：

• レポートに表示される可能性のあるすべての関数の計算機のデータベース。
• 保護されたアプリケーションが実行されている言語またはプラットフォーム（CLR、JVM、PHP、Python、またはRubyインタープリターなど）のランタイムと、アプリケーションで使用されるライブラリを備えた分離されたサンドボックス。

最初のオプションは最大のパフォーマンスを提供しますが、電卓を記述するためにWAF開発者が膨大な量の手作業を行います（標準ライブラリの機能のみに制限されている場合でも）。 2番目のオプションでは、レポートに表示される可能性のあるすべての関数を計算できますが、ランタイムを呼び出して各関数を計算する必要があるため、各HTTPリクエストの処理時間も長くなります。 ここで最適なオプションは、最初のオプションが最も一般的な機能に使用され、他のすべてが2番目の機能を使用して計算される場合です。



式には、アナライザーが「失敗」できない（たとえば、プロジェクトの依存関係がない、またはネイティブコードに関連するメソッドを呼び出す）および（または）計算する機能があり、これはPT AF側でも不可能です（たとえば、外部ソースまたはサーバー環境からデータを読み取る機能）。 このような関数は、式で不明フラグでマークされ、特別な方法で処理されます（以下を参照）。

運用フェーズ

操作フェーズでは、各HTTPリクエストで、WAFはその処理を生成されたバイナリモジュールに委任します。 モジュールはリクエストを分析し、それに関連するWebアプリケーションへのエントリポイントを決定します。 このポイントでは、分析の結果として発見されたすべての脆弱性の式が選択されます-そして、それらは特定の方法で計算されます。



最初に、両方の条件の式が計算されます：脆弱点の到達可能性とそのすべての引数の値。 変数の代わりに、対応するクエリパラメータの値が各式に代入され、その後、その値が計算されます。 数式に不明フラグのある式が含まれている場合、次のように処理されます。

• 不明な各フラグは、ブール式でマークされるまで、式式のツリーを下から上に伝播します。
• このような式（未知の領域）はすべて、式内でブール変数に置き換えられ、結果の式についてブール充足可能性の問題が解決されます。
• n個の条件は、初期条件式から構築されます—前のステップで見つかったすべての解から未知の領域の可能な値を代入することにより。
• 得られた各式の値が計算され、それらの少なくとも1つが実行可能であれば、初期条件も実行可能と見なされます。

計算の結果が元の式の偽の値であった場合、これは、このHTTP要求が、すべての引数の危険な値を持つ脆弱なポイントにアプリケーションを導くことができないことを意味します。 この場合、RVPはリクエスト処理をメインのWAFモジュールに返すだけです。



脆弱性に対する攻撃の条件が満足できる場合、脆弱点の引数の値を計算する番です。 これに使用されるアルゴリズムは、処理されるポイントが属する脆弱性のクラスによって異なります。 それらに共通するのは、未知のノードを含む式を処理するためのロジックのみです：条件式とは異なり、そのような引数式はすぐにWAFに報告され、次の弱点の計算への移行が実行されます。 例として、インジェクションクラス攻撃の検出に使用される最も複雑なアルゴリズムを検討してください。

注入検出

インジェクションクラスには、攻撃者によって制御されたデータに基づいて形成された形式言語（HTML、XML、JavaScript、SQL、URL、ファイルパスなど）のテキストの整合性を侵害することを目的とする攻撃が含まれます。 攻撃は、特別に生成された入力データをアプリケーションに送信することによって実行されます。攻撃されたテキストにそれを代入すると、トークンを超えて、アプリケーションロジックによって提供されないテキストに構文が導入されます。



アプリケーションの現在の脆弱性がこのクラスの攻撃に属している場合、その引数の値は、汚染分析のセマンティクスでの抽象的な解釈を伴う、いわゆる増分計算アルゴリズムを使用して計算されます。 このアルゴリズムの本質は、式の各式が下から上に別々に計算され、各ステップで得られた計算の結果が、各計算関数のセマンティクスと従来の汚染分析のルールに基づいて「汚染」の境界でさらにマークされることです これにより、最終的な計算結果で、入力データの変換の結果として取得されたすべてのフラグメント（汚染されたフラグメント）を分離できます。



たとえば、上記のコードとパラメーター「？







さらに、得られた値は脆弱点の引数の文法に従ってトークンに分割され、複数のトークンが汚染されたフラグメントのいずれかに該当する場合、これは検出された攻撃の正式な兆候です（注入の定義による）：





現在のエントリポイントに関連するすべての脆弱性の式の計算が完了すると、要求処理は検出結果とともにメインWAFモジュールに転送されます。

RVPの利点と機能

この方法で実装されたコードのセキュリティを分析した結果に基づいてアプリケーションを保護するアプローチには、従来のVPと比較して多くの重要な利点があります。

• 上記の正式なアプローチと、出力データの中間変換を考慮に入れる機能により、従来のVPで示されたすべての欠点が排除されます。
• 公式のアプローチは、式に未知のノードがない場合、第1種のエラー（誤検知、誤検知）が発生する可能性も完全に排除します。
• 保護はWebアプリケーションの機能だけでなく、独自の方法で実装されるため、Webアプリケーションの機能への悪影響はありません。

テクノロジをテストしてその有効性を確認するために、統合モジュールPT Application InspectorおよびPT Application Firewallのプロトタイプが、.NETプラットフォーム用のIIS WebサーバーのHTTPモジュールとして開発されました。 考慮されたコード例を使用した彼の作品のデモは、 YouTubeで見ることができます。 多数のオープンCMSのパフォーマンステストでは、許容できる結果以上のものが示されました。RVPを使用したHTTP要求の処理時間は、従来の（ヒューリスティック）WAFメソッドによる処理時間に匹敵しました。 リクエストに対するWebアプリケーションの応答が遅くなる割合の平均は次のとおりです。

• 脆弱点をもたらさない要求を処理する場合は0％。
• 弱点につながるが攻撃ではない要求を処理する場合は6〜10％（弱点の文法の複雑さによる）。
• 脆弱点につながり、攻撃であるリクエストを処理する場合、4〜7％。

従来のVPに対する明らかな利点にもかかわらず、RVPにはまだいくつかの概念的な制限があり、それらを取り除きたいと思います。

• WAF側にないソース（ファイルリソース、データベース、サーバー環境など）からの外部データを含むそのような数式の値を計算する方法はありません。
• 数式の品質は、解析中のコードの一部のフラグメントの近似の品質（ループ、再帰、外部ライブラリのメソッドの呼び出しなど）に直接依存します。
• コンピュータベースの関数を変換するセマンティクスの説明には、ある程度のエンジニアリング作業が必要です。これは、自動化が不十分であり、ヒューマンファクターに関連するエラーが発生する可能性があります。

ただし、RVP機能の一部をアプリケーション側に転送し、ランタイムアプリケーション自己保護（RASP）の基礎となるテクノロジーを適用することにより、これらの欠点を解消できることが判明しました。



しかし、それについては記事の後半で説明します:)