<> [[/その後]] キャッシュにあるレコードに対する問い合わせにはリゾルバーはキャッシュ内のレコードを返答する。 {{{ キャッシュにないレコードを問い合わせることにより、外部への問い合わせを発生させ、 対する偽返答を受け取らせる。当時のBINDは問い合わせポートが53に固定されていた。 }}} これがKamiskyの指摘した攻撃法である。([[/2008]]年) この攻撃により、注入される毒はさまざまである。(リゾルバーの脆弱性) Muellerは同様の手法により、NSに毒を入れやすいことを示した。 Additional Sectionを使った毒盛を再検討する。-- ToshinoriMaeno <> [[/2020]]: https://twitter.com/securitytrails/status/1327015852718305280?s=20 ---- == DNS/毒盛/Kaminsky手法 == <> リゾルバーにDNS問い合わせを送り出させ、それに対する(偽の)返答を受け取らせることにより 　キャッシュ毒盛が成立することがある。UDPではパケット(送信元など)の偽造が容易だから。 Kaminskyはリゾルバーに「次々と」問い合わせを送り出させる攻撃手法を示した。(2008年） 　それまではキャッシュされた情報はTTLによって守られているから、大丈夫だと思われていた。 [[/TTL制約回避]] [[../雨だれ攻撃]] しかし、Kaminskyは問い合わせ名を変えて問い合わせするということだけを指摘していて、 具体的にどのような問い合わせを送りつけ、どのような返答を送り込むかは説明しなかった。 　示された例は問い合わせとして意味のないものであった。 　　[[/解説と対策(民田)]]にある例はBINDの脆弱性と言ってもよいものだった。 Kaminskyはキャッシュにない名前を問い合わせることで、リゾルバーに問い合わせを発生させる例を示し、 それにより毒盛可能な脆弱性があることを指摘した。問い合わせ名を変えることしか提案していないと言ってもよい。 　問い合わせ名を変えなくとも、query typeを変えることで、問い合わせを発生させることもできる。 このことはKaminskyは明示的には言っていない。 -- ToshinoriMaeno <> == 対策 == 対策としては問い合わせポートのランダム化が提案されただけだった。(djbdnsでは2000年以前に実装されている） == 攻撃例 == このため、攻撃者に利益のある毒がどのようなものであるかの憶測がなされた。 そして、 {{{ 　情報がキャッシュにあっても上書きされるという実装の不良と言ってもよい欠陥が暴露された。 }}} 　ほとんどがBINDなどの実装の脆弱性を示すものであった。（民田スライドなど） 　　　https://www.nic.ad.jp/ja/materials/iw/2008/proceedings/H3/IW2008-H3-07.pdf 攻撃手法のなかでも、Muellerの指摘(NS毒)は重要である。 2016年現在でも脆弱な実装が多い。(対策は提案されているが、実装されていない） DNSの仕組みに問題が潜んでいるという説には賛成できない。 {{{ Kaminsky-Mueller流の攻撃手法には対抗できる防御がある。（実装はまだ見あたらない） }}} == さらなる対策 == [[/キャッシュNS上書き脆弱性]] -------- Mueller流攻撃でNSを狙う攻撃の危険性がはっきりした。 　そして現状のリゾルバーには脆弱性があることも分かった。 これらに対する対策も明らかにした。実装が進めば、脅威ではなくなる。 {{{ なにを考えてきたかの記録の意味で残してある。 }}} [[DNS/毒盛/Mueller手法]] そして、簡単で効果的な対策を発見した。[[DNS/毒盛/Kaminsky手法/対策はある]] しかし、リゾルバーに組み込むところまでは行っていない。リゾルバーの構成が理解できていないためである。 リゾルバー作成者の説得を試みているが、成功していない。 -- ToshinoriMaeno <> ---- <> == 2008 == 2008年に Dan Kaminsky により報告されたキャッシュ毒盛攻撃手法　[[../Kaminsky講演]] https://kb.isc.org/article/AA-00924/0/CVE-2008-1447%3A-DNS-Cache-Poisoning-Issue-Kaminsky-bug.html Workarounds: None. (どういう意味なのか） リゾルバーに対して、 「キャッシュされていない名前(タイプ）を問い合わせる」ことにより、 問い合わせを発生させ、攻撃の機会を増やすものである。[[/TTL制約回避]] 具体的に毒が入れられるケースは説明しない、という立場のようです。（理由は不明） https://www.ietf.org/mail-archive/web/dnsop/current/pdf2jgx6rzxN4.pdf [[/Vixie]] 2008年当時では [[https://www.nic.ad.jp/ja/materials/iw/2008/proceedings/H3/IW2008-H3-07.pdf | 民田スライド]] が代表的説明だった。Additional Section のレコードが毒になっている。(これはBINDの不良だと思っている） スライド 21 {{{ Kaminsky型と他の方式の比較 • Kashpureff型との比較 –追加セクションを利用する点は同じ – Kashpureff型は現在の実装では外部名のため無視されるが、 Kaminsky型は内部名となるため、キャッシュ対象となる }}} だが、この説明は間違っている。(Mueller手法を参照） Kaminskyの示した例がまずいことから、導かれた誤解だろう。（あるいは分析不足か） 見直し中： http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html == なぜ説明がないのか == https://www.unbound.net/documentation/DNS_cache_poisoning_vulnerability.html BIND各バージョンへの毒入れ実験(2011) http://www.e-ontap.com/dns/bindmatrix.html Kaminsky の示した例では毒は入らなかった。 6年たって、Kaminsky攻撃手法の意味するところを理解しました。 　BIND関係者は最初からまじめに対応するつもりはなさそうです。本音はDNSSECを推進することにあるのでしょう。 https://www.ietf.org/mail-archive/web/dnsop/current/pdf2jgx6rzxN4.pdf Sourcefire Vulnerability Research Team Report July 25, 2008 http://users.auth.gr/basags/pubs/hase9.pdf Formal Analysis of the Kaminsky DNS Cache-Poisoning Attack Using Probabilistic Model Checking * http://www.atmarkit.co.jp/fsecurity/special/130dnspoisoning1/dnspoisoning01.html * http://www.nttv6.net/files/DKA-20080723.pdf　アクセスできないかも * http://www.topology.org/linux/bind_bigbug.html http://www.sec-pro.net/spnseminar081025_shio.pdf http://www.linuxjournal.com/content/understanding-kaminskys-dns-bug http://www.cs.berkeley.edu/~daw/teaching/cs261-f09/reading/matasano-kaminsky-dns-forgery.html [[/matasano]] http://dnsops.jp/event/20130719/20130719-undocumented-DNS-orange-6.pdf http://www.caughq.org/exploits/CAU-EX-2008-0002.txt http://www.caughq.org/exploits/CAU-EX-2008-0003.txt NS injection http://resources.sei.cmu.edu/asset_files/Presentation/2008_017_101_51416.pdf http://www.merit.edu/events/mjts/pdf/20081007/Blunk_DNSCachePoisoning.pdf Additional Section Exploits (BIND bug) == 解説、 議論 == Kaminskyは {{{ １. キャッシュされているデータのTTL制約を受けない攻撃手法 }}} が存在することを示した。 しかし、間違った例を示している。（意図的だとおもわれる。） slide 17 Enter The DNSRake より {{{ 3) Send rplies containig name server rediretions to www.foo.com --RANDOMwww.foo.com IN NS www.foo.com 　　 www.foo.com IN A 6.6.6.6 -- If this works, it works }}} ここのNS毒が入っても毒として使われることは考えづらい。 主目的はAレコードだと考えるのが妥当であるが、 このAレコードが毒入れできる機会は多くないだろう。　（glue なので） 実際に毒の入る例は示されていない。 その後、毒入れできる実例が見つかっているが、それはBINDの不良（脆弱性）を突いたものであった。 　だが、Kaminsky 型攻撃が使えることを示すには十分な例だった。 == 毒盛できる対象とは == Kaminskyの示した例（対象）では毒盛できない。どういう対象を選べば毒盛できるのだろうか。　[[/毒の例]] 　資料ではbailiwick検査に通れば、 毒盛に成功するように書かれている。 毒盛が成功する多くの例はKaminskyの例とは以下の点で違っている。 　Kaminsky は「委譲返答」で毒が入る可能性を示唆していた。 　しかし、攻撃成功したとの報告の多くはAnswer SectionにAuthority/Additional sectionつきであり、 　Additional Section の毒がキャッシュされたとある。　(これはのちにキャッシュ上書きの脆弱性だと分かる） これらは「委譲返答」ではありません！ {{{ この違いに意味があるかは明らかではありませんが、成功した毒盛手法は容易に対策可能なものです。 bindの動作不良だったようです。最新のbindではすでに対策されているようです。（説明はありません） 説明はbindの公開情報には見当たりません。　（非公開情報にはあるのかもしれませんが。） 　詳細を公開すると、攻撃に利用されるからという理由をいう人もいますが、これでは今後のためになりません。 きちんと追跡して、公開報告することはまだ行われていないようです。 　そのため、毒盛可能かどうかは個別に試して確認するしかありません。 手間もかかり容易ではありません。 -- ToshinoriMaeno <> }}} 委譲返答を使った毒盛も可能であり、非常に危険なため、詳細はここには書きません。 　Kaminsky が具体例を伏せた理由も同じだったかもしれません。 対策が進んだときに解説したいと思っています。 -- ToshinoriMaeno <> http://www.sec-pro.net/spnseminar081025_shio.pdf 30--31 にNS毒の話（検証ずみ）がある。 == 対策 == port randomization を行って、攻撃監視をしているなら、心配はいりません。 （注：2008年での話） 　現在では不十分です。-- ToshinoriMaeno <> 「キャッシュを上書きしない」なら安全かというと、そうではない。 　 キャッシュは一日一回クリアしましょう。 　よく使う名前はhostsファイルなどに書いておくのが安全です。 Paul Wouters: Defending your DNS in a post-Kaminsky world https://www.blackhat.com/presentations/bh-dc-09/Wouters/BlackHat-DC-09-Wouters-Post-Dan-Kaminsky-slides.pdf {{{ Before accepting glue records or additional data, independently verify these with new queries. }}} [[DNS/毒盛/NS毒盛/対策はある]] == おまけ == 権威サーバとキャッシュサーバは分離しましょう。兼用は危険です。 -- ToshinoriMaeno <> [[DNS/毒盛の脅威]] DNS 名前空間の構造（運用）に関連する脆弱性 http://delab.csd.auth.gr/~katsaros/hase9.pdf Formal Analysis of the Kaminsky DNS Cache-Poisoning Attack Using Probabilistic Model Checking https://samsclass.info/40/proj/p7-Kam.htm Performing the Kaminsky Attack http://users.auth.gr/basags/pubs/hase9.pdf ---- <>