深刻なセキュリティ: 意図的なタイプが DNS セキュリティをどのように改善するか

何年にもわたって、私たちは 書かれた および 話 Naked Security で何度も DNS の厄介な問題について ハイジャック.

おそらくご存じのとおり、DNS は ドメインネームシステム、インターネットの「電話帳」または「地名辞典」と表現されることがよくあります。

言葉に慣れていない場合 地名集、それはあなたが見上げるアトラスの後ろにあるインデックスを指します。 モンロビア、リベリア 便利なアルファベット順のリストで、次のように言います 184 - C4. これは、184 ページに直進し、地図の上部にある C の文字からグリッド線をたどり、左側の数字の 4 を横切るように指示します。 線が交わるところに、モンロビアがあります。

ほとんどのユーザーにとって、ほとんどの DNS ルックアップはサーバー名を含めて送信され、A レコードまたは AAAA レコードと呼ばれるものを含む応答が返されるように求めます。

(A レコードは、次のような 32 ビット IPv4 インターネット番号に使用されます。 203.0.113.42; AAAA レコードは、次のような 128 ビットの IPv6 アドレスに対する同等の回答です。 2001:db8:15a:d0c::42 – この記事では、A レコードと IPv4 番号のみを使用しますが、どちらの場合もルックアップ プロセスに同じセキュリティの問題が適用されます。)

架空のドメイン名を検索する例を次に示します。 naksec.test DNS トラフィックを追跡してユーザーに教えるために特別に作成された DNS サーバーを介して。

