DNS インフラストラクチャのリスクを軽減してクラウドのアタックサーフェスを保護

DNS インフラの管理を誤ると、特にクラウドのアタックサーフェスが拡大を続けている場合には、破壊的なサイバー攻撃のリスクにさらされる可能性があります。 この記事では、DNS の脆弱性、DNS 乗っ取り攻撃の影響、DNS セキュリティのベストプラクティス (Tenable の新しいプラグインがどのように役立つかなど) についてご紹介します。

多くの組織がドメイン名システム (DNS) インフラのセキュリティを見落としていますが、特にクラウドの導入を進めている場合において、これは重大な過ちです。 DNS レコードの管理を誤ると、攻撃者にアクティブでないサブドメインや忘れ去られたサブドメインを乗っ取られるかもしれません。 ひとたびサブドメインを支配すれば、ハッカーはさまざまな破壊的なサイバー攻撃を仕掛けることができます。

このブログでは、DNS プロトコルの仕組みを説明し、一般的な DNS の脆弱性とその影響の概要を述べ、検出、予防、軽減のベストプラクティスについて詳しく見ていきます。 また、新しくリリースされた Tenable Vulnerability Management、Tenable Web App Scanning、Tenable Attack Surface Management のプラグインが、DNS インフラのセキュリティ確保にどのように役立つかを説明します。

クラウドの発展によって DNS セキュリティの重要性が高まる理由

新しいクラウドサービスや SaaS アプリケーションを IT インフラに統合して、ユーザーや顧客に提供したいと考える組織はますます増えています。 このプロセスの一環として、組織は多くの場合、ユーザーや顧客がサードパーティのクラウドアプリケーションにアクセスするためのカスタムサブドメインを作成します。 

その作成のために、組織は新しい DNS レコードを作成する必要があります。 カスタムサブドメインが攻撃者に乗っ取られないようにするためには、これらの DNS レコードの追跡が欠かせません。 しかし、あいにく DNS インフラ管理は見落とされがちであり、組織のセキュリティチームにとって盲点となっています。 

DNS 解決の基本

DNS プロトコルは以前からインターネットインフラの重要な構成要素であり、数値の IP アドレスを人間が読める名前に変換する役割を持ちます。

DNS プロトコルは、以下の 4 つを含むさまざまなレコードタイプを提供します。

• 「A」レコードは、サブドメインと IPv4 アドレスと間の基本的な変換です。
• Canonical Name (CNAME) レコードは、1 つの IP アドレスにリンクされた 1 つのドメイン名を指す複数のドメインエイリアスを持つことを可能にします。 例えば、5 つのドメインエイリアスが example.com を指すようにできます。 example.com に結びついた IP アドレスが変更された場合、その DNS レコードを更新するだけで済み、 example.com を指す CNAME エイリアスの変更は不要です。 CNAME レコードは IP アドレスを直接指すことはなく、他のドメイン名のみを指します。 ターゲットのドメイン名は、エイリアスと同じドメイン名でも、異なるドメイン名でもかまいません。
• Mail Exchange (MX) レコードは、どのメールサーバーがドメインの受信 E メールメッセージの受け取りに責任を持つかを指定することによって、 E メールのトラフィックを整理します。
• Name Server (NS) レコードは、特定の DNS ゾーンでどの DNS サーバーが権限を持つかを特定します。 権限を持つ DNS サーバーには、すべてのレコードを備えた DNS ゾーンが含まれます。

サードパーティのサービスを組織のカスタムドメインにマッピングするために、サードパーティベンダーは、これら 4 タイプのレコードのいずれかを設定するよう要求します。 プロセスが完了すると、組織のトラフィックはカスタムドメイン経由で適切にルーティングされます。 

以下の図は、DNS 解決チェーンのどのキャッシュにも存在していない CNAME レコードに対して、DNS 解決の仕組みがどのように働くかの基本的な例を示しています。

^{DNS 解決チェーンのどのキャッシュにも存在していない CNAME レコードに対して、DNS 解決の仕組みがどのように働くかの基本的な例を示した図}

全体的な流れは、MX レコードや NS レコードのような別のタイプのレコードでも同様です。

DNS 乗っ取りの脆弱性を理解する

DNS 乗っ取りのリスクは、DNS レコードがダングリング状態のままになっている場合、つまり DNS レコードがアクティブでないサブドメインや削除されたサブドメインを指している場合に生じます。 これにより、誰でもサードパーティのクラウドサービスからこの DNS レコードを要求できるようになります。 

このような脆弱性の発端となる一般的なシナリオは次のようなものです。

