さくらインターネットのドメインハイジャック脆弱性について

http://causeless.seesaa.net/article/289752013.html

の前提として、

さくらで他人のドメインのサブドメインを勝手に利用できる脆弱性があった。
http://blog.tokumaru.org/2012/06/sakura-dns-subdomain-hijacking.html
http://www.e-ontap.com/blog/20120614.html
http://jprs.jp/tech/security/2012-06-22-shared-authoritative-dns-server.html
http://www.atmarkit.co.jp/news/201206/22/subdomain.html

自分はさくらの中の人ではないので、外から見える限りの状況で話しています。

さくらの共用DNSは、レンタルサーバやメールなどの各種サービスに付属して、外部ドメイン（いわゆる"独自ドメイン対応レンタルサーバ"の機能）や共用ドメイン（*.sakura.jpなどいくつかサブメインを無料で使える）をホストするため、対応するゾーンとレコードを共用のDNSサーバに設定できるようになっている。

公式の設定方紹介を見るとわかるように、『外部ドメインの登録』と、『サブドメインの登録』がそれぞれ個別のUIで用意されている。

まず外部ドメインexample.jpを登録すると、さくらの共用DNSの中に、example.jp.ゾーンが作られる。当然、必要なSOA/NSが作られる。レンタルサーバならAが、メールサーバならMXも同時に作られるだろう。

さらにサブドメインを登録すると、作ったゾーンにたとえばwww IN A 1.2.3.4のような必要なレコードが作られる。

という動作と考えるのが普通だと思う。少なくとも設定後外から引く限りはそういう動作に見える。

その後、レジストラからexample.jpの委任先をns*.dns.ne.jpというさくらのサーバに設定すると、実際にexample.jpはさくらのDNSの内容通りに利用できるようになる。

ここで第三者がレンタルサーバを契約し、www2.example.jpという外部ドメインを申請した場合。
www2.example.jpをルートとするゾーンは、example.jpのサブゾーンなので、本来勝手にゾーンを作られては困るのだが、さくらはこのチェックをしていなかった。
すなわち、他のユーザが作った登録済みゾーンの中に勝手にサブゾーンを切り分ける権限を、第三者に与えてしまった。

すくなくとも一部のDNS実装は親ゾーン側に適切なNSレコードが設定されていなくてもエラーを吐かずに暗黙にゾーン分割を行うので、www2.example.jpは（そとからみて）正しく委任されたサブゾーンに見える。
よってwww2.example.jpはexample.jpのサブドメインにも関わらず、第三者が勝手に利用できるようになる。

この攻撃には、親ゾーンがさくらの共用DNSに委任されている必要があるので、田中社長の発言によれば少なくとも、委任していなかった6万のドメイン、Aレコードのみ設定していた7000のドメインはこの攻撃の対象外だった。
https://twitter.com/goto_ipv6/status/241712704430170114
対象外だった人たちが、さくらのドメイン登録ポリシー信用していなかったのかは分からないが。

この問題のアドホックな対策は、JPRSも書いている用に、第三者による不正なゾーンの分割が発生する不自然な登録をチェックすることだ。

個人的には、この脆弱性は外部ドメインを受け入れるどのレンタルサーバでも起こりうるし、臆病なら自分でチェックしてみるべきとも思う。
昔広告付き無料サーバを使わせてもらっていた頃、cPanel（共用レンタルサーバのマネージメントソフト群）（かその互換品？〜Panelというのがいくつかある）はこれを考慮しているらしいことをチェックしたことがある。

なお根本的には、http://causeless.seesaa.net/article/289854678.html にかいたように、ドメインの所有者をアカウントと正しく紐つける作業が必要になる。