## page was renamed from DNS/セキュリティ/危険な共用ゾーンサービス/スーパードメイン登録 ## page was renamed from DNS/脅威/共用ゾーンサービス/危険なサービス/スーパードメイン登録 ## page was renamed from DNS/共用ゾーンサービス/危険なサービス/スーパードメイン登録 ## page was renamed from DNS/共用DNSサービス/危険なサービス/スーパードメイン登録 ## page was renamed from DNS/危険なサービス/スーパードメイン登録 ## page was renamed from DNS/サービス/危険性/スーパードメイン登録 == DNS/危険なサービス/スーパードメイン登録 == 共用の権威サーバが危険という警告をしてきた理由です。(さくらだけではなかった) 　サブドメインが作れるという脆弱性まであった(さくら)というのは予想外でした。W <> == 乗っ取りの警告 == * 所有確認なしのコンテンツサーバで * スーパードメインを登録することで 既存のサブドメインを乗っ取れるケースがありました。 手元のtinydns でも再現できました。登録データの検査が不十分なのでしょう。 BIND系ではサブドメインが優先されるので、サブドメインを乗っ取ることにはならないようです。 でも、親ドメインがどういう悪影響を受けるかは、分からない。(委譲の状況による) 　サブドメインが（外部から正当に）委譲されている状態で、 　　　サブドメインが親ゾーンのデータを参照していたりしたときに、なにが起きるか。 　　　　返答に含められたとしても、権限外ということで、キャッシュが拒否してくれることを期待しよう。 私(森下さん）の調査ではBIND 9、NSDでは上位ドメイン（スーパードメイン）の同居（押しかけ親）では、 既存のドメイン名の乗っ取りはできませんでした。 ただし、それはBIND 9/NSDでは＊たまたま＊大丈夫だったというだけで、各実装での調査検証が必要です。 外部の設定次第です。押しかけ親でドメイン乗っ取りできると思われるケースを見つけました。 とても危険です。-- ToshinoriMaeno <> == 落とし穴の警告 == スーパードメインが登録可能なサーバでは あらかじめサブドメインを登録しておく「落とし穴」攻撃も可能です。 　（さくら、Dozens で確認：この脆弱性はさくらの脆弱性を誘発したきっかけの脆弱性です。） == 発症の条件 == どちらのケースも所有確認なし、ドメインの親子関係の検査不十分ということで発症します。 (補足）正確には動いているサーバの動作（欠陥）に依存しています。 私の知る範囲ではどのサーバにも委譲の処理に問題があります。 * BIND 系ではサブドメイン（ゾーン）が優先されるようです。 * tinydns では親と子に属するレコードの和集合のレコードから返事が選ばれます。 -- ToshinoriMaeno <> == 登録妨害 == 某共用DNSサービスでは任意の上位ドメインが登録できるという問題がありました。 試しに "ne.jp" を登録したところ、登録できてしまったという話があり、慌てて警告したとのこでした。 サブドメイン登録を禁止していても、こんな穴があると、なにも登録できなくされてしまいます。 さくらに同様の穴(ne.jp など)があったかどうかは確認していません。(たぶんあったのでしょう。) == amazon route 53 == route53のDNSサービスでは先祖、子孫の関係にあるドメインは同一のサーバには割り当てられないとのことです。 我々が外部から観察した結果とも整合します。-- ToshinoriMaeno <> == スーパードメイン検査 == スーパードメインを登録させないための検査はむずかしい。(所有確認しないとしたら) あるサービスではne.jpゾーンが登録できてしまった。 少なくとも、登録妨害にはなるだろう。 登録させないドメインのリストはPublic Suffix List のようなものになるだろう。 これらのリストにあるもののサブドメインは登録させたいだろうから。 == 兄弟ドメイン検査 == ほとんど行われていないが、欲しいケースもある。 委譲が親ドメインに対して行われているが、親ドメインが登録されていないというケースもあるので。 == 参考 == ドメインハイジャックもサブドメインハイジャックもwebハイジャックに比べると気づかれにくい。 それだけ、危険だ。 --- 直接の被害者はドメインを参照した人たちだ。 DNSの知識があまりないから、乗っ取りに気づくことはなさそう。 ドメイン管理者の責任は重い。