1. DNS/移転インジェクション
DNS/毒盛/移転インジェクション 2024年現在も対策されていない。
DNS/毒盛/AncillaryDataAttacks の一種です。 (ですから排除は簡単です)
- 2008年には分かっていたことが、2015年現在も対策されていない。おそるべき怠慢といえる。
- 2018年現在でも攻撃が成功しそうなのはBINDとUnboundである。(Unboundは対策Option が用意されている。)
Kaminsky流の攻撃が成立する例として民田が示したのは
- Answer Sectionを持つ返答に付随するAdditional Sectionを使った攻撃だった。
- 同時期にMuellerはAnswer Section なしのAuthority Sectionを使ったdelegation攻撃が成立すると指摘した。
- こちらはこの項目とは別の脆弱性である。
Answer SectionなしのNoError返答(delegationではないことがAA onで示される)も攻撃手法としてあり得る。
上のAncillaryDataAttacksに含まれるのかどうかは読み取っていなかった。-- ToshinoriMaeno 2017-10-09 06:53:39
キャッシュにある(NS)レコードを上書きするような実装の不良だというのが、前野の主張であるが、
BIND流の考えに染まったひとには受け入れてもらえない。-- ToshinoriMaeno 2017-10-09 06:55:48
/com-net問題が理由かもしれないと思った。-- ToshinoriMaeno 2018-03-01 01:36:07
DNS/毒盛/NS毒盛/authanswerの書き換え : BIND 9.12.1 にも存在する脆弱性
../2014/移転案内攻撃 DNS/毒盛/2014/NS毒/鈴木の例
- なにを指しているかは場面により異なるので、この言葉を使うなら注意が必要である。(私は使わない)
d.t.e-ontap.com NS などを問い合わせることで、毒が入るかどうかが分かるサイト。
- www.d.t.e-ontap.com A を問い合わせて、 d.t.e-ontap.com NSのTTLなどが変化するかを見るとよい。
1.1. 分類
キャッシュにあるNSレコードがRFC 2181に書かれたどの状態にあるかによって、 いくつかに分類される。
1.1.1. 1
最初に使われたのはここだ。 2014-04-15 http://www.e-ontap.com/dns/endofdns2.html には以下のように説明があり、委譲情報を上書きするものだけを指していた。
委譲元から得た最低ランクの NS キャッシュを、 偽権威の Answer に付随する Authority Section の NS で上書きして毒入れすることができ、 そのゾーンを自由にできる。
JPRSもこの流儀のようだ。(別の名前で呼んでいるが) http://jprs.jp/tech/material/iw2014-lunch-L3-01.pdf
1.1.2. 2
その後、Answer に付随する Authority Section の NSがキャッシュされている場合にも 上書きされることがある(実装の不良)ため、 この場合も含めて鈴木は「移転インジェクション」と呼ぶようにしたとのこと。
http://www.e-ontap.com/blog/20140617.html
移転インジェクション脆弱性の確認方法: http://www.e-ontap.com/dns/flip.e-ontap.com.html
- 最近見なおしているが、説明と実際の返答とが一致しない。(返答が正しいとして、説明を直してみる。)
-- ToshinoriMaeno 2018-04-06 12:51:34 /確認方法
JPRSはこちらのケースには言及しない。いや、説明を避けている。RFC2181の責任だとしたいらしい。
https://www.janog.gr.jp/meeting/janog34/doc/janog34-dnsvl-morishita-1.pdf 実装の不良だとは認めたくないようだ。
-- ToshinoriMaeno 2015-11-02 03:31:40
この指摘は前野が行ったものです。
1.1.3. 3
そして、今年になって、権威サーバーにquery type NSで問い合わせて返ってきたAnswerにあるNSを Authority SectionのNSで上書きするリゾルバーが確認された。(BIND) (前野、鈴木) -- ToshinoriMaeno 2018-05-24 12:33:25
これにより、移転インジェクションは3種類に分けられる。
1.2. 結論
(1)「 移転インジェクション」は「いわゆる../委任インジェクション」とは区別して扱われるべき脆弱性である。
- RFCの問題というよりも、キャッシュを上書きする決定をしたリゾルバー実装の欠陥である。
(2)「移転インジェクション」は実装の不良、あるいは実装の選択結果であって、RFC 2181 の不良とするのは間違いである。
- (未定義なのを不良と呼ぶなら別だが。)
- もし、Unbound が上書き(毒)するなら、RFC2181にしたがっていないからだと思う。
- Answer Section (Authoritative Answer) で得ているはずの NS をキャッシュしているはずだから、 それを上書きするなら、同ランク以上のものでなければならない。(それも実装次第だが)
- もし、Unbound が上書き(毒)するなら、RFC2181にしたがっていないからだと思う。
(3) RFC2181の問題だと認識している識者もいるようだが、tssさんの指摘により、前野は上のように考える。
- tssさんに上書きの存在を指摘されるまで、RFC2181の不良説を受けて、深く考えることをしなかった。
つまり、上書きする実装が存在するという指摘はtssさんの貢献です。ここに明記しておく。 -- ToshinoriMaeno 2015-04-06 03:34:17
Knot DNS resolverのようにこの脆弱性をもたない実装も存在する。
- 前野はdjbdns(dnscache)に手をいれて、脆弱性を排除できることを確認した。
1.3. 別件
現状のUnboundでも../委任インジェクションは防御できていない。
- これはRFC2181に責任があるとも言える部分である。それでも、実装次第ではある。
TCPを使うのが簡単な回避策である。
「移転インジェクション」の闇は深い。
-- ToshinoriMaeno 2014-12-12 07:10:09