ソースコード分析と自動エクスプロイト生成について

最近、怠け者だけがソースコードのセキュリティの分析について書いていません。 数年前にソースコードの分析を新しい誇大広告と見なすことを提案した Gartnerの男が、これをやめるという意志をまだ与えていないためです。 そして、私の仕事の現在の方向（ PT Application Inspectorの開発への参加、以下AI）と、最近ではソースコード分析のトピックに関する適切な記事がなかったという事実を考えると、今日までなんとなく奇妙なことですこのブログの日には、この燃えるようなトピックについて1日も汚い日はありませんでした。 まあ、修正しました。

実際、AIのソースコードセキュリティの分析を自動化するためのアプローチについて言えることはすべて、PHDays IVのレポート「 ソースコードによるエクスプロイトの自動生成の問題 」で、Sergey PlekhovとAlexei Moskvinがすでに言っています。 レポートに出席せず、記録を見なかった人のために、記事をさらに読む前にこれを行うことを強くお勧めします。 しかし、Ivan Novikov aka @ d0znppからのレポートの最後に、「ケースは何ですか？」、「あなたのアプローチは同じRIPSとどのように違いますか？」、および「どのようにエントリポイントを取得しますか？」アプリケーションをデプロイしないと、エクスプロイトの構築に必要な外部データ（たとえば、特権ユーザーの名前とパスワード、エントリポイントへのルートなど）を取得することはできません。 用語の混乱があることをすぐに予約したい（私たちの側で無条件に行われます）：「ソースコードによる攻撃ベクトルのセットを自動的に出力する問題」という名前は、AIの作業中に解決されたタスクの本質をはるかに正確に反映します エクスプロイトとしてAIの出力で判明することを呼び出すことは、実際にはまったく正しくありません。 伝統的な用語での悪用よりもクールだからという理由だけで:)そして、私はこの考えを明らかにし、イヴァンが尋ねた質問に対するより詳細な答えを同僚に補足しようとします。

どうしたの？

まず第一に、このケースはコードの欠陥を見つけ、特定のクラスの攻撃に対する脆弱性を確認することにあります。 このケースのフレームワーク内での自動エクスプロイト生成のタスクは、脆弱性の存在を確認する最小限の攻撃ベクトルの結論に達します。 同時に、ベクターは特定のHTTP要求ではなく、システムを脆弱な状態にし、攻撃を成功させる要因の特定のセットを意味します。 さらに言います：一般的なケースでは、攻撃ベクトルをHTTPリクエストのみとして表現することはできません。 第一に、このベクトルには複数のクエリが必要になる場合があるためです。 第二に（そしてこれは重要です）、ベクターにはHTTPリクエストのコンテキストでは記述できない環境プロパティの条件が含まれている可能性があるためです。 それにもかかわらず、検討中の事件の枠組みの中で、私たちは次のことをしなければなりません。 b）何らかの方法で分析結果にそれらを配置します。 これがまさに、このような複雑なベクトルの定義につながったものです。 簡単な例を示します（以降、ASP.NET WebフォームのC＃コードを検討します）。

var settings = Settings.ReadFromFile("settings.xml"); string str1; if (settings["key1"] == "validkey") { Response.Write(Request.Params["parm"]); } else { Response.Write("Wrong key!"); } 

明らかに、この場合、XSS攻撃に対する脆弱性は、settings.xml構成ファイルのkey1パラメーターの値に依存します。 そして、正直にそれを読んだ場合（つまり、実際には、象徴的にSettings.ReadFromFile（ "settings.xml"）を呼び出して結果を変数設定に割り当てない）、2つの可能な方法のうちの1つだけを実行します。ファイルのkey1が「validkey」に設定されていない場合、必然的に脆弱性をスキップすることになります。 最初の呼び出しをシンボリックに実行すると、最終的に次の式が得られます。これは目的のベクトルです。

 Settings.ReadFromFile("setings.xml")["key1"] == "validkey" -> {Request.Params["Parm"] = <script>alert(0)</script>} 

これからHTTPエクスプロイトを推測することもできます。

 GET http://host.domain/path/to/document.aspx?parm=%3Cscript%3Ealert%280%29%3C%2fscript%3E HTTP/1.1 

