Hey, DNS! (HCL AppScan Domain Name Server の利用)

2020/7/24 - 読み終える時間: 3 分

DNS に関するセキュリティーテストの解説記事 Hey, DNS! (with HCL AppScan Domain Name Server) の翻訳記事です。

翻訳者注: 本記事は技術的詳細内容が含まれています。技術者による翻訳文の妥当性確認は行っていません。不明点等がある場合は、恐れ入りますが原文を参照願います。

Hey, DNS! (HCL AppScan Domain Name Server の利用)

2020年7月22日

著者: Shahar Sperling / Chief Architect at HCL AppScan

昔々、「動的解析」は「ブラックボックステスト」と呼ばれていました。昔の名前（Black-Box、White-Box、Glass-Box...）が懐かしいです。新しい名前には素敵な頭字語（DAST、SAST、IASTなど）が使われていますが、その名前は、その作業方法についての説明力としては不足しています。あるタイプのテストや別のタイプのテストを実行するときに直面する課題は、名前がテストオプションが実際にどのように動作するかを説明しているとはほど遠いことです。

Black-Box は、テスト対象を「ブラックボックス」として扱っていることを非常に明確に伝えています。中を見ることはできません。あなたは、ブラックボックスがあなたに公開することを選択したものだけに頼ることができます。私たちがテスト攻撃を実行するとき、アプリケーションが攻撃に対してどのように反応するかを「リフレクション」と呼びます。テストが成功したかどうかを示すのは、リフレクションの欠如であることがあります。

このリフレクションへの依存は、DAST が直面している大きな課題の 1 つです。これは、検出できる問題の種類を制限する要因となっています。いくつかのテストは、即時の応答(またはそれに続く一連の要求に対する応答)を作成し、それらはDASTが発見できる問題です。テストの中には、WebApp の実行フローを混乱させるように設計されているものもあります (意図的に反映の失敗を引き起こす) が、これらも DAST が検出できる問題です。

それ以外はどうでしょうか？

非同期検証メカニズムテストの影響

他のすべてではないかもしれませんが、数年前に導入された非同期検証メカニズムは役に立ちます。これらのテストの背後にある考えは、直接的なリフレクション (あるいはその欠如) に頼るのではなく、アプリケーションの他の外部から観測可能な動作に頼るということです。

これはどこで役に立つのでしょうか？例えば、コマンド実行のテストをするときです。私たちは、以下に説明されているアクションの一つを実行するコマンドを実行しようとします。これらのコマンドは、実行中のアプリケーションのコンテキストの外で実行され、多くの場合、それらに関連したレスポンス（例えば、HTMLへの直接的なリフレクション）がありません。通常の状況では、DAST スキャナはこれらの脆弱性を検出することはできません。

最初のクラスのテストでは、AppScan スキャナ自体に組み込まれた Web サーバーへの HTTP リクエストをトリガーしようとします。AppScanは、テストされたサーバーに特定のURLへのHTTPリクエストを開始させようとしますが、これは攻撃源を理解するのに役立ちます。また、外部ファイル挿入の脆弱性の検出も向上します。

ペイロード部分: http://:/AppScanMsg.html?varId=＜attack_id＞ (山括弧は意図的に全角にしています)

ここで、appscan_ip と port は、スキャナが実行されているマシンの IP と組み込み Web サーバーのポートです。attack_id の値は、送信された実際の攻撃を識別します。

これらのテストは非常に高い精度を持っていますが、失敗しやすいです。多くの場合、ネットワークのセグメンテーションにより、これらの要求がそもそも AppScan に到達しないようになっています。HTTP リクエストは実際にはサーバーによって生成されますが、その後、ネットワーク自体のファイアウォールやセグメンテーションルールによってブロックされることがあります。これはラボやステージング環境では非常に一般的です。ネットワークセグメントへのアクセスは許可されていても、セグメント内のマシンはセグメント外で HTTP トラフィックを生成することはできません。

HTTP トラフィックはエスケープできないかもしれませんが、DNS の性質上、DNS リクエストはそれがよく起こりえることです。そのため、第二のクラスのテストを含めることにしました。最初のテストと同様に、これらのテストはリクエストをトリガーしようとします。しかし、新しいテストでは、組み込みサーバーへの DNS ルックアップをトリガーしようとします。

DNS は連鎖したプロセスです。ある DNS サーバーがホスト名を IP に解決できない場合、接続されている他の DNS サーバーでそのホスト名を探そうとします。DNS リクエストは、ファイアウォールやゲートウェイ、その他のネットワークメカニズムによってブロックされることはほとんどありません。

