---
1. 用語
NS変更通知:
- 権威サーバからの権威あり返答のAuthority Sectionにあるレコードを指すものとする。
- Kaminsky型攻撃を使って、偽NS RRSet を送りつけることができる。
移転通知インジェクション: JPRS用語
- JPRSは親からの委譲を示すRRSetを上書きするケースしか存在しないような説明をしている。これは間違いである。
移転インジェクション:
- 鈴木は当初はJPRSと同じ用法(移転インジェクション)だったが、 2014年6月には権威ある返答中のNSレコードの場合を含むとしている。(定義しなおしたわけではない)
2. DNS/毒盛再考/NS移転通知毒
2014年の指摘:
- 「キャッシュにある(権威のある)NSレコードを上書きする」ような毒を
食ってしまうような脆弱なキャッシュサーバがあるそうだ。
Kaminsky(2008) の間違った例を少し手直しした民田の例を想像してもらえばよい。 しかし、この脆弱性はBINDでは直されたはずだった。
それでも、Ghost Domain Names脆弱性として蘇った。 (2012)
- そのときのISCの対応を見ていて、この対応は間違っていると思った。
移転毒が入るだろうことはこの時知った。 その時すぐに指摘していればよかったのだが。
- でも、さくらの共用ゾーンサービスの危険性に気を取られていたために、忘れてしまった。
-- ToshinoriMaeno 2015-07-22 07:37:05
自ゾーンのNSを騙って、NSを追加変更する毒盛はなんと呼ぶのがいいだろう。
- DNS RFCで規程された動作ではなさそうだが、禁止されている訳ではない。ただ、毒盛に使われ易い。
関連RFC: 2181 第5節 https://moin.qmail.jp/DNS/RFC2181/s5#sub4
3. 毒の例
DNS/脆弱性/GhostDomainNames (いわゆる幽霊ドメイン脆弱性)
DNSゾーンサーバの移転作業の解説を読んでいると、
- 移転作業に見せかけた毒盛が簡単であることが分かる。
-- ToshinoriMaeno 2014-05-18 11:43:41
http://jprs.jp/related-info/guide/019.pdf
- DNSサーバーの引っ越し
~トラブル発生を未然に防ぐ手順とポイント~
- 正規の返答が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 2014-05-25 07:58:18
4. 対策: 移転通知を認めない
自ゾーンのNSを騙って、NSを追加変更して安全なのだろうか。
- DNS RFCで規程された動作ではなさそう。 禁止されている訳ではない。でも、毒盛を容易にする。
調査すべき項目が残っている。
- 入った毒が効果を示し続けるかどうか。
キャッシュを上書きし易いということは、毒も上書きされやすいかもしれない。 (同じランク上書きさせる場合)
-- ToshinoriMaeno 2014-05-26 11:02:15
5. 上位から委譲されるものより、自称の方が優先するのか
http://ns.qmail.jp/DNS/RFC1035/7#A522
DNS/毒盛/Shmatikov の ランキングでは異なる記述もあるようだ。
- 5 Cache Overwriting
-- ToshinoriMaeno 2014-06-20 04:43:34
6. RFC 2181 抜粋
得られるデータの正確さは情報源に依存する。 信頼できるものから、順に以下のようになる。 プライマリゾーンファイルからのデータ (グルーデータを除く)、 ゾーン転送で得られたデータ (グルーデータを除く)、 権威ある返事の answer節中にある権威あるデータ、 権威ある返事の authority節中にあるデータ、 プライマリゾーンファイルのグルーデータ、またはゾーン転送で得られたグルーデータ 権威のない返事の answer節中にあるデータ、および権威ある返事の answer節中にある権威のないデータ、 権威ある返事の付加情報、権威のない返事のauthority節中のデータ、 権威のない返事の付加情報
「上位サーバからの委譲返答」という「一番重要な情報」が信頼度がもっとも低く扱われるようなRFCを尊重することは適当ではない。