DNSSECリソースを枯渇させる新たな脆弱性の修復

Cloudflareは、業界全体で複数のベンダーが協業する、この2つの重大なDNSSEC脆弱性を軽減するための取り組みに携わっています。これらの脆弱性は、DNS解決サービスを提供する重要なインフラストラクチャに重大なリスクをもたらしました。Cloudflareは、当社のパブリックリゾルバ1.1.1.1サービスを利用することで、誰でも無料で使用できるDNS解決を提供します。Cloudflareのパブリックリゾルバ1.1.1.1サービスの軽減策は、これらの脆弱性が公表される前に適用されています。Unbound（オープンソースソフトウェア）を使用する内部リゾルバは、これらの脆弱性を修正する新しいソフトウェアバージョンがリリースされた後、迅速にアップグレードされました。

CloudflareのDNSインフラストラクチャはこれら2つの脆弱が公表される前にすべてが保護されており、現在も安全です。これらの脆弱性は、当社の権威DNSまたはDNSファイアウォール製品には影響を与えません。

現在、主要なDNSソフトウェアベンダーはすべて、ソフトウェアの新バージョンをリリースしています。他のすべての主要なDNSリゾルバープロバイダーも、適切な軽減策を適用しています。お客様の環境でまだDNSリゾルバーソフトウェアの更新をされていない場合、今すぐ更新してください。

背景

一般にDNSSECと呼ばれるドメインネームシステム（DNS）セキュリティ拡張機能は、認証機能と整合性機能を追加するDNSプロトコルの拡張機能です。DNSSECは、DNS応答が本物であることを検証するための鍵と署名を使用します。DNSSECプロトコルはその仕様上、可用性を優先する特定の要件のために、DNSリゾルバーの検証のための複雑さと計算コストの増加を犠牲にしています。このブログで説明した脆弱性の軽減策では、検証側のリソースの枯渇を避けるために、これらの要件を緩和するローカルポリシーの適用が必要となります。

DNSおよびDNSSECプロトコルの設計は、「貴方が自分ですることに関しては厳密に、貴方が他人から受けることに関しては寛容に」というロバストネス原則に従っています。この原則に従ったプロトコル要件を悪用した脆弱性が過去に数多く存在しました。悪意のある行為者は、これらの脆弱性を悪用してDNSインフラストラクチャを攻撃する可能性があります。この場合、複雑な構成でDNSSEC応答を作成することで、DNSリゾルバーに余分な負荷を与えます。多くの場合、私たちはプロトコルが適応し進化する柔軟性と、運用するサービスの安定性とセキュリティを守る必要性との間で、実用的なバランスを取らなければならない状況に直面します。

Cloudflareのパブリックリゾルバー1.1.1.1は、プライバシー中心のパブリックリゾルバーサービスです。ネットワーク外で運用されている権威DNSサーバーの保護に加え、自社のインフラストラクチャの保護を目的としたより厳格な検証と制限を使用してきました。そのため、解決に失敗したという苦情を受けることがよくあります。経験上、厳しい検証と制限は、特にDNSドメインが不適切に設定されている場合、いくつかのエッジケースで可用性に影響を与える可能性があることがわかっています。しかし、こうした厳格な検証と制限は、DNSインフラストラクチャ全体の信頼性と回復力を向上させるために必要です。

脆弱性と軽減方法については、以下の説明をご覧ください。

「KeyTrap」脆弱性（CVE-2023-50387）

はじめに

DNSSECで署名されたゾーンには複数のキー（DNSKEY）を含めることができ、DNSの応答のリソースレコードセット（RRSET）には複数の署名（RRSIG）が含まれることがあります。鍵のロールオーバー、アルゴリズムのロールオーバー、複数の署名者によるDNSSECなどをサポートする場合に、複数の鍵と署名が必要になります。DNSSECプロトコルは仕様上、DNS応答を検証する際に、鍵と署名のあらゆる組み合わせ試すことをDNSリゾルバーに要求しています。

