== DNS/脆弱性/歴史 == <> == 2020 == [[DNS/毒盛/2020/saddns.net]] == あらまし == http://www.networkworld.com/article/2838356/network-security/dns-is-ubiquitous-and-its-easily-abused-to-halt-service-or-steal-data.html 2008年にKaminskyに指摘されても、まともな対応をしてこなかったことをはっきりさせようと、 経過を整理してみている。 参考文献も整理する必要がある。 [[DNS/毒盛/歴史]] 　 振り返ってみると、JPRSは常に後手後手です。（指摘されるまで、行動しないということがよく分かる） -- ToshinoriMaeno <> 落ちていることは、適宜追加してください。 (Kaminsky Blackhat 2009 も参考になる。事実とは限らないが） DNSSECを推進に熱心だったのに、なかなかうまく行かないために、 DNSSECを使えという宣伝はでてこない。 事情はよく分かっていません。 http://dnssec.jp {{{ DNSSECジャパン設置期間終了のお知らせ By dnssecjp, on 7月 17th, 2012 }}} == djbdns 以前 == DNS返答を偽造するまでもなく、ゾーンサーバが偽情報を送りこめた時代もあった。 (Kashpureff, alternic) http://www.secure64.com/news-internic-alternic-dns-poisoning {{{ Kashpureff Arrested in 1997 and Pleads Guilty to Computer Fraud July 1996 - Upset with Internic's control of top domain names, Eugene Kashpureff of Alternic poisoned multiple DNS caching servers which later redirected web traffic to www.alternic.com. }}} 　返答する権限のない情報をキャッシュ側で排除する仕組みが提案された。（bailiwick rule） 　　それでも、ゾーンサーバは送り続けているものが多い。 「TTLによる保護」というまやかし 　いまとなっては詳しく書く必要はなかろう。 == 1999 年 djbdns 公開 == DJB: [[DNS/実装/djbdns]](発表時はdnscache) 　 いろいろ重要なことはあるが、port randomization だけ書いておく。 [[DNS/実装/djbdns/DNSキャッシュをDNSサーバから分離することの重要性]] == 2002 ? == DNS Cache Poisoning – The Next Generation By Joe Stewart, GCIH https://www.ida.liu.se/~TDDC03/literature/dnscache.pdf == 2005 年 e-ontap.com == lame delegation の危険性、　消滅したドメインを参照することの危険性 visa.co.jp などが乗っ取りできる危険性は指摘していたが、現実に乗っ取れる状況が発生したので、 tssさんが保護した。　(visa 側は問題の存在自体を否定している。w) http://www.e-ontap.com/summary/fornondnsexpert.html http://www.e-ontap.com/summary/ https://www.ipa.go.jp/security/vuln/20050627_dns.html http://jprs.jp/tech/dnsqc/ http://jprs.jp/whatsnew/notice/before2011/problematic_ns_notice.html DNSサーバの登録と設定の確認 ～登録したJPドメイン名のDNS設定を確認するための手順～ http://jprs.jp/tech/material/tip0001.html JPRSがDNSサーバの危険な設定を削除開始 http://jprs.co.jp/topics/2006/060112.html == 2008 年 Kaminsky, Mueller == Kaminsky, Mueller の指摘　「TTLによる制約を受けない攻撃が可能であること」 「TTL による保護」という説明の間違いが示された。 民田らのスライド(Answer Section + Authority + Additional による毒) 　BINDの不良、　BIND 側の対策　（キャッシュが受け入れる必要のないものを受け入れている事情は?) http://www.atmarkit.co.jp/ait/articles/0809/24/news141.html https://www.dns-oarc.net/oarc/services/dnsentropy == 2009年 == Kaminsky のさらなる指摘。 DNSSEC に目をむけたのは失敗だったようだ。 (Blackhat 2009) 　セキュリティ業界はDNSを安全なものとは見ていない！ その後のDNSSECはどうだったのか。 ポート固定問合せを送ってくるキャッシュ利用者への警告サイトを作成（これをやっておいてよかった）。 　こういう活動をやっていたのは我々の他にはoarc とかもあった。 　　[開始時期がはっきりするといいですね。 2011 年のようです。] ... archive.org では 2011/7/23 が初出ですね https://web.archive.org/web/20110723103208/https://www.dns-oarc.net/oarc/services/porttest http://www.e-ontap.com/blog/20111102.html 危険なDNSサーバの利用者へ警告 JPRSなどはoarcを紹介するだけで、たいした活動をしてこなかったと思う。 {{{ 2010 年 退職 }}} == 2011 年 （東北大地震） == http://www.e-ontap.com/blog/20110208.html 浸透いうな これが脆弱性だと気づくのは 2012 年のこと。 鈴木による BIND 不良説確認 http://www.e-ontap.com/dns/bindmatrix.html 　ここでもMueller 手法は分かっていたけど、あぶなすぎて、はっきり書かなかった。 　　ポートランダム化が十分進んでいなかった思っていたからでしょう。 http://www.e-ontap.com/blog/20111018.html カミンスキー毒入れ攻撃の真実 別件： ゾーンサーバ移転時の「浸透しない」問題がRFC２１８１からみの動作だとはっきりしたのに、 　目がむいていなかった。 （東北大地震と福島原発でDNSどころではなかった。） == 2012 年 Ghost Domain Names 脆弱性 == [[DNS/GhostDomainNames]] DNS cache update policy の欠陥が問題だとはっきり書いてある。　-- ToshinoriMaeno <> ここでも BIND （ISC) の誤魔化しがある。 (一時しのぎにしかならないのに。） 　根本的な問題だからというのは正しいが、対応できない問題ではなかった。 結局はTTLの問題だけに対応して、毒盛の影響もTTLの制限内に収まるかのように扱った。 「浸透しない」はGDN脆弱性かもしれないと警告したのだが、反応なし。 10分でわかる幽霊ドメイン名と浸透問題の関係 http://dnsops.jp/bof/20120425/20120425-DNSOPS.jp-BoF_Ghost_Domain_Names_v02.pdf {{{ 9.2.2までのBIND 9では「浸透妨害攻撃」が成立する }}} あたかも「浸透」が存在するかのような説明をしている。 {{{ BIND 9.2.3以降ではNSの内容が同じだった場合、 受け入れないようにすることで浸透問題を回避した }}} {{{ 「NSレコードの内容（ホスト名）は違うが、 NSで指定されているホスト名のA／AAAAレコードの内容（IPアドレス）は同じ」 設定を意図的に作成 }}} ここまで書いていて、これがNS毒盛に利用できると気づかないとは考えにくい。 {{{ 論文の内容を理解することで、 DNSの委任のしくみや関係する諸問題に関する深い理解が得られます }}} 理解していないことが、明らかになったひとが言ってもねえ。 == 2012 共用ゾーンサービスの危険性 == {{{ 共用ゾーンサービスの危険性 (さくらなど） 未解決 }}} このときに共用ゾーンサービスの危険性に気づいたのも不幸なめぐりあわせだったかも。w 　　[[DNS/サービス/さくら脆弱性]] セカンダリDNS互助会というのもあった。 http://www.e-ontap.com/blog/20120614.html 他人と共用のDNS権威サーバは危険 http://jprs.jp/tech/material/iw2012-lunch-L3-01.pdf 親の心子知らず？ 委任にまつわる諸問題について考える http://www.geekpage.jp/blog/?id=2012/12/13/1　JPRSによる説明 　ここでも「委任」について説明している。（毒盛の可能性に気がつかないとは考えにくい） キャッシュサーバの動作は「きちんと」決められておらず、（偽返答を棚上げしても）怪しげな動作だとあります。 　それを小手先の修正でごまかしているのが、ISC BIND を作ってきたひとたち。 https://www.nic.ad.jp/ja/newsletter/No51/0800.html == 2014 年 毒盛再考Mueller手法 == co.jp など（本来NSレコードを持たないドメイン名）には簡単にNS毒が入ることに気づく。 　なぜいままで見落としていたかは、あきらか。　 Mueller 手法でほぼDNSは全滅状態だと分かっていたから、ほかのことは考えなかっただけ。 　ポートランダム化の重要性を再認識する。 JPRSはこのことから目をそらすために、dns.jp の問題を持ち出したように見える。 親子ゾーン同居はもともと想定外の運用で、あらたな問題点が指摘される可能性がある。 DNS キャッシュがAmp 攻撃に利用されている。 　毒盛を隠すことに使われているのでなければいいが。 dns.jp ゾーンへの毒盛が容易： 　ゾーンが存在していても、親子同居かつNSに子ゾーン内の名前を使っている場合。JPRSが気づいた。 NSキャッシュを上書きする実装の危険性はtssさんがBINDなどを対象にして、実験で確かめた。(NS移転通知型） Ghost Domain Names 論文でも同様の指摘がある。 DNS cache update policy の欠陥である。 JPRSが公開の場で、脆弱性を認めた。　https://yukar.in/note/ckFPy5 　でも、JPドメインにはいまも大きな脆弱性がある。（JPRSはどうするのだろう。半年以上対応していない） 信学技報, vol. 114, no. 216, IA2014-20, pp. 35-40, 2014年9月. == 2015年 NSキャッシュを上書きする危険性 == 2014年のJPRSの注意喚起以降のJPRSの講演でも、キャッシュを上書きする毒入れ手法はきちんと説明されていない。 　どちらかというと、この危険性に触れないようにしているように見える。（知らないはずはないから） == キャッシュでの対策 == === ランダムポートだけでは足りない === query source port randomization をしたとしても、攻撃の検知は欠かせない。　 　たかだか数日の連続攻撃で陥落する。 攻撃があったときにどう対応するかも難しい。キャッシュに対する要請しだいだから。 　たいして重要ではないキャッシュなら、簡単だが。 saddns (2020) === DNS/TCP のすすめ === TCPを使えばいい。 UDPでは偽パケットを見分けるのが困難だから。 TCPを使う負荷に耐えられないゾーンサーバはあるとしても、root, TLD くらいだ。 　それはroot, TLDゾーンサーバ管理者が努力すべきことだ。できないなら、DNS崩壊でもいい。 UDPを使いつづけたいのであれば、エントロピーを増やす改造をすべきなのに、やってきていない。 === DNSSEC はどうなったのか === JPRSはDNSSEC推進をやめたのだろうか。 http://jprs.jp/dnssec/ 　そういえば、DNSSEC推進団体は解散したのだったか。 {{{ 期間限定の組織ということで発足し、2年半程の活動を経て解散となりますが、 まだまだDNS、DNSSECを取り巻く環境には課題が山積しています。 DNSSECジャパンでの活動は終了しますが、今後とも業界内で連携して課題解決に取り組んで行くことができると信じています。 }}} これが最後のメッセージらしい。 -- ToshinoriMaeno <> Probable Cache Poisoning of Mail Handling Domains By Jonathan Spring on 09/10/2014 | Permalink https://www.cert.org/blogs/certcc/post.cfm?EntryID=206