## page was renamed from DNS/毒盛/まとめ ## page was renamed from DNS/毒盛 = DNS/毒盛 = <> DNSの基礎的知識があることを前提にします。 [[DNS/返答]] 公開リゾルバーは'''Off Path Attack'''を受けます。どう防ぐかが重要です。 '''毒盛攻撃'''の概要と防衛(検査)方法'''[[/対策]]'''を解説します。 そのあと、DNSキャッシュへの毒盛を目的にした[[/攻撃手法]]を説明します。 '''UDP'''では容易に成立する'''中間者攻撃'''は考慮しません。 {{{ 中間者攻撃による偽情報(毒)の混入はDNSだけの問題ではないので、ここでは扱いません。 現状のDNSSECはDNS情報だけを保護するものとしては手間がかかりすぎです。 }}} {{{ 　防御には管理の複雑なDNSSECは必要ありません。 }}} [[/索引]] 　[[/歴史]] UDP をやめるのが第一歩です。TCPを使うならDNSSECもいらない。 . TCP でも危険だと、TCP利用を止めようとするひとたちもいます。 == はじめに == キャッシュ毒盛攻撃は リゾルバーに対する攻撃です。 . リゾルバーにDNS問い合わせを送り出させ、それに対する(偽の)返答を受け取らせるものです。。 . UDPではパケット(送信元)の詐称が比較的簡単なことを利用します。 . https://www.nic.ad.jp/ja/materials/iw/2008/proceedings/H3/IW2008-H3-07.pdf 毒盛攻撃はゾーンサーバのふりをして、[[DNS/リゾルバー]]に偽の[[DNS/返答]]を受け取らせ偽情報をリゾルバーのキャッシュに入れ させることを狙います。成功したら、リゾルバーは嘘の返答をすることになります。 毒盛されると[[/影響]]が大きいのは'''NSレコード'''です。([[/NS毒盛]]) そして、[[/CNAME]], [[/NXDOMAIN]]を使った毒盛についても考察します。 === リゾルバーの現状 === 現存のリゾルバーはすでに得ている情報(キャッシュにある)とは''矛盾する返答''であるにも拘らず受け入れてしまう、 という欠陥を持っています。つまり、毒の検査が不十分ということです。[[/毒見]]　[[/危険なサーバー]] . '''RFC 2181'''を持ち出して、毒盛される言い訳にするのは筋違いです。予め断っておきます。 木構造のドメイン構造と上位に問い合わせ負荷が集中する実装に問題があります。 . それを避けるためとは言え、毒盛耐性を弱めるようなことをしていいとは思えません。 '''キャッシュ優先'''を実施しても負荷増大は問題にならないことを示すつもりです。-- ToshinoriMaeno <> 2008年のKaminskyの警告を受けてのdraftと思われるが、これを実装しないのはなぜか。 Comprehensive DNS Resolver Defenses Against Cache Poisoning . draft-weaver-dnsext-comprehensive-resolver-00 https://tools.ietf.org/html/draft-weaver-dnsext-comprehensive-resolver-00 === 運用妨害 === 正規のサーバが通常動作をしているという前提での防衛策は 正規サーバが(DoSなどにより）返答しなくなっている場合には有効に機能しません。 . 十分準備した攻撃者には対抗できないのかも。 [[/運用妨害]] == キャッシュ優先の原則 == [[/キャッシュにあるレコードは上書きしない]]ことで、多くの毒盛は撃退できます。[[/脆弱性の歴史]] そうすると、残る問題は新たにキャッシュに登録するときということになります。（登録は慎重に） このページでは主に どういう返答であれば、有効な毒となるかを考えます。 . Kaminsky-Mueller流攻撃を利用した[[/NS毒盛]]を扱っています。 * 中間者攻撃は扱いません。暗号化されていないUDPパケットは盗聴/偽造し放題ですから。 * DNSSECは使いません。手間がかかりすぎです。（間違いやすい）[[/誤解]] ---- [[/攻略手順]] http://nominum.com/ghosts-in-the-dns-machine/ == 偽返答を送られにくくする == === DNS Cookies === Domain Name System (DNS) Cookies　　M. Andrews　May 2016 https://tools.ietf.org/html/rfc7873 これが実装されて、普及すれば毒盛はほぼ無理になる。だが、いつになるだろう。 . 実現までに簡単にやれる対策もある。 === DNS返答の嘘を見破る === リゾルバー側で[[/NS毒盛]]を簡単に十分に防御できる方法を[[/2016]]で説明しています。 . (まだ実装がない）簡単な対策があるのに放置されている。 いまや実装の不良と呼んでもいいでしょう。 . DNSSEC推進の立場のひとはMITM攻撃以外に関心はないのでしょうか。 [[/NS毒盛]]以外の攻略は現在では困難だと考えています。 . 例：Kashupureff型攻撃、CNAME攻撃、[[/移転インジェクション]]　/AncillaryDataAttacks [[DNS/用語/glue]] [[DNS/毒盛/AncillaryDataAttacks]] . https://tools.ietf.org/id/draft-weaver-dnsext-comprehensive-resolver-00.html . 一番信用ならないのは/AuthoritySection [[/CNAME]] も危ない。 [[/MX返答]] はどうか。[[/SOA]]はどうか。 「キャッシュにあるレコードは書き換えない」という原則を守るのが重要だが、 RFC2181というおかしなRFCが障害になる。 [[DNS/毒盛/2014/移転案内攻撃]] [[DNS/毒盛/対策/NXDOMAIN返答活用]] はいかが。（実装されているリゾルバーはまだないｗ） == 毒盛とは == [[DNS/リゾルバー]]に偽の情報(DNSレコード)を送り込むことです。 危険性の大きさに配慮して、NS毒以外のものは当面の考察の対象外とします。 NSレコードを目標とした毒盛の解説： [[/毒NS]]　[[/NS毒盛]] CNAME返答を利用する毒: [[/CNAME]] glue を目標とした毒盛： [[/毒glue]] [[DNS/脆弱性/GhostDomainNames]] ---- [[/キャッシュサーバ]]がどのように振る舞うかは実装依存です。　[[/NS毒盛]] では検討します。 [[/部品紹介]] [[/キャッシュサーバ]] [[/成立の要件]] [[/ゾーンサーバの監視]] http://cloud.watch.impress.co.jp/epw/cda/security/2008/08/28/13724.html 「ポートランダム化もすでに破られている」 [[/wikipedia.org]] nicの説明だが、間違いも： https://www.nic.ad.jp/ja/newsletter/No40/0800.html === 2014 年にあらたな展開 === [[/2014]] * Mueller の「委譲毒盛」を使った攻撃の再評価（前野）で、 co.jp などに簡単に毒が入ることがわかった。 * 鈴木は NS が上書きできる実装が多いことを確認した。　(キャッシュされているほぼすべてのNSかも） http://www.e-ontap.com/blog/20140415.html 長年放置されてきた DNS の恐るべき欠陥が明らかに . http://www.e-ontap.com/dns/endofdns.html http://www.e-ontap.com/dns/endofdns2.html [[/委任インジェクション]] はNS毒盛に属する攻撃（の一部）にJPRSがつけた呼び名です。 JPRSは注意喚起を出すはずだったが、Kaminsky流攻撃が増えているとの注意喚起だけでお茶を濁した。 このページも続きが出なかった。http://www.geekpage.jp/blog/?id=2014/4/25/1 === 攻撃手法 === [[/キャッシュ毒盛]] [[/雨だれ攻撃]] [[https://en.wikipedia.org/wiki/DNS_spoofing|DNS_spoofing]] [[/成立の要件]] [[/taxonomy]] [[/poison]] https://moin.qmail.jp/DNS/RFC2181/s5 [[/Guide]] [[/Shmatikov]] https://www.nic.ad.jp/ja/newsletter/No40/0800.html　[[/nicの説明]] https://tools.ietf.org/html/rfc5452 [[DNS/攻撃/fragmentation]] UDP 返答パケットで分割を引き起こすとすり替えやすい。 == 経緯 == === Kaminsky 攻撃 === * Kaminsky流の攻撃手法により、毒盛の防御にはTTLは役にたたないことが示されました。 [[/Kaminsky手法]] {{{ Kaminsky 手法は「キャッシュされていない名前を問い合わせる」ことにより、「毒を送りつける機会を増やす」ものである。 }}} * どういうレコードをキャッシュさせるか（毒盛するか）は、次の段階の話です。 * Kaminsky が示した例では当時のBINDにすら毒盛できませんでした。 . BIND各バージョンへの毒入れ実験 (Kaminsky Bug の検証) http://www.e-ontap.com/dns/bindmatrix.html . https://www.nic.ad.jp/ja/materials/iw/2008/proceedings/H3/IW2008-H3-07.pdf 民田スライドを参照 * http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html glue に毒らしい。 {{{ The authority data may well contain the "real" bankofsteve.com nameserver hostnames, but the glue points those nameservers at badguy IPs. }}} [[DNS/毒盛/Kaminsky手法/JPRS資料]] 2008年に見た資料では一番よかったもの：　 DNSにおけるキャッシュ汚染攻撃 http://www.sec-pro.net/spnseminar081025_shio.pdf * しかし、 [[DNS/node_re-delegation]]の報告にあるように「委譲返答」を使った攻撃が有効であると分かっています。 . [[/Mueller手法]] による「委譲返答攻撃」 と呼びます。 === Mueller の委譲返答攻撃 === Mueller は偽委譲返答（NSなど）を送りこむ攻撃が考えられると言っています。　[[DNS/毒盛/Mueller手法]] Mueller paper の指摘では {{{ 　キャッシュにないレコードを毒として注入します。ここでもTTLは関係しません。（ランキングも） }}} ここまでが2008年に明らかになったことです。（それに世界が気づいていなかったとしたら不思議です。） 問い合わせポートのランダム化である程度の防御ができるからでしょう。 [[DNS/NSレコード/返答中のNS]] === Ghost Domain Names === そして、2012年には[[DNS/GhostDomainNames]]脆弱性が指摘されています。(これもキャッシュへの毒盛です） . （上位サーバで）登録を削除されたはずのドメイン（幽霊）をキャッシュサーバに残す（活かし続ける）というもの。 関連して「[[DNS/共用サービスの危険性]]」を指摘しました。（サブドメイン登録など一部の問題は改善されました。） unbound などのキャッシュサーバ（実装）での対策も追加されていますが、十分利用されているとは言えません。 -- ToshinoriMaeno <> == いまも残る脅威 == A レコード(web サーバやDNSゾーンサーバ) はキャッシュされていることが多いので、対象としません。 リゾルバー側で簡単に実装できる対策が存在するにもかかわらず、なぜか実装されないために、 残っている脆弱性があります。 === NSレコード === Mueller 手法にある NSレコードを狙うのが有効そうです。 RFC2181 では参照返答に含まれるNSレコードでキャッシュを上書きしてよいか、あいまいです。 . Mueller 手法で簡単にNSに毒を入れられるキャッシュ実装もありそうです。 {{{ 正規の返答がNXDOMAINであるような問い合せを送るので、 　毒盛したいNSレコードがキャッシュさせられることがない。 これにより効果的な攻撃になります。 }}} --> Kaminsky 流の「存在しない下位の名前」を問い合せて、一段上位のNSを返答します。 === NSレコードをもたないノード === 現実のDNSゾーン構成を観察すると、簡単に毒盛できそうなケースが多数見つかります。 . 2月に通報済みです。-- ToshinoriMaeno <> NSレコードを持たないノードです。たとえば、co.jp などの属性型JPドメイン名のおおもとです。 . JPRSはいまもこのことを説明していません。　-- ToshinoriMaeno <> === キャッシュの上書き === [[/移転通知インジェクション]] . !!! リゾルバーの実装にこんな欠陥が。　これは不良と呼ぶべきものです。 Internet Week 2014 ランチセミナー 未熟なDNSと今後どう付き合うべきか . スライド１２ {{{ 移転通知インジェクション攻撃 – 移転通知(子のNS)は委任応答(親のNS)よりも信頼度(trustworthiness)が上 • RFC 2181 5.4.1. Ranking data – 上記仕様に準拠しない実装では攻撃は成立し}ない }}} . この説明は間違い。キャッシュを上書きする実装をよく調べましょう。 == いますぐ確認して欲しいこと == {{{ ゾーンサーバとキャッシュサーバは分けていますか。 }}} {{{ キャッシュサーバのポートランダム化はお済みでしょうか。 }}} http://snoopy.e-ontap.com/　　　http://snoopy.e-ontap.com/announce.html . 危険なDNSサーバの利用者へ警告を行う活動を行っています == 毒盛に使う毒 == * キャッシュサーバにキャッシュされていなくて、 * 正当な権威サーバからの返事には含まれていなさそうで、 * 偽返答なら受け入れられそうなレコードとは： Answer Section ではなさそうですね。 Mueller にあるように Authoriyt Section 内の NS レコードが一番狙われ易い。 . [[DNS/Authority_Section_Poisoning]] なかでも、[[DNS/委譲毒盛]] はターゲットを発見できれば、すぐにも毒盛できてしまう危険な手口です。 == キャッシュにあっても危ないかも == キャッシュが優先されて、置き換えが起きないのなら、 余計なお節介のNSレコードも毒盛防御には役にたっているのかもしれない。 でも、置き換えられるのではないか。 [[DNS/RFC2181/s5]] [[/root-servers.net]] 「毒入れの原理」という言葉を使うひとはどういう意味で使っているのだろう。 . 「原理」というような概念があるなら、はっきりした説明があると思ったが、見つからない。 毒が入れられるような「DNS（実装）の欠陥」、あるいは「DNS設計の欠陥」という方がふさわしい呼び方だと考える。 -- ToshinoriMaeno <> == 参考情報 == Comprehensive DNS Resolver Defenses Against Cache Poisoning . draft-weaver-dnsext-comprehensive-resolver-00 https://tools.ietf.org/id/draft-weaver-dnsext-comprehensive-resolver-00.html 1. Cache Policy, Scoping, and Ancillary Data Attacks /AncillaryDataAttacks https://engineering.purdue.edu/kak/compsec/NewLectures/Lecture17.pdf Lecture 17: DNS and the DNS Cache Poisoning Attack by Avi Kak ( kak@purdue.edu ) [[DNS/キャッシュサーバの動作/毒盛耐性]] http://www.e-ontap.com/dns/bindmatrix.html (Kaminsky Bug の検証) [[DNS/GhostDomainNames]] [[DNS/GDN]] [[DNS/NSレコード/返答中のNS]] http://maradns.samiam.org/deadwood/doc/Recursive-algorithm.html [[DNS/BINDの歴史/場当たり的対応]] http://dnsops.jp/event/20130719/20130719-undocumented-DNS-orange-6.pdf 教科書には載っていないDNS　（JPRS　森下） <> <>