1. NS 毒盛
| /NS /authanswerの書き換え /zone_cutsの非存在推定 /ゾーンサーバー側でやれること /リゾルバーでの対策 /対策 |
2008年にKaminskyが指摘した毒盛手法はAdditional Sectionを利用するものであった。(BINDの脆弱性)
おなじ時期にMuellerが指摘したのはAuthority Section (NS)を利用するものだった。 ここでは後者について、検討する。
NS毒盛とはなにか。../2014
- 多くのNS毒は受け入れられる。ただし、毒として効果の大きいものは限られる。
そして/対策とは。../2016 DNS/毒盛/対策/NXDOMAIN返答活用
1.1. 返答中のNSレコード
NSレコードはDNS返答のさまざまな状況で現れる。 DNS/1/資源レコード/NS/返答中のNS
どんな返答のAuthority Sectionにも含まれうると考えておく。
最近話題になったのはNXDOMAIN返答中に含まれたNSレコードによる毒盛です。/
1.2. ゾーンファイル中のNSレコード
- ゾーンの根元に付随するNSと委譲を示すNS（ゾーンの末端ノードに付随するNS)とがある。 NSはゾーンカット（だけ）に現れるレコードだとも言えます。二つの顔を持っています。
親子関係にある複数ゾーンを同一サーバでサービスしていると、 NSは別の場面でも現れて、話を複雑にします。
(-- ToshinoriMaeno 2015-10-15 12:21:29)
1.3. 毒盛手法の分類について
きちんと定義がされないままで、現象を指すだけの言葉を広めようとすることの害：
- 言葉だけがひとり歩きして、理解するのにはじゃまになります。
- 一面しか見えていない状態での命名は害も多そうです。
1.3.1. 毒NS の分類
なにを毒として送りつけるかという視点からの分類：/NS 「どこからの返事として送りこむか」は別項目とした。 DNS/返答/referral か ../AncillaryDataAttacks か
1.3.2. 目標の状態による分類
キャッシュされているものがなにかによって、話が違ってくる。/Ranking
キャッシュにNSなし --> いわゆる「委任インジェクション」が狙う状態
- キャッシュに委譲のNS(親からの情報） JPRSのいう「移転通知インジェクション」 が狙う状態
キャッシュに権威ありNS（Authority Section 由来） tssさんの「/移転インジェクション」で現れる状態
- この場合にも上書きされる実装があったことはGhost Domain Names脆弱性のときに示されている。
- 権威ありNS（問い合せの結果、Answer Sectionで得られる）のキャッシュ。
NS毒は取り込まないようだが、glue はどうか。BINDは危ないらしい。-- ToshinoriMaeno 2018-04-12 09:58:20
https://twitter.com/beyondDNS/status/984349535475412993
1.4. RFC 2181
RFC2181のRankingを遵守するなら、これらの区別は必要だろう。 RRSetの優先順位が述べられている。
- ただし、2181は「返答が毒ではない」ことを前提の議論になっている。つまり、毒見には使えない。
毒も考慮するとしたら、どうするのがより安全かは述べられていない。
これらの情報以外に、/zone cutが存在しないという情報が得られている可能性が大きい。(攻撃時）
- 現存するリゾルバーでこの情報を利用しているものは見あたらない
1.4.1. どこからの返事なのか
委譲を示すNSも委譲する資格のあるサーバからのものかどうかを確認すること。
毒盛する側から見ても、どこからの返事として送りこむかは重要な点だ。
UDPではパケットの送信元を詐称するのは簡単だから、見分けるのは簡単ではない。
1.5. 対策
delegation responseをもらったら、すなおに受け入れてはいけない。
/zoneの非存在が示されていないか。（攻撃だったら、キャッシュにマークがあるはず）
- TCPで問い合わせ直す。（nonce付きで）