[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
SlideShare a Scribd company logo

co.jp への TXT 追加の謎

•
•
Yoshikazu GOTO
Yoshikazu GOTO
1 of 20
co.jp への TXT 追加の謎 RFC 5155 をふらふらと読み解く @goto_ipv6
最初に • 実は、「co.jpにTXTリソースレコードが追加されたこと」については、 直接の理由はわかりませんでした • 「多分これだろうという理由」は、既にわかっています • ここでは、私がどのような道をたどり、どんな答えに行き着いたのか をまとめてみようと思います • なお、この資料は「私がRFC 5155をこのように解釈しました」という内容に なっていますので、内容の正確性はRFC 5155原本にてご確認ください
一通のメール • あるとき、dnsops MLに一通のメールが流れました Subject: [DNSOPS dnsops 1339] Re: キャッシュポイズニング攻撃の危険性増加に関 する緊急の注意喚起の掲載について From: "T.Suzuki" <tss@e-ontap.com> To: dnsops@dnsops.jp Date: Tue, 15 Apr 2014 15:03:41 +0900 <snip> それから、co.jp などにいつの間にか入っている不思議な TXT レコードについて、 本件との関連性の説明をしてもらえたりできませんか?
co.jpにTXTレコード？ • なぜそんなものが？ • また、JPRSさんによる「キャッシュポイズニング攻撃対策：キャッシュ DNSサーバー運用者向け―基本対策編」との関連もわかりません • キャッシュへの毒入れなら、私も擬似環境を作り、攻撃ツールを自作して、 毒入れに成功していました • co.jpドメインも乗っ取ることができました • example.co.jpなど、まるごとごっそり • すぐに思いついたのはDNSSECでした • 「信頼の連鎖」をつなぐためなのでしょうか？ • でも、すでに「信頼の連鎖」は構築済みだったのでは？
co.jpってどんなドメイン名？ • 実は、TXT RRが入る前は、リソースレコードが何も存在しないドメイン 名でした • jpゾーンから直接、example.co.jpが委任されています • DNSSECでも、example.co.jpのDSは、jpゾーンに登録されています • 「example.co.jp」は、例です • co.jpにTXT RRが入ると、DNSSECとしては、状況が変わります • TXT RRに対する署名が行われ、RRSIG RRが生成されます • “drill -D -o rd co.jp. any @a.dns.jp” と入力してみましょう • これで、既に署名されていた jpゾーンと、example.co.jpとの間にあるco.jpも、 署名されることになります • つながった！何がつながった？
とりあえず乗っ取りを試してみる • 擬似環境でDNSSECを有効にし、署名してみます • 結果、co.jpへのTXT RRがあっても毒は入りました • あれ？ • しかし、想定していなかった、別の動作も観測しました • co.jpのDSを偽権威DNSサーバーに問い合わせてしまうのです • 結果、validationに失敗してSERVFAILになりました • DoSとしては成功！！ • でも、なぜキャッシュDNSサーバーは、DSを偽権威DNSサーバーに問い合わ せるのでしょうか？ • しかも、DSを問い合わせる現象は、TXT RRの有無に依存しません
RFC 5155 • ここで出てくるのがRFC 5155です • JPRSさんによる日本語訳はこちらです • 日本語タイトルは「DNSSECにおけるハッシュを使用した不在証明」です • これがまた、難解で… • 特に、「用語」を理解するのが大変 • ハッシュ化所有者名？ハッシュ整列順？空の非終端？証明可能な最近接名？カバー する？ • co.jpは「空の非終端」（Empty non-terminal）になります
混乱 • 「ハッシュ整列順」と「カバーする」が、私を混乱させました • RFC 5155では、「ゾーン列挙」によりゾーンの全内容を読み取ることができて しまう問題を解消しています • ドメイン名にハッシュ関数を適用し、それを権威DNSサーバーが返すことで、 ドメイン名自体は返らなくなるのです • ある範囲にはドメイン名は存在しないことも、複数のハッシュ化所有者名を 返すことで示すことができます • 「カバーする」ということは、例えばco.jpについて「なにもないよ」を示すには、 その両側のハッシュ化所有者名で挟めばよいのかな？ • aa.jpとzz.jpを作ったりしました…失敗…
NSEC3リソースレコード • RFC 5155ではNSEC3 RRが導入されます • NSEC3 RRは、NSEC3 RRのオリジナル所有者名について、これに存在 するRRタイプを列挙します • 「タイプビットマップ」フィールドにエンコードされます • 例えば、jpドメインの場合、NSやSOA, RRRIG, DNSKEY, NSEC3PARAMが存在す ることを、NSEC3 RRを用いてバリデーターに知らせることができます • 「フラグ」フィールド内の「Opt-Outフラグ」により、NSEC3 RRが未署名 委任をカバーしているかがわかります • ん？カバー？
カバーする • RFC 5155に登場する「カバーする」を理解するには、以下のことも理 解しなければなりません（以下、JPRSさんの日本語訳より抜粋） • 最近接名（Closest Encloser）： ある名前に最長一致する実在の名前で、先 祖（親、親の親など）にあたるもの • 証明可能な最近接名（Closest Provable Encloser）： さらに、存在証明が可能なもの • 次近接名（Next Closer Name）： ある名前の証明可能な最近接名より1ラベ ル長い名前 • カバーする： ある名前もしくは次近接名のハッシュが、NSEC3の所有者名と 次ハッシュ化所有者名の間にあるとき、そのNSEC3 RRはその名前を"カバー する"という • んー、わからん…
カバーする（続き） • 続けて、NSEC3 RDATAのワイヤフォーマットを見てみます（3章） • 「次ハッシュ化所有者名」フィールドがあります • 次ハッシュ化所有者名（Next hashed owner name）： 全ハッシュ化所有者名を整列した 集合がある場合に、あるNSEC3 RRの「次ハッシュ化所有者名」フィールドは、そのNSEC3 RRの所有者名の直後にくる所有者名のハッシュを含む • 各NSEC3 RRにおいて、ハッシュ整列順にしたがった次のNSEC3 RRの値を、次ハッシュ化 所有者名として挿入する（7.1章） • ハッシュ整列順（Hash order）： ハッシュ化所有者名がその数値に応じて配列される順 序 • ハッシュ化所有者名（Hashed owner name）： 所有者名にハッシュ関数を適用した後に 生成される所有者名 • 何か、見えてきました
カバーする（続き） • もう一度考えてみる • 例えばexample.co.jpの「最近接名」はco.jpです • しかし署名されているのはjpですので、jpが「証明可能な最近接名」です • すると「次近接名」はco.jpになります • ここで、co.jpの「次ハッシュ化所有者名」のドメイン名はexample.jpとします • NSEC3 RRの所有者名をco.jpとすると、ある名前co.jpのハッシュが自分自身 （所有者自身）となり、さらに「次ハッシュ化所有者名」フィールドにexample.jp のハッシュを入れておけば、co.jpのNSEC3 RRはco.jpを「カバー」する、という ことになります
"Insecure"な委任 • co.jpについては、委任先のドメイン名ではDNSSECを導入していない 組織が多くあります • RFC 5155ではこれを「“Insecure”な委任」と呼んでいます • が、6章を読んで、また混乱しました… • しかし、6章の最初の一文に、「なぜDSを問い合わせるのか」の答え（の一 部）があります • 同様に、8.9章にはバリデーターとして動作した場合の「未署名サブゾーンへ の参照の検証」についての記載があります • このco.jpに毒入れしてみると、DS問い合わせが発生するのです • この動き、どこに書いてあるの？
Opt-Out • NSEC3 RRの「フラグ」フィールドにはOpt-Out bitがあります • このNSEC3 RRが未署名委任を「カバー」しているかを示しています • つまり、ここが1の場合、未署名の委任が存在してもよい、ということです • jpのNSEC3 RRは、ここが1になっています • example.co.jpが未署名（DNSSECを導入していない）でも構わないことを示しています • 署名は、ゾーンファイルに対して行います • dnssec-signzone（BIND9に同梱）やldns-signzone（NLnet Labsの独自作成ツー ルでありldnsライブラリのサンプルプログラム）といったツールがあります • オプションで、Opt-Outを有効にして署名することができます
実装の違い • dnssec-signzoneでは、すべてが“Insecure”な委任の場合にはNSEC3 RRを生成しません • RFC 5155の当初の目的の1つでもある、委任が主たる仕事となる大規模ゾー ンの場合の、署名のコストを減らすために、このような実装になっています • “Secure”な委任がco.jpの配下に1個もないと、co.jpのNSEC3 RRも生成されず、 co.jpの乗っ取りが可能となります • co.jpの配下にex1.co.jpとex2.co.jpがあったとして、どちらもjpから委任されており、しか しDNSSECは導入していなかった場合、DSがjpには登録されていないために、署名の際 に、co.jpのNSEC3 RRは生成されません • jpのNSEC3 RRにはOpt-Outがあるため、バリデーターはco.jp以下についてバリデーショ ンを行いません
実装の違い（続き） • ldns-signzoneでは、ゾーンファイルに記載されたすべての委任につ いて、NSEC3 RRを生成します • さらには、「空の非終端」のNSEC3 RRも生成してしまいます • ゾーンファイルにjpとexample.co.jpが記載されていた場合、署名後のファイルにはco.jp のNSEC3 RRが自動生成されます • example.co.jpが”Secure”か、”Insecure”かどうかは関係ありません • RFC 5155にはErrataが出ており、この中では、ldns-signzoneのような処理をし なければならない、とあります（Errata ID: 3441） • OpenDNSSECでも、この動作をするように変更されています
そしてDSを問い合わせる理由は？ • どちらのツールでも、 “Secure”な委任がある場合は「空の非終端」に ついてもNSEC3 RRが生成されます • 例えばexample.co.jpはjpから委任されているとすると、co.jpから委任されて いるわけではないために、co.jpのNSEC3 RRにおける「タイプビットマップ」に はNSは記録されません（というか空になります） • co.jp NS RRを毒入れされるとバリデーターは、しかしco.jpにはNSが存在しな いことを知っているために、「おかしいぞ」と気が付きます • ここでUnboundもBIND9も、jpの権威DNSサーバーが言っていることよりかは co.jpの（偽）権威DNSサーバーが言っていることを信じてみようということで、 偽権威DNSサーバーにDSがあるか問い合わせ、「信頼の連鎖」が守られて いるかを確認しようとします（これについてのRFCが見つからない…） • そもそも、本来なら委任元に問い合わせるべきだし
というわけで • RFC 5155に、「少しだけ」詳しくなることができました • いや、ほんの少しだけ、ですね… • なぜco.jpにTXT RRをつけたのかという理由は、わかりませんでした • TXT RRの有無で、キャッシュDNSサーバー（バリデーター）の動作に変わりは ありませんでした • どうやら、co.jpにつけたかったのではなくて、aichi.jpなどの都道府県型JPドメ イン名を守るためでは？というお話を、ある方（某h氏）から聞きました • なるほど納得です • aichi.jpなどは、もしかするとDNSSECさえも知らない人・組織が使っている可能性 • なので、「一律」に入れたと、ある方（某O氏）がおっしゃっていました • 結果、co.jpにもTXT RRがつきました
gouv.fr の謎 • JPRSさんは、co.jpやaichi.jpなどにTXTレコードを入れました • drill -D co.jp any • TXTと、TXTに関するRRSIGがありますね • 同じく「空の非終端」となりうるgouv.frはどうでしょうか？ • drill -D gouv.fr any • なぜ、このようにして（なって）いるのでしょうか？
その後 • 2014年7月17日、18日に、香川県高松市にてJANOG34 Meetingが開 催されました • その中に、「Security Issuesへの取り組みと対応―「ちゃんと」「きちんと」伝え るためにできること～キャッシュポイズニングの手法を題材に～」というプロ グラムがあり、co.jpなどにTXT RRがついた理由が明かされました • また、別途、JPRSにて6月9日ころに「DNS.JPゾーンの収容変更につい て」という操作も行われました • dns.jpゾーンが作成（jpゾーンから分離）されました

More Related Content

co.jp への TXT 追加の謎

  • 1. co.jp への TXT 追加の謎 RFC 5155 をふらふらと読み解く @goto_ipv6
  • 2. 最初に • 実は、「co.jpにTXTリソースレコードが追加されたこと」については、 直接の理由はわかりませんでした • 「多分これだろうという理由」は、既にわかっています • ここでは、私がどのような道をたどり、どんな答えに行き着いたのか をまとめてみようと思います • なお、この資料は「私がRFC 5155をこのように解釈しました」という内容に なっていますので、内容の正確性はRFC 5155原本にてご確認ください
  • 3. 一通のメール • あるとき、dnsops MLに一通のメールが流れました Subject: [DNSOPS dnsops 1339] Re: キャッシュポイズニング攻撃の危険性増加に関 する緊急の注意喚起の掲載について From: "T.Suzuki" <tss@e-ontap.com> To: dnsops@dnsops.jp Date: Tue, 15 Apr 2014 15:03:41 +0900 <snip> それから、co.jp などにいつの間にか入っている不思議な TXT レコードについて、 本件との関連性の説明をしてもらえたりできませんか?
  • 4. co.jpにTXTレコード？ • なぜそんなものが？ • また、JPRSさんによる「キャッシュポイズニング攻撃対策：キャッシュ DNSサーバー運用者向け―基本対策編」との関連もわかりません • キャッシュへの毒入れなら、私も擬似環境を作り、攻撃ツールを自作して、 毒入れに成功していました • co.jpドメインも乗っ取ることができました • example.co.jpなど、まるごとごっそり • すぐに思いついたのはDNSSECでした • 「信頼の連鎖」をつなぐためなのでしょうか？ • でも、すでに「信頼の連鎖」は構築済みだったのでは？
  • 5. co.jpってどんなドメイン名？ • 実は、TXT RRが入る前は、リソースレコードが何も存在しないドメイン 名でした • jpゾーンから直接、example.co.jpが委任されています • DNSSECでも、example.co.jpのDSは、jpゾーンに登録されています • 「example.co.jp」は、例です • co.jpにTXT RRが入ると、DNSSECとしては、状況が変わります • TXT RRに対する署名が行われ、RRSIG RRが生成されます • “drill -D -o rd co.jp. any @a.dns.jp” と入力してみましょう • これで、既に署名されていた jpゾーンと、example.co.jpとの間にあるco.jpも、 署名されることになります • つながった！何がつながった？
  • 6. とりあえず乗っ取りを試してみる • 擬似環境でDNSSECを有効にし、署名してみます • 結果、co.jpへのTXT RRがあっても毒は入りました • あれ？ • しかし、想定していなかった、別の動作も観測しました • co.jpのDSを偽権威DNSサーバーに問い合わせてしまうのです • 結果、validationに失敗してSERVFAILになりました • DoSとしては成功！！ • でも、なぜキャッシュDNSサーバーは、DSを偽権威DNSサーバーに問い合わ せるのでしょうか？ • しかも、DSを問い合わせる現象は、TXT RRの有無に依存しません
  • 7. RFC 5155 • ここで出てくるのがRFC 5155です • JPRSさんによる日本語訳はこちらです • 日本語タイトルは「DNSSECにおけるハッシュを使用した不在証明」です • これがまた、難解で… • 特に、「用語」を理解するのが大変 • ハッシュ化所有者名？ハッシュ整列順？空の非終端？証明可能な最近接名？カバー する？ • co.jpは「空の非終端」（Empty non-terminal）になります
  • 8. 混乱 • 「ハッシュ整列順」と「カバーする」が、私を混乱させました • RFC 5155では、「ゾーン列挙」によりゾーンの全内容を読み取ることができて しまう問題を解消しています • ドメイン名にハッシュ関数を適用し、それを権威DNSサーバーが返すことで、 ドメイン名自体は返らなくなるのです • ある範囲にはドメイン名は存在しないことも、複数のハッシュ化所有者名を 返すことで示すことができます • 「カバーする」ということは、例えばco.jpについて「なにもないよ」を示すには、 その両側のハッシュ化所有者名で挟めばよいのかな？ • aa.jpとzz.jpを作ったりしました…失敗…
  • 9. NSEC3リソースレコード • RFC 5155ではNSEC3 RRが導入されます • NSEC3 RRは、NSEC3 RRのオリジナル所有者名について、これに存在 するRRタイプを列挙します • 「タイプビットマップ」フィールドにエンコードされます • 例えば、jpドメインの場合、NSやSOA, RRRIG, DNSKEY, NSEC3PARAMが存在す ることを、NSEC3 RRを用いてバリデーターに知らせることができます • 「フラグ」フィールド内の「Opt-Outフラグ」により、NSEC3 RRが未署名 委任をカバーしているかがわかります • ん？カバー？
  • 10. カバーする • RFC 5155に登場する「カバーする」を理解するには、以下のことも理 解しなければなりません（以下、JPRSさんの日本語訳より抜粋） • 最近接名（Closest Encloser）： ある名前に最長一致する実在の名前で、先 祖（親、親の親など）にあたるもの • 証明可能な最近接名（Closest Provable Encloser）： さらに、存在証明が可能なもの • 次近接名（Next Closer Name）： ある名前の証明可能な最近接名より1ラベ ル長い名前 • カバーする： ある名前もしくは次近接名のハッシュが、NSEC3の所有者名と 次ハッシュ化所有者名の間にあるとき、そのNSEC3 RRはその名前を"カバー する"という • んー、わからん…
  • 11. カバーする（続き） • 続けて、NSEC3 RDATAのワイヤフォーマットを見てみます（3章） • 「次ハッシュ化所有者名」フィールドがあります • 次ハッシュ化所有者名（Next hashed owner name）： 全ハッシュ化所有者名を整列した 集合がある場合に、あるNSEC3 RRの「次ハッシュ化所有者名」フィールドは、そのNSEC3 RRの所有者名の直後にくる所有者名のハッシュを含む • 各NSEC3 RRにおいて、ハッシュ整列順にしたがった次のNSEC3 RRの値を、次ハッシュ化 所有者名として挿入する（7.1章） • ハッシュ整列順（Hash order）： ハッシュ化所有者名がその数値に応じて配列される順 序 • ハッシュ化所有者名（Hashed owner name）： 所有者名にハッシュ関数を適用した後に 生成される所有者名 • 何か、見えてきました
  • 12. カバーする（続き） • もう一度考えてみる • 例えばexample.co.jpの「最近接名」はco.jpです • しかし署名されているのはjpですので、jpが「証明可能な最近接名」です • すると「次近接名」はco.jpになります • ここで、co.jpの「次ハッシュ化所有者名」のドメイン名はexample.jpとします • NSEC3 RRの所有者名をco.jpとすると、ある名前co.jpのハッシュが自分自身 （所有者自身）となり、さらに「次ハッシュ化所有者名」フィールドにexample.jp のハッシュを入れておけば、co.jpのNSEC3 RRはco.jpを「カバー」する、という ことになります
  • 13. "Insecure"な委任 • co.jpについては、委任先のドメイン名ではDNSSECを導入していない 組織が多くあります • RFC 5155ではこれを「“Insecure”な委任」と呼んでいます • が、6章を読んで、また混乱しました… • しかし、6章の最初の一文に、「なぜDSを問い合わせるのか」の答え（の一 部）があります • 同様に、8.9章にはバリデーターとして動作した場合の「未署名サブゾーンへ の参照の検証」についての記載があります • このco.jpに毒入れしてみると、DS問い合わせが発生するのです • この動き、どこに書いてあるの？
  • 14. Opt-Out • NSEC3 RRの「フラグ」フィールドにはOpt-Out bitがあります • このNSEC3 RRが未署名委任を「カバー」しているかを示しています • つまり、ここが1の場合、未署名の委任が存在してもよい、ということです • jpのNSEC3 RRは、ここが1になっています • example.co.jpが未署名（DNSSECを導入していない）でも構わないことを示しています • 署名は、ゾーンファイルに対して行います • dnssec-signzone（BIND9に同梱）やldns-signzone（NLnet Labsの独自作成ツー ルでありldnsライブラリのサンプルプログラム）といったツールがあります • オプションで、Opt-Outを有効にして署名することができます
  • 15. 実装の違い • dnssec-signzoneでは、すべてが“Insecure”な委任の場合にはNSEC3 RRを生成しません • RFC 5155の当初の目的の1つでもある、委任が主たる仕事となる大規模ゾー ンの場合の、署名のコストを減らすために、このような実装になっています • “Secure”な委任がco.jpの配下に1個もないと、co.jpのNSEC3 RRも生成されず、 co.jpの乗っ取りが可能となります • co.jpの配下にex1.co.jpとex2.co.jpがあったとして、どちらもjpから委任されており、しか しDNSSECは導入していなかった場合、DSがjpには登録されていないために、署名の際 に、co.jpのNSEC3 RRは生成されません • jpのNSEC3 RRにはOpt-Outがあるため、バリデーターはco.jp以下についてバリデーショ ンを行いません
  • 16. 実装の違い（続き） • ldns-signzoneでは、ゾーンファイルに記載されたすべての委任につ いて、NSEC3 RRを生成します • さらには、「空の非終端」のNSEC3 RRも生成してしまいます • ゾーンファイルにjpとexample.co.jpが記載されていた場合、署名後のファイルにはco.jp のNSEC3 RRが自動生成されます • example.co.jpが”Secure”か、”Insecure”かどうかは関係ありません • RFC 5155にはErrataが出ており、この中では、ldns-signzoneのような処理をし なければならない、とあります（Errata ID: 3441） • OpenDNSSECでも、この動作をするように変更されています
  • 17. そしてDSを問い合わせる理由は？ • どちらのツールでも、 “Secure”な委任がある場合は「空の非終端」に ついてもNSEC3 RRが生成されます • 例えばexample.co.jpはjpから委任されているとすると、co.jpから委任されて いるわけではないために、co.jpのNSEC3 RRにおける「タイプビットマップ」に はNSは記録されません（というか空になります） • co.jp NS RRを毒入れされるとバリデーターは、しかしco.jpにはNSが存在しな いことを知っているために、「おかしいぞ」と気が付きます • ここでUnboundもBIND9も、jpの権威DNSサーバーが言っていることよりかは co.jpの（偽）権威DNSサーバーが言っていることを信じてみようということで、 偽権威DNSサーバーにDSがあるか問い合わせ、「信頼の連鎖」が守られて いるかを確認しようとします（これについてのRFCが見つからない…） • そもそも、本来なら委任元に問い合わせるべきだし
  • 18. というわけで • RFC 5155に、「少しだけ」詳しくなることができました • いや、ほんの少しだけ、ですね… • なぜco.jpにTXT RRをつけたのかという理由は、わかりませんでした • TXT RRの有無で、キャッシュDNSサーバー（バリデーター）の動作に変わりは ありませんでした • どうやら、co.jpにつけたかったのではなくて、aichi.jpなどの都道府県型JPドメ イン名を守るためでは？というお話を、ある方（某h氏）から聞きました • なるほど納得です • aichi.jpなどは、もしかするとDNSSECさえも知らない人・組織が使っている可能性 • なので、「一律」に入れたと、ある方（某O氏）がおっしゃっていました • 結果、co.jpにもTXT RRがつきました
  • 19. gouv.fr の謎 • JPRSさんは、co.jpやaichi.jpなどにTXTレコードを入れました • drill -D co.jp any • TXTと、TXTに関するRRSIGがありますね • 同じく「空の非終端」となりうるgouv.frはどうでしょうか？ • drill -D gouv.fr any • なぜ、このようにして（なって）いるのでしょうか？
  • 20. その後 • 2014年7月17日、18日に、香川県高松市にてJANOG34 Meetingが開 催されました • その中に、「Security Issuesへの取り組みと対応―「ちゃんと」「きちんと」伝え るためにできること～キャッシュポイズニングの手法を題材に～」というプロ グラムがあり、co.jpなどにTXT RRがついた理由が明かされました • また、別途、JPRSにて6月9日ころに「DNS.JPゾーンの収容変更につい て」という操作も行われました • dns.jpゾーンが作成（jpゾーンから分離）されました