この文書は2016年以降更新されていません

仮想パッチに関するチートシート

OWASP 作成
ジャンプ先: 移動、 検索
Cheatsheets-header.jpg


最終改訂日 (yy/mm/dd):2015/11/05

はじめに

このチートシートの目的は、組織におけるリスク緩和のための保護の適時の実装を最大限に推進するのに役立つ、 簡潔な仮想パッチフレームワークを提示することです。

定義: 仮想パッチ

既知の脆弱性を攻略しようとする試みを防止およびレポートする、セキュリティポリシー適用レイヤー。

仮想パッチの仕組みは、セキュリティ適用レイヤーによるトランザクションの分析を通じて、送信されてきた攻撃を途中で捕捉し、有害なトラフィックが Web アプリケーションに到達しないようにするものです。仮想パッチの適用により、アプリケーション自体の実際のソースコードは変更せずに、攻撃を阻止できます。

コードを修正しない理由

純粋に技術的な観点から言えば、組織における最適な改善戦略は、Web アプリケーションソースコード内の特定された脆弱性を修正することです。このコンセプトは、Web アプリケーションセキュリティ専門家とシステム所有者の両方から広く合意されています。しかし、残念なことに、現実世界のビジネス環境では、Web アプリケーションのソースコードを容易に更新できない状況が多くあります。たとえば、次のような場合です。

  • リソース不足: 開発者が既に他のプロジェクトに割り当てられている。
  • サードパーティ製ソフトウェア: ユーザー側でのコードの変更が不可能。
  • アプリ開発者のアウトソーシング: 変更を行うためには新たなプロジェクトが必要になる。

重要な点は、コードレベルの修正と仮想パッチの適用は、相互に排他的なわけではないことです。これらは、それぞれ異なるチーム (開発者チームとシステム運用チーム) によって実行されるプロセスであり、並行して実行することが可能です。

仮想パッチの価値

仮想パッチの主な 2 つの目標は、次のとおりです。

  • 修正時間の最小化: アプリケーションソースコードの修正には時間がかかります。仮想パッチの主な目的は、特定された脆弱性の緩和措置をできるだけ早急に実装することです。この対応の緊急性は状況に応じて異なります。たとえば、脆弱性がコードのレビューや侵入テストにより社内で特定される場合もあれば、今まさに発生しているインシデントへの対応措置の一部として脆弱性が検出される場合もあります。
  • 攻撃対象領域の縮小: 攻撃ベクトルの最小化に集中的に取り組みます。入力値検証が行われていない場合など、一部のケースでは、攻撃対象領域を 100% 縮小することが可能です。XSS 対策としての出力エンコード処理が行われていない場合など、その他のケースでは、露出の制限しかできない可能性があります。10 分で 50% 縮小するほうが、48 時間で 100% 縮小するよりも優れていることに留意してください。

仮想パッチ適用ツール

上記の定義では、特定のツールは挙げていませんが、仮想パッチの適用には、以下を含め、多数のオプションがあります。

  • WAF や IPS アプライアンスなど通信路の途中に設置するデバイス
  • ModSecurity などの Web サーバープラグイン
  • ESAPI WAF などのアプリケーションレイヤーフィルター