その結果は高い精度で非常に良いのですが、キャッチがあります。多くのマシンでは、組織のポリシーにより、特定の DNS リゾルバへのルックアップを実行できません。これは、スキャナ内蔵の DNS サーバーをマシン上で設定しなければならないことを意味します。これは問題です。

解決策は、自動的に認識される DNS サーバーを作成することです。

AppScanドメインネームサーバー（ADNS）の導入

ADNS - AppScan Domain Name Server のご紹介です。オープンなインターネット上に鎮座するクラウドベースのサーバーで、インターネットベースのDNS サーバーを利用できるマシンであれば誰でもアクセス可能で、利用できるようになっています。これは、世界中のコンピュータの大多数を構成しています（物理的にインターネットに接続されていないコンピュータを除く）。HTTP トラフィックが遮断されている環境や、ファイアウォールによって遮断されている環境でも、通常は DNS トラフィックを通過させることができます。

その結果、テストの仕組みは次のようになります。

• ステップ 1: クラフトされたホストへのペイロードを持つ攻撃を作成する。

• ステップ2: テストされたサーバーはこのホスト名を調べる。

• ステップ 3: ADNSはこのルックアップの記録を受信して保持する。

• ステップ 4: AppScanは、ルックアップが行われたかどうかをADNSに問い合わせる。

シンプルさを維持し、ステップ 4 が成功することを確実にするために、DNS ルックアップを使用してクエリも行われます。そのため、インターネットへの直接アクセス（HTTPアクセス）がないAppScanインスタンスでも、DNS ルックアップが成功する確率が非常に高いため、このメカニズムを使用することができます。

前述したように、DNS の検索は細工されたホスト名に対して行われます。ホスト名は次のように構成されています。

vX-ping-＜variant_id＞-＜scan_GUID＞.securityip.appscan.com (山括弧は意図的に全角しています)

• securityip.appscan.com / securityip.appsechcl.com - これらは ADNS 自体を参照しています。この記事は「appsechcl」から「appscan」への移行期に書かれています。どちらかの名前が出てきます。この記事の目的のために、私は "appscan.com "を使用しています。
• variant_id - 特定の攻撃を識別するID
• scan_GUID - 特定のスキャンを識別するID。バリアントIDは1回のスキャンでは一意ですが、グローバルに識別可能なIDのためには、ランダムなスキャンIDも必要です。
• X - これは AppScan プロトコル(スキャナと ADNS 間の交換)の内部識別子です。

ペイロードは次のようになります。

v3-ping-11345?b697b0fb-06f5-4aab-a8d5-1867c7daa8c5.securityip.appscan.com

• 3 - 現在のプロトコルのバージョン
• 11345 - バリアント ID は送信された元のテストを識別します。
• b697b0fb-06f5-4aab-a8d5-1867c7daa8c5 - グローバルに一意なインスタンス ID。

ADNS はこれらのルックアップを待っており、それらの記録を保持しています。ADNS は解決されたホスト名 (例えば、ソースIP/ポート) 以外のものを保持しませんし、 リクエストの発信元を特定する方法もありません。ADNS はその後、次のように見える別のルックアップを待ちます。

v3-query-11345-b697b0fb-06f5-4aab-a8d5-1867c7daa8c5.securityip.appscan.com

これは、AppScan スキャナが生成するルックアップです。この名前を解決すると、ADNS IP アドレスまたは NXDOMAIN (Non-Existent Domain) が返されます。これは攻撃の検証段階です。サーバーが有効な IP アドレスを返す場合、攻撃は成功しています。そうでない場合、AppScanはテストされたアプリケーションが脆弱性がなかったことを登録します。

AppScan は様々なテストで ADNS を使用します。明らかなのはコマンド実行シナリオでの直接検索です。しかし、他のタイプのテストでも恩恵を受けることができます。例えば、リモートファイルインクルージョンです。古典的な DAST の検証は、アプリケーションを騙して、レスポンスの中に検出できる外部コンテンツを埋め込むように試みます。ADNS を使用して、外部 URL に ADNS ドメインを含めることができます。コンテンツは埋め込まれませんが、アプリケーションは少なくともホスト名を解決する必要があり、これが脆弱性の証明となります。

ADNS は、非リフレクションテストの精度の飛躍的な向上を表し、AppScan が検出するために使用できる脆弱性の種類の全体的な数を増やします。

私たちはこれを常に喜んでいます。

詳細

ADNS の詳細については、HCL Software に連絡してデモを予約してください。