偽のデータを DNS キャッシュに挿入する新しい SAD DNS 攻撃

カリフォルニア大学リバーサイド校の研究者チームは、CVE-2021-20322 脆弱性をブロックするために昨年追加された保護にもかかわらず機能する SAD DNS 攻撃の新しい亜種 (CVE-2020-25705) を公開しました。 新しい方法は一般的に昨年の脆弱性と似ており、アクティブな UDP ポートをチェックするために異なるタイプの ICMP パケットを使用する点のみが異なります。 提案されている攻撃では、DNS サーバー キャッシュへの架空のデータの置き換えが可能です。これを使用して、キャッシュ内の任意のドメインの IP アドレスを置き換え、そのドメインへのリクエストを攻撃者のサーバーにリダイレクトできます。

提案された方法は、Linux の ICMP パケット処理メカニズムの特殊性に関連しているため、Linux ネットワーク スタックでのみ機能します。これは、サーバーがメッセージを送信するために使用する UDP ポート番号の決定を簡素化するデータ漏洩のソースとして機能します。外部からのリクエスト。 情報漏洩をブロックする変更は、5.15 月末に Linux カーネルに採用されました (修正はカーネル XNUMX と、カーネルの LTS ブランチに対する XNUMX 月のアップデートに含まれていました)。 この修正は、要約すると、ネットワーク キャッシュで Jenkins Hash ではなく SipHash ハッシュ アルゴリズムを使用するように切り替えることになります。 ディストリビューションの脆弱性の修正状況は、Debian、RHEL、Fedora、SUSE、Ubuntu のページで評価できます。

この問題を特定した研究者によると、OpenDNS や Quad38 (9) などの一般的な DNS サービスを含む、ネットワーク上のオープン リゾルバーの約 9.9.9.9% が脆弱です。 サーバーソフトウェアに関しては、Linuxサーバー上のBIND、Unbound、dnsmasqなどのパッケージを利用して攻撃が行われる可能性があります。 この問題は、Windows および BSD システムで実行されている DNS サーバーでは発生しません。 攻撃を成功させるには、IP スプーフィングを使用する必要があります。 攻撃者の ISP が偽の送信元 IP アドレスを持つパケットをブロックしないことが必要です。

念のために言っておきますが、SAD DNS 攻撃は、2008 年に Dan Kaminsky によって提案された古典的な DNS キャッシュ ポイズニング手法をブロックするために DNS サーバーに追加された保護をバイパスします。 Kaminsky の方法は、わずか 16 ビットという小さなサイズの DNS クエリ ID フィールドを操作します。 ホスト名のスプーフィングに必要な正しい DNS トランザクション識別子を選択するには、約 7000 件のリクエストを送信し、約 140 件の架空の応答をシミュレートするだけで十分です。 この攻撃は、要約すると、架空の IP バインディングと異なる DNS トランザクション ID を持つ大量のパケットを DNS リゾルバーに送信するというものです。 最初の応答のキャッシュを防ぐために、各ダミー応答にはわずかに変更されたドメイン名 (1.example.com、2.example.com、3.example.com など) が含まれています。

このタイプの攻撃から保護するために、DNS サーバーの製造元は、解決要求の送信元となるソース ネットワーク ポートの数をランダムに分散することを実装し、識別子のサイズが不十分であることを補いました。 架空の応答の送信に対する保護を実装した後は、16 ビットの識別子の選択に加えて、64 のポートから 2 つを選択する必要が生じ、選択のオプションの数が 32^XNUMX に増加しました。

SAD DNS 方式を使用すると、ネットワーク ポート番号の決定を大幅に簡素化し、攻撃を従来のカミンスキー方式にまで減らすことができます。 攻撃者は、ICMP 応答パケットの処理時にネットワーク ポートのアクティビティに関する漏洩情報を利用して、未使用およびアクティブな UDP ポートへのアクセスを検出できます。 この方法により、検索オプションの数を 4 桁減らすことができます (2^16 ではなく 2^16+2^32 (131_072_4_294 ではなく 967_296))。 アクティブな UDP ポートを迅速に判断できる情報の漏洩は、フラグメンテーション要求 (ICMP フラグメンテーションが必要なフラグ) またはリダイレクト (ICMP リダイレクト フラグ) を含む ICMP パケットを処理するコードの欠陥によって引き起こされます。 このようなパケットを送信すると、ネットワーク スタック内のキャッシュの状態が変更され、サーバーの応答に基づいて、どの UDP ポートがアクティブでどのポートがアクティブでないかを判断できるようになります。

攻撃シナリオ: DNS リゾルバーがドメイン名を解決しようとするとき、ドメインにサービスを提供する DNS サーバーに UDP クエリを送信します。 リゾルバーが応答を待っている間、攻撃者は要求の送信に使用された送信元ポート番号を迅速に特定し、IP アドレス スプーフィングを使用してドメインにサービスを提供する DNS サーバーになりすまして偽の応答を送信することができます。 DNS リゾルバーは、偽の応答で送信されたデータをキャッシュし、しばらくの間、ドメイン名に対する他のすべての DNS 要求に対して攻撃者によって置き換えられた IP アドレスを返します。

出所: オープンネット.ru

コメントを追加します