用途の例として、オープンソースの ModSecurity WAF ツール (http://www.modsecurity.org/) を使用した仮想パッチの例を示します。

仮想パッチの適用方法

他のほとんどのセキュリティプロセスと同様に、仮想パッチは、行き当たりばったりに適用するものではありません。成功する可能性が最も高い、一貫性のある反復可能なプロセスに従う必要があります。以下に示す仮想パッチワークフローは、業界で受け入れられている IT インシデント対応手法を模倣したものであり、次のフェーズで構成されます。

  • 準備
  • 特定
  • 分析
  • 仮想パッチの作成
  • 実装 / テスト
  • 回復 / フォローアップ

公開された脆弱性の例

この記事の残りの部分では、次の SQL インジェクション脆弱性 (http://www.osvdb.org/show/osvdb/88856) を例として取り上げます。

88856�: WordPress Shopping Cart Plugin for WordPress における /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php の reqID パラメーターに対する SQL インジェクション

説明: WordPress Shopping Cart Plugin for WordPress には、攻撃者による SQL インジェクション攻撃を許容しかねない欠陥が存在します。この問題は、/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php スクリプトで "reqID" パラメーターに対するユーザー入力が適切にサニタイズされないことに起因します。これにより、攻撃者によってバックエンドデータベースで SQL クエリのインジェクションや改変が行われ、任意のデータの改ざん / 漏えいにつながる可能性があります。

準備フェーズ

仮想パッチの準備フェーズを適切に行う必要があります。これについては、どんなに強調してもし過ぎることはありません。特定された脆弱性および Web アプリケーションで発生中の侵入に対処する前に、多くの準備作業をして仮想パッチ適用のプロセスとフレームワークを設定しておく必要があります。要するに、侵害が発生してから、Web アプリケーションのファイアウォールのインストールや仮想パッチのコンセプトについて提案しているようでは遅いのです。実際のインシデント発生時は緊張が高まっており、迅速な対応が鍵になります。そのため、平常時に仮想パッチの基盤を築いておき、実際にインシデントが発生したときにはすべての準備が整っている状態にしておきます。

準備フェーズで対処しておく必要がある重要な項目をいくつか次に示します。

  • 公開された脆弱性 / ベンダー別脆弱性の監視: 使用している市販のソフトウェアに関連する、ベンダー別のあらゆるアラートメーリングリストに確実に登録しておきます。それによって、ベンダーから脆弱性情報やパッチデータがリリースされたときに確実に通知を受け取ることができます。
  • 仮想パッチの事前認可: 仮想パッチは迅速に実装する必要があるため、標準のソフトウェアに適用される通常のガバナンスプロセスと認可ステップを迅速化する必要があります。仮想パッチでは実際にソースコードが変更されるわけではないため、通常のソフトウェアパッチほど多くの回帰テストは必要ありません。仮想パッチをウイルス対策の更新やネットワーク IDS シグネチャと同じグループに分類すると、認可プロセスが迅速になりテストフェーズの延長も最小限ですみます。
  • 仮想パッチ適用ツールの事前展開: インシデント発生時には迅速な対応がきわめて重要であるため、新しいソフトウェアのインストールの承認を得るための時間的なゆとりはありません。たとえば、ModSecurity WAF を埋め込みモードで、使用している Apache サーバー上にインストールするか、または Apache リバースプロキシサーバー上にインストールします。この展開の利点は、非 Apache バックエンドサーバー用の修正プログラムを作成できることです。通常の状況下では使用しなくても、必要に応じてすぐに有効化できるように ModSecurity を "準備" しておくのが最適です。
  • HTTP 監査ロギングの強化: ほとんどの Web サーバーで使用されている標準の共通ログ形式 (CLF) では、適切なインシデント対応に必要な十分なデータが提供されません。以下の HTTP データへのアクセスが必要です。
    • リクエスト URI (QUERY_STRING を含む)
    • 完全なリクエストヘッダー (Cookie を含む)
    • 完全なリクエスト本文 (POST ペイロード)
    • 完全なレスポンスヘッダー
    • 完全なレスポンス本文

特定フェーズ

特定フェーズでは、組織で使用されている Web アプリケーション内の脆弱性がその組織によって認識されます。通常、脆弱性の特定方法として、事前対策的な特定と事後対応的な特定の 2 つの方法があります。

事前対策的な特定

この場合、組織が、組織内のセキュリティ状態を自ら評価し、次のタスクを実行します。

  • アプリケーションの動的評価: 実行中の Web アプリケーションに対して善意の攻撃者による侵入テストまたは自動 Web 評価ツールを実行して、欠陥を特定します。
  • ソースコードのレビュー: 善意の攻撃者が手動 / 自動の手段により Web アプリケーションのソースコードを分析して、欠陥を特定します。

カスタムコードを使用した Web アプリケーションの場合、独自の特性を持っており、サードパーティによる脆弱性の通知に頼ることができないため、これらの事前対策的な特定タスクがきわめて重要になります。

事後対応的な特定

脆弱性の事後対応的な特定方法として、主に次の 3 つの方法があります。

  • ベンダーからの連絡 (事前警告など): 使用している市販の Web アプリケーションに関する脆弱性がベンダーによって公開されます。たとえば、Microsoft Active Protections Program (MAPP) (http://www.microsoft.com/security/msrc/collaboration/mapp.aspx) などがあります。
  • 一般公開: 使用している市販 / オープンソースの Web アプリケーションに関する脆弱性が一般公開されます。一般公開の場合、より多くの人々がその脆弱性について認識しているため、脅威のレベルが高くなります。
  • セキュリティインシデント: 攻撃が活動中であるため、緊急性が最も高い状況です。このような状況下では、迅速な対応が必要になります。

分析フェーズ

分析フェーズを開始するための推奨ステップを以下に示します。

  1. 仮想パッチの適用可能性について判断する: 仮想パッチはインジェクションタイプの欠陥には適していますが、他の攻撃タイプやカテゴリに対しては、攻撃対象領域を縮小するための適切なレベルの対策とはならないことがあります。基本的な欠陥を徹底的に分析することによって、その仮想パッチ適用ツールに適切な検出ロジック機能があるかどうか判断する必要があります。
  2. バグ追跡 / チケットシステムを活用する: 追跡用およびメトリックとして、バグ追跡システムに脆弱性情報を入力します。既に使用している Jira などのチケットシステムか、または ThreadFix (https://code.google.com/p/threadfix/) などの専用ツールの使用を推奨します。
  3. 脆弱性の名前を確認する: これは、脆弱性の発表や脆弱性スキャンなどによって指定された、適切な公開識別子 (CVE 名 / 番号など) を特定する必要があることを意味します。脆弱性が公開情報によって特定されたのではなく、事前対策的な方法で特定された場合は、それぞれの脆弱性に独自の識別子を割り当てる必要があります。
  4. 影響レベルを特定する: Web 脆弱性に関連する重大度を理解することは常に重要です。情報漏えいは、SQL インジェクションの問題と同じ扱いにはできない場合があります。
  5. 影響のあるソフトウェアのバージョンを特定する: 組織にインストールしたバージョンが影響を受けているか判断するため、脆弱性対象のソフトウェアバージョンを特定する必要があります。
  6. どのような構成のときに問題がトリガーされるのか特定する: 一部の脆弱性は特定の構成設定の下でのみ現れることがあります。
  7. 攻撃 / テスト時に使用された概念実証 (PoC) の攻略コードまたはペイロードを特定する: 多くの脆弱性発表では、脆弱性を浮き彫りにする攻略コードが一緒に公開されます。このデータが公開されている場合は、分析用に必ずダウンロードしておきます。これは、後で仮想パッチを開発するとき、およびテストするときに役立ちます。

仮想パッチ作成フェーズ

正確な仮想パッチの作成プロセスには、次の 2 つの主要ルールを適用します。

  1. フォールスポジティブをなくす: いかなる場合も、正当なトラフィックをブロックしない。
  2. フォールスネガティブをなくす: たとえ、検出を回避するための工作が攻撃者によって意図的に仕組まれていたとしても、いかなる攻撃も見逃さない。

これら 2 つのルールの両方を最小化するように注意する必要があります。両方の目標を 100% 満たすことはできないかもしれませんが、仮想パッチの本来の目的はリスクの緩和であることに留意します。"修正時間" を短縮することはできても、欠陥の完全な修正を実装できるとは限らないことをビジネスオーナーは理解する必要があります。

仮想パッチの手動作成

ポジティブセキュリティ (ホワイトリスト) 仮想パッチ (推奨ソリューション)

ポジティブセキュリティモデル (ホワイトリスト) は、独立した入力検証エンベロープをアプリケーションに提供する包括的なセキュリティメカニズムです。このモデルでは、有効な入力 (文字セットや長さなど) が指定され、指定内容に違反するものすべてが拒否されます。アプリケーション内のあらゆるページのあらゆるパラメーターに対してルールを定義することで、アプリケーションはコードから独立した、追加のセキュリティエンベロープによって保護されます。

ホワイトリスト ModSecurity 仮想パッチの例

ホワイトリスト仮想パッチを作成するには、想定される正常な入力値は何かを特定できなければなりません。準備フェーズで適切な監査ロギングを実装していれば、監査ログを確認することによって、想定される入力タイプの形式を特定できるはずです。このケースの場合、"reqID" パラメーターが受け入れるのは整数のみなので、次のような仮想パッチを使用できます。 

#
# "reqID"  という名前の 1 つのパラメーターのみを受け取ることを確認する
#
SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter - Duplicate Parameters Names Seen.',logdata:'%{matched_var}'"
  SecRule &ARGS:/reqID/ "!@eq 1"

#
# reqID のペイロードに整数のみが格納されることを確認する
#
SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:2,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'"
  SecRule ARGS:/reqID/ "!@rx ^[0-9]+$"

この仮想パッチは、指定されたページの reqID パラメーターを検査し、整数以外のあらゆる文字の入力を阻止します。

  • 注: ルール ID が適切に割り当てられ、バグ追跡システムで追跡されるようにする必要があります。
  • 注意: 仮想パッチ作成時に考慮すべき検出回避のベクトルは多数あります。検出回避の防止方法の詳細については、仮想パッチのベストプラクティスに関する OWASP のドキュメントを参照してください。

ネガティブセキュリティ (ブラックリスト) 仮想パッチ

ネガティブセキュリティモデル (ブラックリスト) は、有効トラフィックのみを許可するポジティブセキュリティとは対照的に、特定の既知の攻撃を検出するルールセットがベースです。

ブラックリスト ModSecurity 仮想パッチの例

次に、一般公開されているアドバイザリ(http://packetstormsecurity.com/files/119217/WordPress-Shopping-Cart-8.1.14-Shell-Upload-SQL-Injection.html) で提供されている PoC コード例を示します。 

http://localhost/wordpress/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php?reqID=1' or 1='1

ペイロードを見ると、攻撃者が一重引用符文字を挿入し、その後末尾に追加の SQL クエリロジックを付加しているのがわかります。このデータに基づいて、次のように一重引用符文字を無効とします。 

SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'"
  SecRule ARGS:/reqID/ "@pm '"

仮想パッチの適用には、ポジティブセキュリティとネガティブセキュリティのどちらの方法を使用するのが適切か

仮想パッチでは、ポジティブセキュリティモデル、ネガティブセキュリティモデルのどちらも使用できます。どちらを使用するかの決定は、状況といくつかの考慮事項に依存します。たとえば、ネガティブセキュリティルールは、通常、ポジティブセキュリティルールよりも実装に時間がかかりませんが、検出回避が発生する可能性が高くなります。

一方、ポジティブセキュリティルールは、ネガティブセキュリティルールよりも保護機能に優れていますが、多くの場合手動プロセスが必要となるため、スケーラビリティに欠け、大規模 / 動的なサイトでは管理が難しくなります。手動のポジティブセキュリティルールをサイト全体に適用することはできないかもしれませんが、脆弱性のアラートによって問題のあるロケーションが特定されている場合には、ポジティブセキュリティモデルを選択的に適用することが可能です。

特定の攻略行為専用の仮想パッチに関する注意

特定の攻略行為専用の仮想パッチを取り急ぎ作成するという安易な道を選ぶことは、避けるべきです。たとえば、認可された侵入テストで、あるページ上の脆弱性が特定され、次のような攻撃ペイロードがレポートで使用されたとします。 <script>alert('XSS Test')</script>

このペイロードそのものを単純にブロックする仮想パッチを実装することは、賢明ではありません。当座の保護機能はある程度確保されるかもしれませんが、長期的に見た場合、この保護の価値は大幅に低下します。

仮想パッチの自動作成

脆弱性の数が増すにつれて、パッチの手動作成が困難になり、自動的手段が必要になる場合があります。脆弱性が自動ツールを介して特定され、XML レポートが利用可能な場合は、自動プロセスを活用してその脆弱性データを仮想パッチに自動変換し、保護システムで使用することが可能です。以下に 3 つの例を示します。

実装 / テストフェーズ

新たに作成された仮想パッチを正確にテストするには、Web ブラウザー以外のアプリケーションの使用が必要となる場合があります。有用なツールをいくつか以下に示します。

テストステップ

  • 仮想パッチは、最初は、通常のユーザートラフィック (フォールスポジティブ) をブロックしないように "ログのみ" の構成で実装します。
  • 特定のツールまたは評価チームによって脆弱性が特定されている場合は、再テストを要請します。
  • 検出回避によって再テストに失敗した場合は、分析フェーズに戻って、問題のより適切な修正方法を特定します。

回復 / フォローアップフェーズ

  • 追跡システム内のデータの更新: 仮想パッチの実装を迅速化する必要がある場合でも、通常のパッチ管理プロセスで仮想パッチを追跡すべきです。つまり、適切な変更要求チケットなどを作成して、作成した仮想パッチの存在とその機能について文書化するようにします。チケットシステムを更新することは、脆弱性の種類ごとの "修正時間" メトリックを特定するためにも役立ちます。仮想パッチのルール ID 値が必ず適切にログに記録されるようにする必要があります。
  • 定期的な再評価: また、定期的に再評価を実施して、(実際のソースコードの修正によって Web アプリケーションコードを更新した場合に) 以前の仮想パッチを削除してもよいか、よいならいつ削除するかを確認します。調べたところ、多くの人々が、アプリケーションまたはデータベースが持つ機能よりも優れた特定 / ロギング機能が提供されるという理由で、仮想パッチをそのまま維持することを選択しています。
  • 仮想パッチアラートレポートの実行: 仮想パッチがトリガーされたかどうか / いつトリガーされたかを特定するためのレポートを実行します。それによって、ソースコードが修正されるまでの露出期間に関連した仮想パッチの価値が明らかになります。

参考資料

Authors and Primary Editors

Ryan Barnett (Main Author)
Josh Zlatin (Editor/Contributing Author)
Christian Folini (Review)

Other Cheatsheets

Developer Cheat Sheets (Builder)

Assessment Cheat Sheets (Breaker)

Mobile Cheat Sheets

OpSec Cheat Sheets (Defender)

  • Virtual Patching Cheat Sheet

Draft Cheat Sheets

Retrieved from "https://www.owasp.org/index.php?title=Virtual_Patching_Cheat_Sheet&oldid=203129"