## page was renamed from DNS/毒盛/2014/NS変更毒 ## page was renamed from DNS/毒盛/2014/NS更新毒 ## page was renamed from DNS/毒盛/2014/NS移転通知毒 ## page was renamed from DNS/毒盛/2014/NS 移転通知毒 ## page was renamed from DNS/毒盛2014/NS 移転通知毒 ## page was renamed from DNS/毒盛再考/NS 移転通知毒 <> --- <> <> ---- == 用語 == NS変更通知: 　権威サーバからの権威あり返答のAuthority Sectionにあるレコードを指すものとする。 　　Kaminsky型攻撃を使って、偽NS RRSet を送りつけることができる。 移転通知インジェクション：　JPRS用語 　JPRSは親からの委譲を示すRRSetを上書きするケースしか存在しないような説明をしている。これは間違いである。　 移転インジェクション： 　鈴木は当初はJPRSと同じ用法(移転インジェクション）だったが、 　2014年6月には権威ある返答中のNSレコードの場合を含むとしている。（定義しなおしたわけではない） http://www.e-ontap.com/dns/pandora_ieice.pdf pp.20--21 == DNS/毒盛再考/NS移転通知毒 == 2014年の指摘： 　「キャッシュにある（権威のある）NSレコードを上書きする」ような毒を 食ってしまうような脆弱なキャッシュサーバがあるそうだ。 Kaminsky(2008) の間違った例を少し手直しした民田の例を想像してもらえばよい。 しかし、この脆弱性はBINDでは直されたはずだった。 それでも、Ghost Domain Names脆弱性として蘇った。 (2012) 　そのときのISCの対応を見ていて、この対応は間違っていると思った。 移転毒が入るだろうことはこの時知った。 その時すぐに指摘していればよかったのだが。 　でも、さくらの共用ゾーンサービスの危険性に気を取られていたために、忘れてしまった。 -- ToshinoriMaeno <> 自ゾーンのNSを騙って、NSを追加変更する毒盛はなんと呼ぶのがいいだろう。 DNS RFCで規程された動作ではなさそうだが、禁止されている訳ではない。ただ、毒盛に使われ易い。 関連RFC： 2181 第５節　https://moin.qmail.jp/DNS/RFC2181/s5#sub4 [[DNS/リゾルバー/RFC2181ランキング再考]] == 毒の例 == [[DNS/脆弱性/GhostDomainNames]] (いわゆる幽霊ドメイン脆弱性） DNSゾーンサーバの移転作業の解説を読んでいると、 　移転作業に見せかけた毒盛が簡単であることが分かる。 -- ToshinoriMaeno <> http://jprs.jp/related-info/guide/019.pdf ＤＮＳサーバーの引っ越し ～トラブル発生を未然に防ぐ手順とポイント～ * 正規の返答がNXDOMAINとなるような問い合せを送るのは通常の攻撃と同様である。 %dnsq ns qmail.gtld-servers.net a2.gtld-servers.net {{{ 2 qmail.gtld-servers.net: 107 bytes, 1+0+1+0 records, response, authoritative, nxdomain query: 2 qmail.gtld-servers.net authority: gtld-servers.net 86400 SOA a2.nstld.com nstld.verisign-grs.com 2010113000 3600 900 1209600 86400 }}} * Kaminsky 攻撃の時に民田スライドで示されたようなNS(+glue)による毒盛はいまも有効なのだろうか。 　Answer Section + Authority Section による移転通知攻撃とも呼べる攻撃手法 (移転とは限らない） Ghost Domain Names 脆弱性論文により示されたところでは毒盛は可能なようだ。 -- ToshinoriMaeno <> [[/鈴木の例]] == 対策： 移転通知を認めない == 自ゾーンのNSを騙って、NSを追加変更して安全なのだろうか。 DNS RFCで規程された動作ではなさそう。 禁止されている訳ではない。でも、毒盛を容易にする。 調査すべき項目が残っている。 　入った毒が効果を示し続けるかどうか。 キャッシュを上書きし易いということは、毒も上書きされやすいかもしれない。　（同じランク上書きさせる場合） -- ToshinoriMaeno <> == 上位から委譲されるものより、自称の方が優先するのか == http://ns.qmail.jp/DNS/RFC1035/7#A522 [[DNS/毒盛/Shmatikov]] の ランキングでは異なる記述もあるようだ。 5 Cache Overwriting -- ToshinoriMaeno <> == RFC 2181 抜粋 == {{{ 得られるデータの正確さは情報源に依存する。 信頼できるものから、順に以下のようになる。 プライマリゾーンファイルからのデータ (グルーデータを除く)、 ゾーン転送で得られたデータ (グルーデータを除く)、 権威ある返事の answer節中にある権威あるデータ、 権威ある返事の authority節中にあるデータ、 プライマリゾーンファイルのグルーデータ、またはゾーン転送で得られたグルーデータ 権威のない返事の answer節中にあるデータ、および権威ある返事の answer節中にある権威のないデータ、 権威ある返事の付加情報、権威のない返事のauthority節中のデータ、 権威のない返事の付加情報 }}} 「上位サーバからの委譲返答」という「一番重要な情報」が信頼度がもっとも低く扱われるようなRFCを尊重することは適当ではない。 <>