テルアビブ大学とヘルズリヤ（イスラエル）の学際的センターの研究者グループ 新しい攻撃方法 (）、任意の DNS リゾルバーをトラフィック アンプとして使用できるため、パケット数に関して最大 1621 倍の増幅率が得られます（リゾルバーに送信されるリクエストごとに、被害者のサーバーに送信されるリクエストの数は 1621 個になります）。トラフィックに関しては最大 163 回です。
この問題はプロトコルの特殊性に関連しており、再帰クエリ処理をサポートするすべての DNS サーバーに影響します。 （CVE-2020-8616） （CVE-2020-12667） （CVE-2020-10995） и (CVE-2020-12662)、および Google、Cloudflare、Amazon、Quad9、ICANN などの企業のパブリック DNS サービス。 この修正は DNS サーバー開発者と調整され、製品の脆弱性を修正するためのアップデートが同時にリリースされました。 リリースで実装された攻撃保護
, , , .
この攻撃は、攻撃者が名前決定を委任される、これまでに見たことのない多数の架空の NS レコードを参照するリクエストを使用することに基づいていますが、応答内で NS サーバーの IP アドレスに関する情報を含むグルー レコードを指定していません。 たとえば、攻撃者は、攻撃者.com ドメインを担当する DNS サーバーを制御することによって、sd1.攻撃者.com という名前を解決するクエリを送信します。 攻撃者の DNS サーバーに対するリゾルバーの要求に応じて、IP NS サーバーの詳細を示さずに応答内で NS レコードを示すことにより、sd1.attacker.com アドレスの決定を被害者の DNS サーバーに委任する応答が発行されます。 前述の NS サーバーはこれまでに検出されたことがなく、その IP アドレスが指定されていないため、リゾルバーは、ターゲット ドメイン (victim.com) にサービスを提供している被害者の DNS サーバーにクエリを送信して、NS サーバーの IP アドレスを特定しようとします。
問題は、攻撃者が、存在しない架空の被害者サブドメイン名 (fake-1.victim.com、fake-2.victim.com、...fake-1000) を持つ繰り返しのない NS サーバーの膨大なリストで応答できることです。被害者.com）。 リゾルバーは、被害者の DNS サーバーにリクエストを送信しようとしますが、ドメインが見つからなかったという応答を受け取ります。その後、リスト内の次の NS サーバーを決定しようとし、すべての DNS サーバーを試行し終わるまでこれを繰り返します。攻撃者によってリストされた NS レコード。 したがって、XNUMX 人の攻撃者のリクエストに対して、リゾルバは NS ホストを特定するために膨大な数のリクエストを送信します。 NS サーバー名はランダムに生成され、存在しないサブドメインを参照するため、キャッシュから取得されず、攻撃者からの各リクエストにより、被害者のドメインにサービスを提供する DNS サーバーに対して大量のリクエストが発生します。
研究者らは、この問題に対するパブリック DNS リゾルバーの脆弱性の程度を調査し、CloudFlare リゾルバー (1.1.1.1) にクエリを送信すると、パケット数 (PAF、パケット増幅率) を 48 倍に増やすことが可能であると判断しました。 (8.8.8.8) - 30 回、FreeDNS (37.235.1.174) - 50 回、OpenDNS (208.67.222.222) - 32 回。 より顕著な指標が観察されるのは、
Level3 (209.244.0.3) - 273 回、Quad9 (9.9.9.9) - 415 回
SafeDNS (195.46.39.39) - 274 回、Verisign (64.6.64.6) - 202 回、
Ultra (156.154.71.1) - 405 回、Comodo Secure (8.26.56.26) - 435 回、DNS.Watch (84.200.69.80) - 486 回、Norton ConnectSafe (199.85.126.10) - 569 回。 BIND 9.12.3 ベースのサーバーの場合、リクエストの並列化により、ゲイン レベルは最大 1000 に達する可能性があります。Knot Resolver 5.1.0 では、ゲイン レベルは約数十倍 (24 ～ 48) になります。 NS 名は順番に実行され、XNUMX つの要求で許可される名前解決ステップ数の内部制限に基づいて実行されます。
防衛戦略には主に XNUMX つあります。 DNSSEC を備えたシステムの場合 使用します リクエストがランダムな名前で送信されるため、DNS キャッシュのバイパスを防ぐため。 この方法の本質は、DNSSEC による範囲チェックを使用して、権威ある DNS サーバーに接続せずに否定応答を生成することです。 より簡単な方法は、単一の委任されたリクエストを処理するときに定義できる名前の数を制限することです。ただし、この方法では、プロトコルで制限が定義されていないため、一部の既存の構成で問題が発生する可能性があります。
出所： オープンネット.ru