検証中、リゾルバはすべての署名のキータグを調べ、署名に使用された関連するキーを見つけようとします。鍵タグは、鍵のリソースデータ（RDATA）のチェックサムとして計算された符号なしの16ビットの数値です。鍵タグは、署名を作成したと思われる鍵と署名を効率的にペアリングできるようにするためのものです。ただし、鍵タグは一意ではなく、複数の鍵が同じ鍵タグを持つ可能性があります。悪意のある行為者は、同じ鍵タグを持つ複数の鍵と複数の署名を含むDNS応答を簡単に作成することができますが、そのどれもが検証できない可能性があります。検証リゾルバーは、この応答を検証しようとする際に、すべての組み合わせ（鍵の数×署名の数）を試行する必要があります。これにより、検証リゾルバーの計算コストが何倍にも増え、すべてのユーザーのパフォーマンスが低下します。これは、KeyTrapの脆弱性として知られています。

この脆弱性には、1つの鍵で複数の署名を使用する、1つの署名に鍵タグが競合する複数の鍵を使用する、親DS（Delegation Signer）レコードに追加された対応するハッシュを持つ複数の鍵を使用する、などの変種があります。

軽減

私たちはゾーンカットで受け入れる鍵の最大数を制限しています。（ゾーンカットとは、親ゾーンが子ゾーンに権限委任を行う場所のことで、例えば「.com」ゾーンはcloudflare.comの管理をCloudflareのネームサーバに委任する場合です）。この制限がすでに導入され、プラットフォームに他のさまざまな保護が構築されている場合も、権威DNSサーバーからの悪意のあるDNS応答を処理するには、依然として計算コストがかかることが判明しました。

この脆弱性に対処し、さらに軽減するために、私たちはRRSETごとの署名検証の制限と、解決タスクごとの合計署名検証の制限を追加しました。1件の解決タスクには、1つのDNS問い合わせに応答するために、外部の権威DNSサーバーへの複数の再帰的クエリーが含まれる場合があります。これらの制限を超えるクライアントクエリは解決に失敗し、拡張DNSエラー（EDE）コード0応答を受け取ることになります。さらに、この脆弱性を悪用しようとする攻撃を検出できるようにするメトリクスを追加しました。

NSEC3反復および最も近いエンクロージャー証明の脆弱性（CVE-2023-50868）

はじめに

NSEC3は、認証済みの不在証明に対する代替のアプローチです。認証済みの不在証明についての詳細はこちらをご覧ください。NSEC3は、ゾーンの列挙を防ぐために、DNS名を直接使用するのではなく、DNS名から得られるハッシュを使用し、標準はハッシュ計算の複数の反復をサポートしています。ただし、ハッシュ計算の入力として完全なDNS名が使用されるため、初期値を超えてハッシュ反復数を増やしても、追加の値は得られないため、RFC9276では推奨されていません。この複雑さは、最も近いエンクロージャー証明を見つける間にさらに膨れ上がります。権威DNSサーバーからの悪意のあるDNS応答は、不要なハッシュ計算を行うことにより、検証リゾルバーのコンピューティングリソースを使い果たすために複数のDNSラベルを持つ高いNSEC3反復回数と長いDNS名を設定する可能性があります。

軽減

この脆弱性について、当社はKeyTrapと同様の軽減手法を適用しました。1つのDNSの問い合わせに応答するために、解決タスクごとの総ハッシュ計算の上限を追加しました。同様に、この上限を超えるクライアントからのクエリは解決に失敗し、EDEコード27の応答を受け取ることになります。また、ハッシュの計算を追跡するメトリクスも追加し、この脆弱性を悪用しようとする攻撃を早期に検出できるようにしました。

タイムライン

クレジット

KeyTrapの脆弱性を発見し、責任ある開示を行ってくれたドイツ国家研究センターATHENEのElias Heftrig氏、Hya Schulmann氏、Niklas Vogel氏、Michael Waidner氏に感謝の意を表します。

NSEC3反復および最も近いエンクロージャー証明の脆弱性を発見し、責任ある開示を行ってくれたインターネットシステムズコンソーシアム（ISC）のPetr špaék氏に感謝の意を表します。

さまざまな関係者間の調整を促進してくれたQuad9およびDNS運用分析研究センター（DNS-OARC）のJohn Todd氏に感謝の意を表します。

そして最後に、インターネットの耐障害性と安全性を確保するという共通の目標に向けて取り組んできた、さまざまなDNSベンダーやサービスプロバイダーを代表するDNS-OARCコミュニティメンバーに感謝の意を表します。