ただし、これは自給自足ではなく、Webアプリケーションの環境に課される条件に依存します。

データベース、ファイルシステム、またはその他の外部ソースから値を取得すると、単純なジレンマにつながります。外部データを取得し、本格的なエクスプロイトを構築する能力がある（理論的には可能）が、潜在的な脆弱性を見逃す実行パスが失われた場合、または外部ソースへの呼び出しを象徴的に処理し、それにより、そのような呼び出しの結果として発生する可能性のあるすべての値と実行パスのセットをカバーします。 また、全天候型の普遍的な攻撃者を作成するのではなく、可能な限りコードセキュリティを分析する人間のルーチンを自動化するというタスクに直面したため、本格的なエクスプロイトを構築する観点から、さらなる人間の作業を必要とする実証済みの論理式の形式でベクトルを取得することは、そのようなエクスプロイトを自動で取得するよりも好ましい機能。

ただし、外部データを読み取らずに実際にどこにも存在しない状況が発生する可能性があります。これは、アプリケーションコードではなく外部構成ファイルで定義されている場合、Webアプリケーションへのエントリポイントへのルートを決定し、追加のファイルをソースコードと接続することですそれらを構成ファイル（動的言語に関連）にリストし、同様のタスクをいくつか実行します。 しかし、質問はありません。必要な場合は、指を交差させて読みます。 もちろん、できるところ。

要約すると、現時点では、AIがデータベースからデータを読み取り、分析されたコードのシンボリック実行中にそれを使用するように教えることに対する障害はありません。 ただし、これには、少なくともWebアプリケーションデータベースを展開する必要があり、上記で説明したタスクセットのフレームワーク内で明確な利点を提供することなく、アナライザーの脆弱性検出能力を大幅に低下させます。

あなたのアプローチはRIPSとどう違いますか？

私がRIPSで採用されているアプローチを判断できる限り、AI'shnyはすべてよりも少し異なります。 RIPSは、多数の標準ライブラリ関数のエミュレーションを使用してデータフローグラフのパスをタグ付けすることにより、古典的な静的汚染分析を実装するという事実から始まり、AIアプローチでは、論理ステートメントの記述形式でモデル（各エントリポイントに1つ）を構築する必要があります各CFGノードのアプリケーションの状態とその達成条件。これにより、エミュレートする代わりに実際のコードを部分的に実行することで、そのパス（if、条件付きリターン、例外処理などを含む）を解決できます。最高の再 キャラクターの実行と比較した結果。 そして、RIPSがカスタムフィルタリング関数で愚かに中断することを（しかしこれに限定されない）終了しますが、AIはそれらを使用しようとします（そしてほとんどの実際のケースで非常に成功します）。

例を示す方が良いでしょう。 次のソースコードの断片があるとしましょう ^[1] ：

 string name = Request.Params["name"]; string key1 = Request.Params["key1"]; string parm = Request.Params["parm"]; byte[] data; if (string.IsNullOrEmpty(parm)) { data = new byte[0]; } else { data = Convert.FromBase64String(parm); } string str1; if (name + "in" == "admin") { if (key1 == "validkey") { str1 = Encoding.UTF8.GetString(data); } else { str1 = "Wrong key!"; Response.Write(str1); return; } } else { str1 = "Wrong role!"; } Response.Write("<a href='http://host.domain' onclick='" + CustomSanitize(str1) + "'>Click me</a>"); 

明らかに、潜在的な危険な操作が2回あります（以降、PVO-潜在的に脆弱な操作）-HTTP要求に対するサーバーの応答のストリームに書き込むResponse.Writeメソッドへの呼び出し。 最初のケースでは、定数「Wrong Key！」がメソッドに渡されますが、これは私たちには関係ありません。 ただし、2番目の結果は、引数を使用してCustomSanitizeメソッドを呼び出した結果であり、その値は、受信した要求のパラメーターの値から計算されます。 しかし、HTMLマークアップ要素の挿入によってXSS攻撃の可能性を確認するのに十分な値をstr1に転送できるようにするには、何をすべきでしょうか？ この質問に対する答えを見つけるプロセスがどのように見えるか見てみましょう ^[2] 。