古い学校の Linux ツールを使用しました dig、の略 ドメイン インターネット 痴漢、単純な DNS 要求を生成します (dig デフォルトでは、必要なサーバーの A レコードを検索します。

$ dig +noedns @127.42.42.254 naksec.test ;; 質問セクション: ;naksec.test. で ;; 回答セクション: NAKSEC.TEST. 5 で 203.0.113.42 ;; クエリ時間: 1 ミリ秒 ;; サーバー: 127.42.42.254#53(127.42.42.254) (UDP) ;; 日時: 23 年 14 月 38 日月曜日 42:2023:56 GMT ;; MSG サイズ rcvd: XNUMX

DNS サーバーがどのようにリクエストを処理したかを次に示します。着信リクエストの XNUMX 進ダンプと、返された成功した応答が示されています。

---> 127.0.0.1:57708 から 127.42.42.254:53 へのリクエスト ---> 00000000 62 4e 01 20 00 01 00 00 00 00 00 00 06 6e 61 6b |bN. .........nak| 00000010 73 65 63 04 74 65 73 74 00 00 01 00 01 |sec.test..... | DNS ルックアップ: naksec.test の A レコード ==> A=203.0.113.42 <--- 127.42.42.254:53 から 127.0.0.1:57708 への応答 <--- 00000000 62 4e 84 b0 00 01 00 01 00 00 00 00 06 6e 61 6b |bN........ナック| 00000010 73 65 63 04 74 65 73 74 00 00 01 00 01 06 4e 41 |sec.test......NA| 00000020 4b 53 45 43 04 54 45 53 54 00 00 01 00 01 00 00 |KSEC.TEST.......| 00000030 00 05 00 04 cb 00 71 2a |......q* |

パフォーマンス上の理由から、ほとんどの DNS 要求は UDP を使用することに注意してください。 ユーザーデータグラムプロトコル、送信と希望に基づいて機能します。通信したいサーバーでUDPパケットを発射し、応答が返ってくるかどうかを待ちます。

これにより、UDP は、その大きないとこである TCP よりもはるかに単純で高速になります。 伝送制御プロトコル、その名前が示すように、UDP が処理しない多くの詳細を自動的に処理します。

特に、TCP はデータが失われたことを検出し、それを再要求します。 データのチャンクが正しい順序で到着するようにします。 一度セットアップすれば、同時に送信と受信に使用できる単一のネットワーク接続を提供します。

UDP には「接続」の概念がないため、要求と応答は基本的に独立して移動します。

• DNS リクエストが DNS サーバーに到着する 独自の UDP パケットで。
• DNSサーバーは記録を保持します どのコンピュータがその特定のパケットを送信したか。
• サーバーは、返信する回答を見つけようとします。 または存在しないと判断します。
• サーバーは応答を送信します XNUMX 番目の UDP パケットを使用して元の送信者に送信します。

オペレーティング システムまたはネットワークのレベルから見ると、上記の XNUMX つの UDP パケットは独立したスタンドアロンの伝送であり、同じデジタル接続の一部として結び付けられているわけではありません。

各応答を送信するクライアントを記憶するのはサーバー次第です。 どの応答が最初に送信した要求に関連しているかを把握するのは、クライアント次第です。

どうして確信できますか？

この時点で、特に上記の DNS 要求と応答の小さいサイズを見ると、「送信中に文字化けしたり、誤って送信されたりしたものではなく、正しい応答と一致したことをクライアントがどのように確認できるのか」と疑問に思うでしょう。偶然か意図的なものか？」

残念ながら、ほとんどではないにしても多くの DNS 要求 (特にサーバーからサーバーへの要求で、最初に要求したサーバーが答えを知らず、応答を作成するために知っているものを見つける必要がある場合) は暗号化されていません。それ以外の場合は、あらゆる種類の暗号認証コードでラベル付けされています。

実際、デフォルトでは、DNS 要求には単一の「識別タグ」が含まれています。これは、DNS データ形式のドキュメントでは単に次のように呼ばれています。 ID.

驚くべきことに、公式のインターネット RFC (コメントを求める）DNS仕様として機能するドキュメントはまだです RFC 1035 (私たちは現在、9000 年代半ばの RFC に取り組んでいます)、1987 年 35 月までさかのぼります。ちょうど XNUMX 年前です!

当時、帯域幅と処理能力の両方が不足していました。典型的な CPU 速度は約 10MHz でした。 デスクトップ コンピュータには約 1M バイトの RAM がありました。 まったくオンラインに接続できる組織のインターネット アクセス速度は、多くの場合、56kbits/sec または 64kbits/sec であり、全員で共有されていました。 また、1200 ビット/秒は、当時のダイヤルアップ モデムを介した個人接続の手頃な選択肢でした。

そのため、DNS 要求および応答ヘッダーは、RFC 12 のかわいい ASCIIアート 明確にする：

 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+ --+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QR| オペコード |AA|TC|RD|RA| Z | R コード | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | アンカウント | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

上記の XNUMX 進ダンプで動作中の ID を確認できます。ここでは、要求パケットと応答パケットの両方が同じ XNUMX 文字で始まります。 bN、16ビット識別子に対応 62 4e XNUMX進数で。

非常に大まかに言えば、これらの 16 ビットは、公式の DNS プロトコルが「認証」または「エラー検出」によって提供するものと同じです。

当て推量による干渉

ご想像のとおり、通常の DNS トラフィックのエンド ツー エンドのシンプルさを考えると、いわゆる ミドルボックス or スキャニング プロキシ ネットワーク トラフィックを傍受、調査、変更できる人は、DNS トラフィックに簡単に介入できます。

これには、故意に不正確な情報を提供する返信を送り返すことも含まれます。たとえば、IT チームが、マルウェアが散らばっていることがわかっているサーバーからユーザーをリダイレクトするなどです。

また、児童虐待のコンテンツなどの違法コンテンツのブロックリストに載っているため、一部のサーバーが存在せず、正常に動作していても、存在しないと報告することを要求する、お住まいの国の法律に準拠している ISP が含まれる場合もあります。

しかし、一見したところ、このような非常に弱い DNS ID タギングは、些細なことのようにも見えます。 ネットワーク トラフィックをまったく可視化できない攻撃者に対しても ユーザーまたはサーバーで偽の DNS 応答を起動する…

…危険なほど高い確率で成功します。

攻撃者が、ネットワーク上の誰かが定期的に訪問することを知っている場合 naksec.test、そのサーバーは、偽のニュース、危険な更新、または不正な JavaScript コードを埋め込むためのジューシーな場所のように見えるかもしれません.

攻撃者がハッキングできない場合 naksec.test サーバー自体、質問に答えると主張する作成された ID タグを使用して、定期的かつ頻繁に UDP パケットを DNS サーバーに送信した場合はどうなるでしょうか。 naksec.test"？

そうすることで、彼らは DNS 要求をハイジャックし、偽の応答を提供し、その結果、Web サイトへの次の訪問を誤った方向に導くことができる可能性があります。 naksec.test まったくサーバー。

ある程度の運が必要

もちろん、彼らは少し幸運になる必要がありますが、毎回真実のDNS応答を取得する必要があるのに対し、成功する必要があるのはXNUMX回だけであるため、全体的なチャンスを高めるために何度も何度も試すことができます.

成功するには、不正な DNS 応答を送信する必要があります。

• あなた自身のサーバーがまだ質問に対する答えを知らなかった期間中。 DNS 応答には、TTL と呼ばれる 32 ビットの数値が含まれています。 有効期間、これは、反対側が回答を再利用し続けることができる期間を示しています。 あなたまたは ytour ネットワーク上の他の誰かが要求した場合 naksec.test 最近、DNS サーバーのキャッシュに回答がある場合があります。 それ以上のルックアップは必要なく、攻撃者がハイジャックするための送信要求もありません。
• あなたがリクエストを送信してから、正式な返信が外部から返ってくるまでの間。 昔でさえ、DNS ルックアップ時間が数秒を超えることはめったにありませんでした。 今日では、ミリ秒単位で測定するのが最適です。
• 最初の 16 ビットに正しい数値が含まれています。 65536 (2¹⁶) 異なる値を 16 ビットに変換するため、攻撃者は多少の幸運に恵まれる必要があります。 しかし、今日のネットワーク帯域幅では、一度に 65536 の異なる偽の応答を送信して、考えられるすべての ID 番号をカバーするには、ほんの一瞬しかかかりません。

幸いなことに、まともな DNS サーバーは、デフォルトでハイジャックを困難にするための追加の措置を講じています。

少なくとも、それは 2008 年頃から彼らが行ってきたことです。 故ダン・カミンスキー 当時の多くの DNS サーバーは、固定の UDP ポート (ほとんどの場合、正式に DNS に割り当てられたポート 53) で着信要求をリッスンするように構成されているだけではなかったと指摘しました…

…しかし、固定ポートでインバウンド応答を受信することもできます。トラフィックに適切な対称性を作成するためだけに、多くの場合ポート 53 も使用します。

両方向に固定ポートを使用する理由は、おそらくプログラミングを簡単にするためでした。 常に同じ UDP ポート番号で応答をリッスンすることにより、どの応答に対してどのポートを開く必要があるかを追跡する必要がなくなります。 これは、DNS ソフトウェアの要求ハンドラーと応答生成コンポーネントが独立して動作できることを意味します。 リクエスト リスナーは、返信の送信者に「この特定の返信は、通常のポートではなく、特別なポートに戻る必要があります」と伝える必要はありません。

ポート番号を追加の ID として使用する

最近では、ほとんどすべての UDP ベースの DNS サーバーは、いつものようにポート 53 をリッスンしますが、DNS リクエスターが使用する、いわゆる「ソース ポート」を追跡します。これはランダムに選択されると予想されます。

UDP ソース ポートは、昔ながらのオフィスの電話交換機の「内線番号」に少し似ており、ユーザーとネットワークが要求を互いに区別できるようにするために使用することを目的としています。

インターネット プロトコル ポート (TCP も使用) は 1 から 65535 まで実行できますが、ほとんどのアウトバウンド接続はソース ポート 1024 から 65535 のみを使用します。これは、通常、ポート番号 1023 以下がシステム権限を持つプロセス用に予約されているためです。

DNS ルックアップの送信者は、各リクエストの開始時に真にランダムな 16 ビット ID を挿入するだけでなく、関連する応答をリッスンする真にランダムな UDP ソース ポート番号を選択する必要があるという考えです。

これにより、詐欺師が上記の「幸運を乗っ取る」リストに追加しなければならない推測のレベルが追加されます。つまり、これらすべてのボックスにチェックを入れる偽の返信を送信する必要があります。

• 最近尋ねられたクエリである必要があります。 通常、過去数秒以内です。
• ローカル サーバーのキャッシュにないルックアップである必要があります。 通常、過去数分以内に他の誰もそれについて質問しなかったことを意味します。
• 正しい 16 ビット ID 番号が必要です データパケットの開始時。
• 正しい宛先ポートに送信する必要があります 関連するサーバーの IP 番号で。

そしてもう一つ

実際、DNS リクエスタが、基礎となる DNS プロトコルを変更せずに、したがって (ほとんどの場合) 何も壊さずに実行できる別のトリックがあります。

このトリックは、驚くべきことに、 最初に提案された 2008 年に、輝かしいタイトルの論文で 0x20 ビット エンコーディングによる DNS 偽造耐性の向上: LeeT クエリによるセキュリティ。

このアイデアは奇妙に単純で、DNS プロトコルの XNUMX つの詳細に依存しています。

• すべての DNS 応答には、最初に元のクエリ セクションを含める必要があります。 当然のことながら、クエリには空の回答セクションがありますが、返信には元の質問を反映する必要があります。これにより、リクエストと返信が誤って混同されないようにすることができます。
• DNS に関する質問はすべて、大文字と小文字が区別されません。 求めるかどうか naksec.testまたは NAKSEC.TESTまたは nAksEc.tESt、同じ答えが得られるはずです。

現在、DNS は大文字と小文字を区別しないため、元のクエリを繰り返す応答の部分で同じスペリングを使用する必要があるというプロトコルには何もありません。

ただし、RFC 1035 では大文字と小文字を区別しない比較を行う必要がありますが、 実際にケースを変更しないでください リクエストで受け取ったテキスト名、または返信で使用するために独自のデータベースから取得したテキスト名。

つまり、リクエストを受け取った場合、 nAKsEC.tEST、データベースには次のように保存されています NAKSEC.TESTの場合でも、これら XNUMX つの名前は同一と見なされ、一致します。

しかし、答えを定式化するとき、RFC 1035 は次のように提案しています。 返信に入れるデータの大文字と小文字を変更しないでくださいDNS で要求される大文字と小文字を区別しない比較のおかげで、見栄えがよくなり、反対側でも一致する場合でも、.

したがって、DNS 要求を送信する前に文字の大文字と小文字をランダムに混同すると、ほとんどの DNS サーバーは、ここに示すように、独自のデータベースがサーバーの名前を別の方法で格納している場合でも、その奇妙な文字のマッシュアップを忠実に反映します。 :

$ dig +noedns @127.42.42.254 nAkSEc.tEsT ;; 質問セクション: ;nAkSEC.test. で ;; 回答セクション: NAKSEC.TEST. 5 で 203.0.113.42 ;; クエリ時間: 1 ミリ秒 ;; サーバー: 127.42.42.254#53(127.42.42.254) (UDP) ;; 日時: 23 年 14 月 40 日月曜日 34:2023:56 GMT ;; MSG サイズ rcvd: XNUMX

私たちのDNSサーバーは名前を保存します naksec.test すべて大文字であるため、返信の回答セクションにはフォーム内の名前が含まれます NAKSEC.TEST、その IPv4 番号 (A レコード) とともに 203.0.113.42.

ただし、DNS サーバーが返す応答の「クロスチェックのために返されたクエリ データは次のとおりです」の部分では、DNS ルックアップで最初に使用された大文字と小文字のマッシュアップが保持されます。

---> 127.0.0.1:55772 から 127.42.42.254:53 へのリクエスト ---> 00000000 c0 55 01 20 00 01 00 00 00 00 00 00 06 6e 41 6b |.U. .........nAk| 00000010 53 45 63 04 74 45 73 54 00 00 01 00 01 |SEc.tEsT..... | DNS ルックアップ: nAkSEc.tEsT の A レコード ==> A=203.0.113.42 <--- 127.42.42.254:53 から 127.0.0.1:55772 への応答 <--- 00000000 c0 55 84 b0 00 01 00 01 00 00 00 00 06 6e 41 6b |.U.........nAk| 00000010 53 45 63 04 74 45 73 54 00 00 01 00 01 06 4e 41 |SEc.tEsT......NA| 00000020 4b 53 45 43 04 54 45 53 54 00 00 01 00 01 00 00 |KSEC.TEST.......| 00000030 00 05 00 04 cb 00 71 2a |......q* |

追加のセキュリティ タグ付け、無料

ビンゴ！

DNS ルックアップで追加できる「識別タグ付け」がいくつかあります。

ランダムに選択された 15 ビット程度の送信元ポートと、ランダムに選択された 16 ビットの ID 番号データに加えて、要求者はドメイン名の各アルファベット文字の大文字と小文字を選択できます。

naksec.test さらに10ビット分のランダムな「タグ付け」のために、それぞれ大文字または小文字で書くことができる10文字が含まれています。

推測するこの追加の詳細を使用して、攻撃者はタイミング、UDP ポート番号、ID タグの値、およびドメイン名の大文字化について幸運をつかむ必要があります。受け入れます。

ちなみに名前は 0x20 エンコード 上記はちょっとした冗談です: 0x20 頭数では 00100000 バイナリで、そのバイトの孤立したビットは、ASCII エンコーディング システムで大文字と小文字を区別するものです。

文字 A 〜へ I、たとえば、0x41から0x49として出てきますが、 a 〜へ i 0x61 から 0x69 として出てきます。

 ASCII テキストとしての ASCII エンコーディング チャート +------+------+------+------+------+------+- --+------+ |00 ^@ |10 ^P |20 |30 0 |40 @ |50 P |60 ` |70 p | |01 ^A |11 ^Q |21 ! |31 1 |41 A |51 Q |61 A |71 Q | |02 ^B |12 ^R |22 " |32 2 |42 B |52 R |62 b |72 r | |03 ^C |13 ^S |23 # |33 3 |43 C |53 S |63 c |73 s | |04 ^D |14 ^T |24 $ |34 4 |44 D |54 T |64 日 |74 t | |05 ^E |15 ^U |25 % |35 5 |45 E |55 U |65 e |75 u | |06 ^F |16 ^V |26 & |36 6 |46 F |56 V |66 f |76 v | |07 ^G |17 ^W |27 ' |37 7 | 47 G |57 W |67 g |77 w | |08 ^H |18 ^X |28 ( |38 8 |48 H |58 X |68 h |78 x | |09 ^I |19 ^Y |29 ) |39 9 |49 私 |59 年 |69 私 |79 年 | |0A ^J |1A ^Z |2A * |3A : |4A J |5A Z |6A j |7A z | |0B ^K |1B ^ [ |2B + |3B ; |4B K |5B [ |6B k |7B { | |0C ^L |1C ^ |2C , |3C < |4C L |5C |6C |7C | | |0D ^M | 1D ^] |2D - |3D = |4D M |5D ] |6D m |7D } | |0E ^N |1E ^^ |2E . |3E > |4E N |5E ^ |6E n |7E ~ | | 0F ^O |1F ^_ |2F / |3F ? |4F O |5F _ |6F o |7F | +------+------+------+--- ---+------+------+------+------+

つまり、0x41+0x20 を加算して 0x61 を取得すると、 A に a; 0x69-0x20 を減算して 0x49 を取得すると、次のようになります。 i に I.

なぜ今なのか？

あなたは今、疑問に思っているかもしれませんが、 「なぜ今、そのアイデアが 15 年前に登場したとしても、それが実際に何の役にも立たないのでしょうか?」

私たちの突然の関心は、たまたま、 最近の公開メール Google の技術者から、この昔ながらのセキュリティ トリックを使用した 2022 年の実験が実際に展開されたことを認めています。

以前に発表したように、Google パブリック DNS は、権限のあるネームサーバーに送信される DNS クエリ名の大文字と小文字のランダム化を有効にするプロセスを進めています。 北米、ヨーロッパ、アジアの一部の地域に展開し、DNS over TLS でカバーされていない地域の DNS クエリの大部分 (90%) を保護することに成功しました。

興味深いことに、Google は、このシンプルで明らかに議論の余地のない微調整で発生した主な問題は、ほとんどの DNS サーバーが一貫して大文字と小文字を区別しない (したがって、このトリックを使用できる) か、一貫して大文字と小文字を区別しない (ブロックリストに登録される) ことであると示唆しています。ご想像のとおり…

…いくつかのメインストリーム サーバーは、時折、短期間「大文字と小文字を区別する」モードになります。

それは本当に役に立ちますか？

質問への答え、 "その価値はありますか？" まだ明らかになっていません。

次のような素敵な長いサービス名がある場合 nakedsecurity.sophos.com (22 個のアルファベット文字)、2²² 大文字と小文字が異なるということは、詐欺師が試行する 4 万の組み合わせを意味し、65536 の異なる ID 番号を乗算し、約 32000 から 64000 の異なる送信元ポートを乗算して推測します…

…しかし、Twitter のような超短いドメイン名に大金を払った場合 t.co、攻撃者は以前よりも2x2x2 = 8倍難しい仕事しかありません。

それでも、これを試したことに対して、Google に「シャポー」と言えると思います。

サイバーセキュリティのオブザーバーが好んで言うように、攻撃はますます速くなる一方です。そのため、既存のプロトコルを利用してクラッキング時間を追加できるものはすべて、ほぼ「無料」で、有効な反撃方法となります。

---

• SEO を活用したコンテンツと PR 配信。 今日増幅されます。
• Platoblockchain。 Web3メタバースインテリジェンス。 知識の増幅。 こちらからアクセスしてください。
• 情報源： https://nakedsecurity.sophos.com/2023/01/23/serious-security-how-deliberate-typos-might-improve-dns-security/