## page was renamed from DNS/毒盛2014 ## page was renamed from DNS/毒盛再考 <> ---- <> Vulnerability Note [[/VU#800113]] https://www.kb.cert.org/vuls/id/800113 = DNS/毒盛/2014 = 概要: [[/経緯]] Mueller手法によるNS毒盛が容易なケース(ENT)を見つけたので、 JPRSに連絡したら、ENT以外に他にもいくつか見つかった。 JPRSはこっそりと修正している。整合性のない説明を繰り返した。 こんな容易な重大な攻撃手法を見逃していたことを認めたくなかったらしい。 世界的にも認めたくないひとがほとんどだ。(DNSSECを使え、という反応) 2月に連絡したのに、連休直前まで警告をせず、その警告もポートランダム化を促すだけのものだった。 tssさんによる説明 http://www.e-ontap.com/dns/endofdns.html tssさんが学会で公表することになった。http://www.e-ontap.com/dns/pandora_ieice.pdf 電子情報通信学会 研究会 https://www.ieice.org/ken/program/index.php?tgs_regid=313a6a6912ff8cef0d9c569ac920c4b56b45859186da18eac77294035ab02a66 {{{ co.jp のように資源レコードをもたないドメイン名にはNS毒を入れやすいという指摘をした。 }}} 手法はMuellerが2008年に書いているとおりだが、身近のco.jpという影響の大きい名前が見逃されていた。 [[/Mueller手法]] JPRSの嘘 : [[To_tss/Mueller/2014-12-17]] JPサーバーが属しているdns.jpにも波及して、dns.jpドメインのNS変更(分離)を引き起こした。 JP が rootに登録している [a-m].dns.jp が ｢親子同居｣ 状態にあったことが悪影響していた。 JPRSは安定運用のためとだけしか説明していない。JPRSの姿勢が問われている。 -- ToshinoriMaeno <> 実際に行われた警告はport randomizationの奨励だけだった。 https://jprs.jp/tech/security/2014-04-15-portrandomization.html [[/ENT]] [[/実例]]　中国では「DNS缓存投毒」というようです。 通称「DNSキャッシュポイズニング」 のことをここでは （DNS）毒盛と呼んでいます。 DNSSECは使っていないという前提で検討しています。 [[DNS/毒盛]] と重複しています。(整理中） コメントは twitter @beyondDNS 宛にお願いします。 [[/経緯]] [[DNS/脆弱性/歴史]] キャッシュへの毒盛はたいした脅威ではないと考えるひとたち（JPRSの一部)もいるようです。 　　ポートランダム化は当然で、あとはDNSSECを使えばいいというひとたちもいます。 筆者はDNSなんて信用して使うものではないという立場です。それでも、キャッシュ毒盛は気になります。 2008 年に公表されている [[/Mueller手法]] を理解することが重要です。 それだけで十分とも言えます。 それには[[DNS/基礎知識/資源レコード/NS]] をしっかり理解することが重要です。 そして、[[DNS/キャッシュサーバ]]の動作が実装依存であることを知ることです。　-- ToshinoriMaeno <> DNSキャッシュポイズニング攻撃とその対策について改めて考える： http://www.ieice.org/~ia/archives/ia20140906/20140912-ia-fujiwara.pdf [[/偽案内攻撃]]は[[/Mueller手法]]で取り上げられています。特に重大と思われる[[/jpゾーン毒盛]] を議論します。 [[/unbound]] [[/lame_delegation]] http://www.e-ontap.com/dns/ipsj-tokai2.pdf http://www.e-ontap.com/blog/20140415.html == 結論と警告 == NS レコードには毒盛されやすい。毒盛されたときの影響が大きい。 {{{ 1. NS レコードを持たないドメイン名は毒盛され易い。　 2. NS レコードがキャッシュに保持され難いドメインは毒盛され易い。 親子ゾーンが同居している場合の子ドメイン側のNS 3. NS レコードは上書き(毒盛）されやすい。 (NS移転返答を装う毒) RFC2181, 実装不良である。 }}} 以上のみっつのケースが別々に指摘されている。　1,2 は Mueller 手法を適用するだけです。 [[DNS/毒盛/成立の要件]] [[/容易なケース]] で詳しく説明してみます。　-- ToshinoriMaeno <> 　今後、さらなる調査、分析が望まれます。 [[/対策]] にあるような対策をしてあれば、あまり心配する必要はないでしょう。 ---- [[../毒盛]] は散らかりすぎなので、整理してみる。 材料は [[DNS/毒盛/関連ページ]] [[DNS/毒盛/キャッシュ毒盛]] などを使います。 == 再考 == [[DNS/キャッシュ毒盛/2014]] 　重要なのはここです。　[[DNS/毒盛/成立の要件]] 　危ないことに気づいたのは [[watch-zone/jp]] あたりからです。 {{{ NSキャッシュの上書き問題については、遅くとも２０１２年の Ghost Domain Names 脆弱性で 気づいていなければならなかった。 }}} RFC２１８１ 上書きについては検討不十分なため、今後の課題ということにします。 [[DNS/毒盛再考/root-servers.net]] 　　[[DNS/NSレコード/返答中のNS]]　　tss さんの blog http://www.e-ontap.com/blog/20140415.html http://www.e-ontap.com/dns/pandora_ieice.pdf 移転の便宜のためのはずが、毒盛に使えるという心配が： [[DNS/コンテンツサーバ/移転/JPRS手順]] [[DNS/GhostDomainNames]]　[[DNS/浸透問題]] にも関係があります。 [[DNS/ゾーンサーバの移転手順再考]] TTL は毒盛防止のためにあるわけではないし、毒盛防止には役立たない。 JPNIC解説： https://www.nic.ad.jp/ja/newsletter/No40/0800.html [[/e-ontap]] : tss さんのサイト == 観察 == こんな観察が公表されている。 毒盛攻撃は始まっていると思うべきでは。　（2008 年から続いているのかも） 　https://indico.dns-oarc.net//getFile.py/access?contribId=23&resId=0&materialId=slides&confId=19 {{{ Auth servers often fail, if they stay up they usually give back NXDOMAIN Recently we also see NODATA, NOERROR returned }}} 「実際に見たことがない」というひとがいたので、紹介しておく。 　　理解する気がなければ、見えていても見えない。w https://www.cert.org/blogs/certcc/post.cfm?EntryID=206 == 毒盛/Kaminsky == [[DNS/毒盛/Kaminsky手法]] -- [[/Kaminsky手法]] : 2008 年の BlackHat 講演で公表されたもので、原理は簡単です。 　TTLによる制約は幻だったことを示したものです。 == Mueller 手法 == [[/Mueller手法]] Kaminsky とほぼ同時期に公表されたもので、これも原理は簡単です。 * 偽NSレコードを毒として注入する。 　 NSレコードがキャッシュされていない名前を狙うというのがMueller の指摘です。 ほぼすべての www に毒盛可能だということが指摘されていましたが、重視されなかった。（なぜだろう。） tss さんはキャッシュの上書き（RFC2181 ranking)を利用した毒盛も試しています。　http://www.e-ontap.com/dns/endofdns2.html （実装依存なので、自分では手を出さないことにしています。） 参考： The Hitchhiker’s Guide to DNS Cache Poisoning 　[[DNS/毒盛/Guide/議論]] == 現実の構成 == NSレコードが存在していない（つまりキャッシュされていない）ドメイン名（例： co.jp ) が身近にあることに気づいた。 (2014-02) これは危ないということで、JPRSにも連絡しました。すぐに対応されるだろうと期待したのだが、... -- ToshinoriMaeno <> JPRSはキャッシュサーバの運用者にポートランダム化対策などを呼びかけただけだった。 (2014-04-15) 　http://jprs.jp/tech/security/2014-04-15-portrandomization.html JPCERTにも連絡してあるはずなのに、これだけの注意喚起しかない： 　https://www.jpcert.or.jp/at/2014/at140016.html == ポートランダム化対策 == ポートランダム化対策すらしていないキャッシュサーバが IP アドレスにして 10% も残っている。 　私は10％に収まっていてよかったと思うほうだ。 インターネットはこういう管理者がいることを前提に使っていくしかないものだと思っている。 　つまり、毒の入りそうなキャッシュサーバは使わないという自衛手段が必要だということです。 == ポートランダム化以外の対策 == UDPを使っていると時間をかければ、毒盛はいつかは成功する。(DNSSECを使えばいいのかもしれないが） 　毒盛攻撃を検知して、キャッシュをクリアすることが重要である。 あまり普及していないようだが、いろいろ対抗手段はある。別途[[/対策]]で取り上げる。　 　一番のおすすめはTCPを使うこと。 Kaminsky 攻撃が公表されてから6年が過ぎようとしているのに、 　ポートランダム化という貧弱な対策が主たる対策として推奨されているのは残念なことだ。 　　対応していないNATを責める前にやることがあるだろう。-- ToshinoriMaeno <> http://tools.ietf.org/html/draft-barwood-dnsext-fr-resolver-mitigations-08 Resolver side mitigations draft-barwood-dnsext-fr-resolver-mitigations-08 == 被害を受けるのはだれか == [[/gouv.fr]] も co.jp と同様の問題があるのだが、nic.fr のひとは指摘を理解できないようだ。 DNSSEC を使わないのがいけない、と言っているようにも見える。DNSSECの普及度を知らないのか。危険性を理解していないのか。 2008 年にKaminskyが攻撃手法を公開したときに、もっとしっかり洗い出ししていればと思う。 　攻撃側が当時から分かっていて、こっそり利用していたということがないことを願うばかり。 いまは早く広く知らせることが重要だと考える。-- ToshinoriMaeno <> 　ひとことまとめ： 危険なキャッシュサーバを見分ける目が必要です。 == どうやって公表するか == {{{ 脆弱な構成を知る前から、毒盛の危険性があることは警告しつづけていた。 }}} (JPRSはなにをやっていたか） {{{ co.jp のことを見つけて（2/15 に通告)からは、Mueller 手法の紹介、解説を続けた。 }}} DNSをある程度理解していれば、「co.jp が毒盛に弱い」という指摘だけで攻撃を開始するだろう。 　６年前から分かっていた手法を使うだけだから。 {{{ それでも、JPRSがどのような注意喚起をするかを見定めるまでは公表は控えた。 }}} 　OpenSSL の HeartBleed 脆弱性が公表されたことも影響している。 だが、co.jp などが危ないということを知っていながら、 {{{ いつまでも警告しないのもまずい。　　　 }}} 　実際に被害を受けるのは攻撃サイトに誘導される利用者だから。 4/15 づけのJPRSの注意喚起では不十分ということで、tssさんがblog に書いたのと合わせて、 自分のwikiでも、co.jp が危ないということが見えるようにした。（2014-04-15) -- ToshinoriMaeno <> tss さんの blog http://www.e-ontap.com/blog/20140415.html あるところでの反応：　http://security.slashdot.jp/story/14/04/16/0555243 http://www.e-ontap.com/dns/ipsj-tokai2.pdf == まとめ == 「キャッシュ毒盛」、「ゾーンサーバの移転トラブル（浸透まち）」、「Ghost Domain Names 脆弱性」 などはすべて同じ 問題から生まれています それはDNSで、ドメインを分割管理するための委譲（委任）方法がきちんと定義されてないからだと考えます。 　あるいはキャッシュサーバがなにをどうキャッシュするかがはっきりしていない（実装依存）からだと言ってもいいでしょう。 -- ToshinoriMaeno <> = DNS/毒盛2014/まとめ = 結論： キャッシュサーバ側での対策 6 を使うのがよい。　-- ToshinoriMaeno <> TCPを使うのが望ましいが、ただちに全面採用は難しいだろう。 == 毒盛しやすいみっつのケース == 1. NS レコードを持たないドメイン名は毒盛され易い。　（ドメインの構造・構成による）　 2. NS レコードがキャッシュされることが少ないと、毒盛され易い。 　　親子ゾーン同居などでは、子孫側のNSがキャッシュされることがまれである。 3. NS レコード自体が上書き(毒盛）されやすい。（RFC2181） 　　 NS移転通知を装う毒が可能な実装が多い。 == キャッシュ側での対策 == 1. 問合せポートをランダム化 2. アクセス制限 (やった方がよいが、内部からの攻撃もありえる） 3. 共用キャッシュの提供中止 （内部からの攻撃もありえる） 4. UDPを使わない。（TCPにより問合わせる） 5. 毒盛攻撃の検知と即時対応 6. [[../NS 毒盛対策を強化したキャッシュ]]の利用： 1. 問合せしなおし、2. 余計なお世話を排除 7. その他（DNSSEC?)　DNSCurve もある。 中間者攻撃対策にはDNSSECは手間がかかるので、DNSCurveを検討するのがよいだろう。 -- ToshinoriMaeno <>