1. DNS/毒盛
ここではDNS/キャッシュサーバーに/偽返答を受け入れさせることを指すものとする。
../キャッシュポイズニングとも言われる。
1.1. 2008
Kaminsky の指摘
1.2. 2012
1.3. 警告 2021
query source portを推測する手法 /2021 SADDNS 2.0
2020年に続いてのsaddns警告; 非常に危険なので、該当サイトは対策しましょう。-- ToshinoriMaeno 2021-11-29 02:23:17
ローカルゾーンに偽情報を置くものもある。(漫画村対策などで検討された。)
ゾーンサーバに偽情報を答えさせる攻撃はDNS/なりすましで扱う。
- (かつてはハイジャックと言っていたが、違うような気がするので、ハイジャックは使わない。)
1.4. 対策
アクセス制限が重要である。そして、エントロピーを大きくする。 権威サーバーにはTCPで問い合わせる。これに尽きる。DJB提案のDNSCurveもある。
- Cookie あり返答をしない相手にだけTCPを使うのでもよい。
DNSSECを使うと返答が長くなるので、フラグメントすり替え攻撃に弱くなる。
- UDPではフラグメント化パケットは破棄する。 この場合もCookie確認は必要だ。(長大返答に有効かは不明)
1.5. まとめ
- UDP返答には偽レコードを含め易い。
- DNSリゾルバーには返答中の偽レコードを受け入れる脆弱性が存在する。
- Kaminsky流毒入れ(絨毯爆撃)やフラグメント返答の部分置換などの手法がある。
- SADDNSはquery source portを推測するのにサイドチャネルを利用する。(Linux kernel不良)
毒を盛る対象として、効果が大きいのはNSレコードである。(狙われ易い。)
DNSSECを使わなくとも、偽レコードの多くは検出、排除できる。 だが、リゾルバー実装者は少なく、DNSSEC推進の立場が多くて、対策の進みは鈍い。
/概略 DNS/問合せ DNS/返答 /tweet /tweet/2 DNS/FCP
2. DNS/毒盛/索引
「毒入れ」と言うひとも多い。ここでは「毒盛」で統一している。 (中国語では投毒といわれることもある。)
Internet-Wide Study /KSW17 http://www.cs.colostate.edu/~cs557/papers/KSW17.pdf
DNS spoofing https://www.semanticscholar.org/topic/DNS-spoofing/806488
https://arxiv.org/pdf/1605.01394.pdf
2.1. 重要項目
/キャッシュにないNS Muellerの指摘(2008年) /Mueller手法 /2014
/キャッシュ内のNSレコードを上書きする毒盛は鈴木によって調べられている。/移転インジェクション
/対策はあるのに、実装がなされない。DNSSEC偏重の害だ。-- ToshinoriMaeno 2018-01-28 21:18:04
2.1.1. 脆弱なBIND
DNS/毒盛/BIND-trust-level RFC/2181 rankingの元になった実装
キャッシュにあるNSレコードを上書きする/NS毒盛はずっと放置されている。
2.2. 手法
以下の手法に共通するのは、確率的毒盛だ。
繰り返し攻撃することで、毒盛を成功させる。
/繰り返し攻撃が可能な条件も問題になる。(攻撃対象により変化する。)
2.2.1. Kaminsky 手法
/Kaminsky手法と/Mueller手法による/NS毒盛
/CNAME毒盛への応用も。 送信ポートランダム化などのエントロビー増加により脆弱性緩和。
2.2.2. Herzberg-Shulman手法
フラグメントに分割された返答の後部を偽データで置き換える
- フラグメント化させない対策、TCP利用など。
DNS 毒入れの真実 Oct 24, 2015 @DNS温泉補講 鈴木常彦 http://www.e-ontap.com/dns/poisoning_spa
- (前野やJPRSが指摘した内容も含まれているが、言及はない。)
Contents
3. NS毒について
NS RRSet という概念が重要だ。
- 「浸透いうな！」、「DNSサーバ移転」、「”Ghost Domain Names"脆弱性」、そして Mueller 手法 ...
3.1. 返答中のNS
偽のNSレコードを送りつける攻撃を検討する。 (参考： DNS/RFC/2181/s5 ranking ）
DNS query に対応する返答に現れるNSレコードはすくなくとも以下のむっつ（６）の異なる状況で使われている。
- NS query に対する返答: 現在はNSを問い合わせることはほとんど行われていない
- 委譲を確認する： （オレオレ）権威をもつゾーンサーバであることを確認するために返す。
- NS移転を示す： （オレオレ）権威をもつゾーンサーバがNS移転、追加を示すために返す。
- 問い合わせ削減用： ゾーンサーバが効率改善のためにおまけとして付ける。
- 余計なお世話： キャッシュ兼用サーバがキャッシュされた（権威を持たない）データ（多くは上位ゾーン）を返す。
- キャッシュ兼用でなくても、root を返すものもあるかもしれない。
1 で Answer sectionに現れる以外は Authority Section に現れる。
１、２ 以外は無用な返事であると言える。
- これらを受け入れるときには、十分な検査をして、毒の危険性を少なくすること。 受け入れたとしても、どう利用するかという問題もある。
３ はあった方がいいかもしれないが、信用するのは危険。
- answer の有無、nxdomain などで分ける必要があるのかも。
-- ToshinoriMaeno 2014-03-19 01:21:53
3.2. 検討
これらの使い方がどういう文書で裏付けられた根拠をもつのか、それとも実装が勝手にやっているだけなのか。
まずは RFC 1034 から。 NS の移転のケースは想定されていないらしい。 -- ToshinoriMaeno 2014-03-29 22:16:49
上方参照（余計なお世話）の典型はBINDが標準設定で返すと聞いたルートサーバ情報だ。 （こんなものを受け入れるリゾルバーがいまもあったら見てみたい。） 捨てられだけのものを送るのはネットワーク帯域の無駄使いでしょう。
2008年のKaminsky講演で使われたスライドに現れるNSは「委譲」、「移転」とは別ものだと考える。 民田スライドに現れるものはAnswer section がある返答に「おまけでつけられている NS RRSet」 だから。
「滲透しない」というひとがいるのも一部はDNSゾーンサーバの移転方法が関係している。 これも「移転」返答の処理に不良があるケースかもしれない。
Ghost Domain Names (鬼域名、幽霊ドメイン名）脆弱性は委譲ではなく、 「NSの移転」の処理に脆弱性（不良）があったのを攻撃されたものです。（ISCはDNSの本質的問題だと修正しない態度だった）
委譲（委任）を示す返答中のNS RRSet がもっとも重要であることは言うまでもないでしょう。 毒盛の対象として、一番狙われるものです。（でも、「なにが委譲なのか」はきちんと理解されているかどうかあやしい）
3.3. なにがキャッシュされているか
少なくとも以下のみっつの状態を区別して、検討する必要がある。
- キャッシュには関連NSはない。
- キャッシュに委譲を示すNSレコードがある。 (root-server からの返答など、 jp NS)
- キャッシュにゾーンサーバからAnswer として得たNSレコードがある。
3.3.1. 委譲毒
キャッシュに関連NSがない状態で、（上位）ゾーンサーバからの委譲を装う毒NSを送りつける。（Mueller手法）
JPRSは「委任インジェクション」と呼んでいる。 ../手法2014
co.jp, go.jp などの NSレコードを持たないドメイン名が狙われる。
3.3.2. 委譲変更毒
委譲を示すNSしかない状態で、ゾーンサーバからの返答を装う毒NSを送りつける。
- 移転インジェクション（tss)とか 移転通知インジェクション(JPRS) とか呼ばれているもの。
毒の可能性を考慮しないキャッシュはRRSetを置き換える。
- ただし、Ghost Domain Names 脆弱性対策として、TTLは制限される。
jp などの ccTLD などを調べてみよう。
3.3.3. 転居毒
ゾーンサーバからAnswer として得たNSレコードがキャッシュされているにもかかわらず、 ゾーンサーバからの返答を装う毒NSを送りつけると食ってしまうキャッシュサーバがある。（実装の脆弱性）
- tssさんは移転インジェクションと区別できていなかったと言う。JPRSの移転通知インジェクションには含まれていない。
毒の可能性を考慮しないほとんどのキャッシュはRRSetを置き換える。（2015年７月現在）
- ただし、Ghost Domain Names 脆弱性対策として、TTLは制限される。
-- ToshinoriMaeno 2015-07-26 00:20:23
3.4. 対策
いずれも対策は単純である。w -- ToshinoriMaeno 2015-07-26 00:20:23
3.5. JPRS
JPRS は転居毒について触れていない。
- キャッシュにあるNSが権威あるレコードである場合を無視しているのか、上書きの不良に触れたくないのか。
-- ToshinoriMaeno 2015-08-04 23:06:40