1. ある組織の事業部門が、社内ユーザー向けにサードパーティのクラウドサービスを立ち上げます。
2. 続いてこの事業部門は、このサービスの DNS CNAME レコードを、正規のものだとわかりやすいよう「組織」が所有するドメインを使用して作成するように、IT 部門に依頼します。
3. その後、事業部門はこのサードパーティクラウドサービスの使用を停止することを決定しましたが、IT 部門に DNS ゾーンから DNS CNAME レコードを削除するよう依頼しませんでした。
4. 攻撃者を含む任意のユーザーは、クラウドサービスプロバイダーにカスタムサブドメインを要求し、それを、攻撃対象の組織のドメインの下で悪意のあるコンテンツをホストするように設定できます。

一例として、2 日間にわたる会議のようなイベントのために、AWS S3 ストレージバケット上で基本的な静的ウェブサイトをホストしたい組織を取り上げ、その組織が所有する mysuperstaticwebsite.acme.corp のようなサブドメインをマッピングしてみます。 AWS の公式ドキュメントに従うことで、サービスがプロビジョニングされ、意図したすべてのユーザーが利用できるようになります。

イベント終了後、組織は S3 でホストされているウェブサイトをオフラインにしましたが、カスタムサブドメインの DNS レコードを削除するのを忘れました。 

ウェブサイトには、S3 バケットが存在しないことを示す、次のような一般的なエラーメッセージが表示されるようになりました。

しかし、mysuperstaticwebsite.acme.corp の DNS レコードを見た攻撃者は、次のような設定を目にするはずです。

dig +short CNAME mysuperstaticwebsite.acme.corp mysuperstaticwebsite.s3-website.eu-west-3.amazonaws.com.

攻撃者は、この情報を利用することで、AWS コンソールにログオンし、eu-west-3 リージョンに mysuperstaticwebsite という名前の S3 バケットを作成し、https://mysuperstaticwebsite.acme.corp の正当なウェブサイトを閲覧していると思わせて人々を引き付けることができます。

この危険なシナリオは、CNAME レコードに限った問題ではありません。 MX レコード、NS レコード、A レコードも同様に脆弱です。 例えば、マスターカードの DNS 設定ミスは、az.mastercard.com に設定された NS レコードのひとつに誤記の問題があっただけだったため 5 年ほど気づかれないままでした。 akam.ne を使用したこのレコードは、実際に、登録可能な存在しないドメインをターゲットにしていました。 

DNS の乗っ取りは、ドメイン名の有効期限が切れ、所有する組織が与えられた期間内に更新しなかった場合にも起こります。 その場合、ハッカーを含む誰もがそのドメイン名を購入できるようになり、前の所有者は複数の攻撃シナリオにさらされることになります。

一度の乗っ取りによる数多くの影響

組織は大抵、ブランドの評判や顧客からの信頼を損なうだけにとどまらない、DNS 乗っ取り攻撃の潜在的な影響に気づいていません。 

侵害された DNS レコードの種類や、組織での使用状況に応じて、以下のような多くの悪用手法が組織のセキュリティに影響を及ぼす可能性があります。

• フィッシング: 攻撃者は正規の URL ドメイン名でホストされたリアルなフィッシングサイトを構築し、組織内外のユーザーを標的にすることができます。
• E メールの傍受: MX レコードは、E メールのインフラの非常に重要な要素です。 1 つまたはいくつかの MX レコードがダングリング状態のまま放置され、ターゲット DNS レコードが利用できなくなると、攻撃者が DNS レコードを乗っ取って、このサービスの以前の利用者に宛てた電子メールを受信する可能性があります。 これにより、大きな影響が生じかねません。 例えば、攻撃者がパスワードのリセット操作を実行したり、組織からアクティブなサービスにログインしたりできるようになる可能性があります。 
• Cookie トス: サブドメインを支配すると、攻撃者は親ドメインの Cookie を設定して、それを他のサブドメインに適用できるようになります。 他のアプリケーションでの Cookie の扱い次第では、攻撃者がさらなる攻撃を行いやすくなる可能性があります。
• クライアント側セキュリティのバイパス:
  • ウェブサイト管理者は、コンテンツセキュリティポリシー (CSP) によってブラウザが読み込めるリソースを制御できます。 侵害されたサブドメインが CSP の許可リストに含まれている場合、攻撃者はこの脆弱性を悪用して CSP のセキュリティ制御をバイパスし、クロスサイトスクリプティング (XSS) などのクライアント側攻撃を仕掛ける可能性があります。
  • オリジン間リソース共有 (CORS) ポリシーは、許可されたオリジンの中の脆弱なサブドメインを定義します。 オリジンとは URI スキーム、ホスト名、ポート番号の組み合わせであり、オリジンを CORS ポリシーに追加すると、指定されたウェブアプリケーション上でクロスサイトリクエストを実行することを許可されるソースが定義されます。 攻撃者は悪意のある JavaScript をホストし、CORS 設定を悪用して機密情報にアクセスしたり、正規ユーザーの代わりに操作を実行したりする可能性があります。
