## page was renamed from DNS/毒盛/攻撃手法/移転インジェクション ## page was renamed from DNS/毒盛/移転インジェクション = DNS/移転インジェクション = <> <> [[DNS/毒盛/移転インジェクション]] 2024年現在も対策されていない。 [[DNS/毒盛/AncillaryDataAttacks]] の一種です。 (ですから排除は簡単です） 　2008年には分かっていたことが、2015年現在も対策されていない。おそるべき怠慢といえる。 　　2018年現在でも攻撃が成功しそうなのはBINDとUnboundである。(Unboundは対策Option が用意されている。) [[DNS/リゾルバー/RFC2181ランキング再考]] Kaminsky流の攻撃が成立する例として民田が示したのは 　　Answer Sectionを持つ返答に付随するAdditional Sectionを使った攻撃だった。 　同時期にMuellerはAnswer Section なしのAuthority Sectionを使ったdelegation攻撃が成立すると指摘した。 　　　こちらはこの項目とは別の脆弱性である。 Answer SectionなしのNoError返答(delegationではないことがAA onで示される）も攻撃手法としてあり得る。 　上のAncillaryDataAttacksに含まれるのかどうかは読み取っていなかった。-- ToshinoriMaeno <> キャッシュにある(NS)レコードを上書きするような実装の不良だというのが、前野の主張であるが、 　BIND流の考えに染まったひとには受け入れてもらえない。-- ToshinoriMaeno <> [[/com-net問題]]が理由かもしれないと思った。-- ToshinoriMaeno <> [[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などが変化するかを見るとよい。 　　http://www.e-ontap.com/dns/propagation/test/　　 [[/Knot-resolver]] 　http://www.e-ontap.com/blog/20151107.html == 分類 == キャッシュにあるNSレコードがRFC 2181に書かれたどの状態にあるかによって、 いくつかに分類される。 === 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 === 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 <>　　[[/確認方法]] JPRSはこちらのケースには言及しない。いや、説明を避けている。RFC2181の責任だとしたいらしい。 * http://jprs.jp/tech/material/iw2014-lunch-L3-01.pdf * https://www.janog.gr.jp/meeting/janog34/doc/janog34-dnsvl-morishita-1.pdf 　実装の不良だとは認めたくないようだ。 -- ToshinoriMaeno <> この指摘は前野が行ったものです。 === 3 === そして、今年になって、権威サーバーにquery type NSで問い合わせて返ってきたAnswerにあるNSを Authority SectionのNSで上書きするリゾルバーが確認された。(BIND) (前野、鈴木) -- ToshinoriMaeno <> これにより、移転インジェクションは3種類に分けられる。 == 結論 == (1)「 移転インジェクション」は「いわゆる[[../委任インジェクション]]」とは区別して扱われるべき脆弱性である。 　　　RFCの問題というよりも、キャッシュを上書きする決定をしたリゾルバー実装の欠陥である。 http://www.e-ontap.com/dns/endofdns2.html (２)「移転インジェクション」は実装の不良、あるいは実装の選択結果であって、RFC 2181 の不良とするのは間違いである。 　（未定義なのを不良と呼ぶなら別だが。） 　 もし、Unbound が上書き（毒）するなら、RFC２１８１にしたがっていないからだと思う。 　　　Answer Section (Authoritative Answer) で得ているはずの NS をキャッシュしているはずだから、 　　　それを上書きするなら、同ランク以上のものでなければならない。（それも実装次第だが） (3) RFC2181の問題だと認識している識者もいるようだが、tssさんの指摘により、前野は上のように考える。　　 　　tssさんに上書きの存在を指摘されるまで、RFC2181の不良説を受けて、深く考えることをしなかった。 　　つまり、上書きする実装が存在するという指摘はtssさんの貢献です。ここに明記しておく。　-- ToshinoriMaeno <> Knot DNS resolverのようにこの脆弱性をもたない実装も存在する。 　前野はdjbdns(dnscache)に手をいれて、脆弱性を排除できることを確認した。 == 別件 == 現状のUnboundでも[[../委任インジェクション]]は防御できていない。 　これはRFC2181に責任があるとも言える部分である。それでも、実装次第ではある。 TCPを使うのが簡単な回避策である。 「移転インジェクション」の闇は深い。 -- ToshinoriMaeno <>