まず、2番目のResponse.Writeの到達可能性条件を導出します。 それ自体が制御フローに影響を与える構造に埋め込まれていないという事実にもかかわらず、以前のコードブロックでは、コード全体に共通する関数からの戻りがあり、その到達可能性条件は同時にPVOの到達不能の条件でもあります。 明らかに、実行されるreturnステートメントの条件は論理式です：（name == "adm" && key1！= "Validkey"）。 したがって、その到達不能の条件は次の式になります：（name！= "Adm" || name == "adm" && key1 == "validkey"）。 この戻り値は2番目のResponse.Writeの到達可能性に影響する唯一のステートメントであるため、最後の式はPVOの到達可能性の条件になります。

実際、式（name！= "Adm" || name == "adm" && key1 == "validkey"）は、制御フローグラフ上のPVOへのパスを形成するための相互に排他的な2つの条件を提供します。 それぞれが実行されるときのstr1の可能な値を考慮してください。 （name！=“ Adm”）を使用すると、変数str1は定数値“ Wrong role！”を取得します。これにより、攻撃が成功することは間違いありません。 ただし、（name ==“ adm” && key1 ==“ validkey”）を使用すると、str1はデータ引数を使用してEncoding.UTF8.GetStringメソッドを呼び出した結果を取得します。このメソッドは、次の2つの値を取ります：new byte [0] with string.IsNullOrEmpty （parm）およびConvert.FromBase64String（parm）with！string.IsNullOrEmpty（parm）。 を含む興味のない破棄。 脆弱性値の悪用可能性と、すべての変数の値を汚染源まで巻き戻すと、次の式が得られます。

 (Request.Params["name"] == "adm" && Request.Params["key1"] == "validkey" && !string.IsNullOrEmpty(Request.Params["parm"])) -> Response.Write("<a href='http://host.domain' onclick='" + CustomSanitize(Convert.FromBase64String(Request.Params["parm"])) + "'>Click me</a>") 

この場合に構築された実行モデルのグラフィカル表現は、次のようになります（クリック可能）。