• クラウドリソースの侵害: 侵害された標的が、例えばストレージバケットやデータベースなどのクラウドリソースである場合、インフラの他の部分にも広範な影響が及ぶ可能性があります。 例えば、ウェブアプリケーションが乗っ取られたストレージバケット上の JavaScript 静的ファイルをまだ参照している場合、攻撃者が悪意のある JavaScript コンテンツをアップロードして、内部または外部の他のウェブアプリケーションに対して蓄積型 XSS 攻撃を行う可能性があります。 

脆弱なレコードが NS レコードであれば、リスクはさらに高くなります。 このタイプのレコードの場合、管理者は DNS ゾーン全体の管理をサードパーティサーバーに委任できます。 このレコードが侵害されると、攻撃者は委任されたゾーンに他の複数のレコードを作成できるようになります。

検出、予防、軽減の方法

DNS 乗っ取りの脆弱性の軽減策は難しくありません。多くは、DNS レコードのライフサイクル管理に関するベストプラクティスに従えば大丈夫です。 

最初は、以下のような失敗を防ぐために、外部サービスのプロビジョニングプロセスをしっかりと文書化して確立しておく必要があります。

• DNS レコードは作成されているが、サードパーティクラウドサービスの導入が済んでいない
• DNS レコードは作成され、サードパーティのクラウドサービスへの登録も済ませたが、カスタム DNS の設定が終わっていない
• サードパーティのクラウドサービスが終了したが、組織の DNS ゾーンから DNS レコードが削除されていない

こうした自体を避けるには、DNS レコードを作成する前に、必ずサードパーティのクラウドサービスの作成と設定を済ませておく必要があります。 サードパーティクラウドサービスが不要になったら、外部サービス設定を削除する前に DNS レコードを必ず削除します。 

サービスプロバイダとして SaaS アプリケーションを開発している場合は、顧客に対し、ドメイン名にカスタム DNS レコードを割り当てて自社のインフラにルーティングする前に、ドメイン名の所有権を検証するよう求めてください。 一般的なセキュリティ保護では、組織はサブドメインの DNS ゾーンに TXT DNS レコードを追加して、サブドメインの所有者であることを確認する必要があります。 また、攻撃者が以前の CNAME レコードを再利用してサブドメインを乗っ取ることを防ぐために、それぞれの顧客が使用するランダムでユニークな CNAME レコードを生成することもできます。

攻撃者は、組織のアタックサーフェスを分析する際に、その組織に関連する DNS レコードを列挙して、ダングリング状態のレコードが存在するかをチェックします。 そのために、攻撃者は次の 3 種類の問題を探します。

• HTTP レスポンスを提供するダングリング状態のサービス。 こうしたサービスには有効で解決可能な DNS レコードもありますが、脆弱なサービスのフィンガープリンティングに使用できるデフォルトの HTTP レスポンスも提供します。
• DNS 解決に失敗したダングリング状態のサービスには、ほとんどの場合において、解決不可能な DNS レコードをターゲットにした CNAME レコードがあり、DNS リゾルバによって NXDOMAIN エラーが返されます。
• 割り当てられていない IP アドレスを対象とするダングリング状態のサービス。 攻撃者は、例えば、パブリッククラウドインフラ上の Erastic IP アドレスを要求できます。

Tenable Vulnerability Management 内の Tenable Attack Surface ManagementとTenable Web App Scanningの機能を活用すれば、DNS のセキュリティ問題を包括的に評価し、修正できます。 Tenable Attack Surface Management の機能に加えて、プラグイン 114146 (Subdomain Takeover) と 114572(Danging DNS Record) を活用することで、Tenable Web Application Scanning のユーザーは、サブドメインが HTTP ベースのダングリングレコードを標的にしているかどうかを迅速に確認し、攻撃者が悪用する前にこれらの問題の修正を試みることができます。 

まとめ

組織のアタックサーフェスを管理するには、DNS インフラの堅牢な管理が必要です。 DNS レコードはクラウド導入初期の遺物のように思えるかもしれませんが、最新のアーキテクチャの複雑化とクラウドサービスの急速な進化により、DNS のインフラ管理はこれまで以上に重要な意味を持つようになっています。

攻撃者は DNS の脆弱性を悪用する際、攻撃チェーンを構築して、ユーザーセッションを侵害したり、機密データを流出させたり、レガシーサービスになりすましたりするかもしれません。 そのため、組織は事前対策型のアプローチを採用し、DNS のプロビジョニングと管理の堅牢なプロセスを採用する必要があります。