1. NS 毒盛

2008年にKaminskyが指摘した毒盛手法はAdditional Sectionを利用するものであった。(BINDの脆弱性)

おなじ時期にMuellerが指摘したのはAuthority Section (NS)を利用するものだった。 ここでは後者について、検討する。

NS毒盛とはなにか。../2014

そして/対策とは。../2016  DNS/毒盛/対策/NXDOMAIN返答活用

1.1. 返答中のNSレコード

NSレコードはDNS返答のさまざまな状況で現れる。 DNS/1/資源レコード/NS/返答中のNS

どんな返答のAuthority Sectionにも含まれうると考えておく。

最近話題になったのはNXDOMAIN返答中に含まれたNSレコードによる毒盛です。/

1.2. ゾーンファイル中のNSレコード

親子関係にある複数ゾーンを同一サーバでサービスしていると、 NSは別の場面でも現れて、話を複雑にします。

1.3. 毒盛手法の分類について

きちんと定義がされないままで、現象を指すだけの言葉を広めようとすることの害:

1.3.1. 毒NS の分類

なにを毒として送りつけるかという視点からの分類:/NS  「どこからの返事として送りこむか」は別項目とした。 DNS/返答/referral か ../AncillaryDataAttacks

1.3.2. 目標の状態による分類

キャッシュされているものがなにかによって、話が違ってくる。/Ranking

  1. キャッシュにNSなし --> いわゆる「委任インジェクション」が狙う状態

  2. キャッシュに委譲のNS(親からの情報) JPRSのいう「移転通知インジェクション」 が狙う状態
  3. キャッシュに権威ありNS(Authority Section 由来) tssさんの「/移転インジェクション」で現れる状態

    • この場合にも上書きされる実装があったことはGhost Domain Names脆弱性のときに示されている。
  4. 権威ありNS(問い合せの結果、Answer Sectionで得られる)のキャッシュ。

https://twitter.com/beyondDNS/status/984349535475412993

1.4. RFC 2181

RFC2181のRankingを遵守するなら、これらの区別は必要だろう。 RRSetの優先順位が述べられている。

毒も考慮するとしたら、どうするのがより安全かは述べられていない。

これらの情報以外に、/zone cutが存在しないという情報が得られている可能性が大きい。(攻撃時)

DNS/NSレコードの上書きの害

1.4.1. どこからの返事なのか

委譲を示すNSも委譲する資格のあるサーバからのものかどうかを確認すること。

毒盛する側から見ても、どこからの返事として送りこむかは重要な点だ。

UDPではパケットの送信元を詐称するのは簡単だから、見分けるのは簡単ではない。

1.5. 対策

delegation responseをもらったら、すなおに受け入れてはいけない。

  1. /zoneの非存在が示されていないか。(攻撃だったら、キャッシュにマークがあるはず)

  2. TCPで問い合わせ直す。(nonce付きで)