したがって、クエリパラメーター名とkey1の値は既にあり、行うべきことは、CustomSanitize式の最終値（Convert.FromBase64String（Request.Params ["parm]のように、Request.Params [" parm "]の値を見つけることだけです。 »]））XSSにつながる脆弱性の悪用を提供します。

そして、ここで、静的解析の従来の手段では対処できないという問題が発生します。 Convert.FromBase64Stringメソッドはライブラリメソッドであり、アナライザーのナレッジベースでConvert.ToBase64Stringの逆関数を持つと説明できます。この関数から、CustomSanitizeの結果は入力Convert.ToBase64Stringに送られると結論付けることができます。 しかし、ライブラリではないCustomSanitizeをどうするかは、どこにも記述されておらず、分析のこの段階では白黒のボックスですか？ さて、このメソッドのソースが利用可能であれば-この場合、その本体に「フォールスルー」し、上記と同様の方法でシンボリックコードの実行を継続できます。 しかし、ソースコードがない場合はどうでしょうか。 答えは前の文にありました。それについてしばらくの間忘れておくために、分析は静的であり、このメソッドをブラックボックスとして使用します。 以前に変換された式Convert.ToBase64String（CustomSanitize（Request.Params ["parm"]））があります。多くのXSSベクトルがあります（{`<script> alert（0）</ script>`、 onmouseover = 'a [アラート]; a [0] .call（a [1]、1） `and`“ onmouseover =” a [アラート]; a [0] .apply（a [1]、[1]） `}）-それで、Request.Params [" parm "]シンボル変数をベクトルの値で指定し、結果の式を直接実行することで、この式の焦点を外さないのはなぜですか？

CustomSanitizeが山かっこ文字のみを削除するとします。 次に、ファジングの結果として、3つの値を取得します。

 scriptalert(0)/script 'onmouseover='a[alert];a[0].call(a[1],1) "onmouseover="a[alert];a[0].apply(a[1],[1]) 

後者の2つは、攻撃ベクトルとして考慮する価値があります。 したがって、PVO引数として渡される完全な式がわかります。 文字変数Request.Params ["parm"]の値がベクトルの値で指定されている場合、その値が落ちる正確な場所を知っています。 これらの2つから、その使用が注入につながるベクトルを選択するために、他に何が必要ですか？ 「 安全なWebアプリケーションを開発し、同時にあなたの心を失わないようにするには 」ウェビナーを注意深く聞いた人たちは、私たちは他に何も必要ないとすぐに答えます:)

T.O. このコードの分析の最終結果は、コンテキスト（PVO実行のコンテキストでシンボリック変数の値を定義する）の悪用です：

 Request.Params["name"] = "adm" Request.Params["key1"] = "validkey" Request.Params["parm"] = "'onmouseover='a[alert];a[0].call(a[1],1)" 

HTTP（HTTPリクエストの実際のパラメータの要件を定義する）を悪用することは既に可能です：

 GET http://host.domain/path/to/document.aspx?name=adm&key1=validkey&parm=%27onmouseover%3D%27a%5Balert%5D%3Ba%5B0%5D.call%28a%5B1%5D%2C1%29 HTTP/1.1 

AIでは、興味がある場合は次のようになります（クリック可能）：


もちろん、厳しい現実では、すべてが少し複雑です。フィルタリング関数によって修正されたベクトルでさえ「シュート」することがあり、そのような関数の正規表現の出現とともに、定数値の代わりにそれらを記述する有限オートマトンを操作する必要が生じます。 クエリの入力パラメータが出力言語の任意の文法構造に固執する可能性があるという事実は、アイランド言語などのプロパティの解析および/またはヒューリスティックな推論の必要性につながります。 など しかし、これらはすでに個々の（そしておそらくもう少し科学的な）記事のトピックです。 私たちの仕事の一環として、これらの問題も正常に解決されたことにのみ注意してください。

エントリーポイントはどのようにして取得しますか？

すべての例で、 "/ path / to / document.aspx"（つまり、Webアプリケーションへのエントリポイントへのルート）を取得するという質問を意図的に省略しました。 このタスクには普遍的なソリューションはなく、アナライザーのナレッジベースでさまざまなフレームワークの詳細を説明する必要があります。 たとえば、ASP.NET Webformの場合、エントリポイントはいわゆるハンドラメソッドです。 Webフォームコントロールのポストバック（.aspxファイルを解析し、対応する分離コードファイルにリンクする必要があります）。 ASP.NET MVCでは、ルートは、アプリケーションの初期化コードにRouteCollectionを直接入力することにより定義されます。 セクションurlMappings、urlrewritingnetなどがWebConfigに表示される可能性を忘れないでください。これは、アプリケーションへのHTTPリクエストのルーティングにも影響します。 また、開発者がカスタムルーティングロジックを実装する独自のHTTPハンドラーを定義することを妨げるものはありません。カスタムルーティングロジックの逆はアルゴリズム的に不溶性のタスクです。 この場合、Java / C＃の場合はすべてのpublicメソッドとprotectedメソッド、またはPHPの場合はすべての.phpファイルをエントリポイントとして考慮する以外に選択肢はありません。外部からは到達できないコードで誤検知をキャッチする可能性が高くなります。 しかし、私は個人的にそのような.NETアプリケーションをまだ見ていません。PHPフレームワークの既存の動物園は、刺激的ではありますが、エントリーポイントへのルートの取得に関連する部分を含むアナライザーのナレッジベースで非常に形式化されています。 既に明らかであるように、データベースのルーティングルールを記述するなどのエキゾチックな、潜在的なすべてのエントリポイントの前述の直接列挙を処理しています（ところで、一見思われるほど悪い結果は得られません）。

それだけです

私はまだこれらの質問に答えることができたことを願っています。 しかし、突然新しいものが発生した場合、または理解できない瞬間が残っている場合-彼らが言うように、ようこそ:)

---

1. ↑すぐに、この例は確かに合成であり、生きているシステムからの実際の例ではなく、平均的なお粗末なコードを分析する方法で起こりうる問題を示すことを意図していることを予約します。 読者の1人がコードフラグメントの独自のバージョンを提供したい場合は、分析プロセスを検討することができ、それはまったく問題ではありません。
2. ↑このような単純なコードであっても、分析プロセスの段階的な実行の説明は、均一な論理式の変換のマルチページチェーンをもたらすため、ここでは計算を行いません。 興味のある方は、アプローチのかなり詳細な説明と、記事の冒頭で述べたレポートの記録における個々の段階に慣れることができます。