1. DNS/毒盛

DNSの基礎的知識があることを前提にします。 DNS/返答

公開リゾルバーはOff Path Attackを受けます。どう防ぐかが重要です。

毒盛攻撃の概要と防衛(検査)方法/対策を解説します。 そのあと、DNSキャッシュへの毒盛を目的にした/攻撃手法を説明します。

UDPでは容易に成立する中間者攻撃は考慮しません。

中間者攻撃による偽情報(毒)の混入はDNSだけの問題ではないので、ここでは扱いません。
  現状のDNSSECはDNS情報だけを保護するものとしては手間がかかりすぎです。

 防御には管理の複雑なDNSSECは必要ありません。

/索引  /歴史

UDP をやめるのが第一歩です。TCPを使うならDNSSECもいらない。

1.1. はじめに

キャッシュ毒盛攻撃は リゾルバーに対する攻撃です。

毒盛攻撃はゾーンサーバのふりをして、DNS/リゾルバーに偽のDNS/返答を受け取らせ偽情報をリゾルバーのキャッシュに入れ させることを狙います。成功したら、リゾルバーは嘘の返答をすることになります。

毒盛されると/影響が大きいのはNSレコードです。(/NS毒盛) そして、/CNAME, /NXDOMAINを使った毒盛についても考察します。

1.1.1. リゾルバーの現状

現存のリゾルバーはすでに得ている情報(キャッシュにある)とは矛盾する返答であるにも拘らず受け入れてしまう、 という欠陥を持っています。つまり、毒の検査が不十分ということです。/毒見 /危険なサーバー

木構造のドメイン構造と上位に問い合わせ負荷が集中する実装に問題があります。

キャッシュ優先を実施しても負荷増大は問題にならないことを示すつもりです。-- ToshinoriMaeno <<DateTime(2017-1

/否定返答

1.2. 基本的対策

/対策 にまとめました。

  1. アクセス制限(できれば、他人には使わせないw)
  2. 問い合せのエントロピー増加策 (ポートランダム化など) あるいはTCP利用
  ルータがNATで使うポートにも注意が必要です。
  3. 不審な問い合せをしていないかの24時間監視

これらは手間がかかるので、すべてが実施されているとは限らない。

ポートランダム化検査:http://snoopy.e-ontap.com/

1.2.1. 対策はあります

キャッシュサーバへの毒盛は/防衛できると考えています。DNSSECは必要ないと思います。

キャッシュサーバへの/実装が普及していないのが大きな問題です。

現時点で知られている毒盛手法に対してはいくつかの簡単な対策があります。対策は 毒を紛れ込ませ難くする方法と紛れ込んだ毒を判別する方法に分けて考察します。

リゾルバーは非公開に(アクセス制限)するのが簡単な対策ですが、 利用者が多ければ、内部からの攻撃にも配慮しなければなりません。

https://thehackerblog.com/respect-my-authority-hijacking-broken-nameservers-to-compromise-your-target/

Knot resolverであれば、私が知るかぎりの攻撃は実用上十分な対策が出来ています。 (対NS毒盛、対CNAME毒盛には私的パッチを適用して、確認中です。) -- ToshinoriMaeno 2017-05-06 00:12:08

2008年のKaminskyの警告を受けてのdraftと思われるが、これを実装しないのはなぜか。

Comprehensive DNS Resolver Defenses Against Cache Poisoning

https://tools.ietf.org/html/draft-weaver-dnsext-comprehensive-resolver-00

1.2.2. 運用妨害

正規のサーバが通常動作をしているという前提での防衛策は 正規サーバが(DoSなどにより)返答しなくなっている場合には有効に機能しません。

/運用妨害

1.3. キャッシュ優先の原則

/キャッシュにあるレコードは上書きしないことで、多くの毒盛は撃退できます。/脆弱性の歴史 そうすると、残る問題は新たにキャッシュに登録するときということになります。(登録は慎重に)

このページでは主に どういう返答であれば、有効な毒となるかを考えます。


/攻略手順

http://nominum.com/ghosts-in-the-dns-machine/

1.4. 偽返答を送られにくくする

1.4.1. DNS Cookies

Domain Name System (DNS) Cookies  M. Andrews May 2016 https://tools.ietf.org/html/rfc7873 これが実装されて、普及すれば毒盛はほぼ無理になる。だが、いつになるだろう。

1.4.2. DNS返答の嘘を見破る

リゾルバー側で/NS毒盛を簡単に十分に防御できる方法を/2016で説明しています。

いまや実装の不良と呼んでもいいでしょう。

/NS毒盛以外の攻略は現在では困難だと考えています。

DNS/用語/glue

DNS/毒盛/AncillaryDataAttacks

「キャッシュにあるレコードは書き換えない」という原則を守るのが重要だが、 RFC2181というおかしなRFCが障害になる。

DNS/毒盛/2014/移転案内攻撃

DNS/毒盛/対策/NXDOMAIN返答活用 はいかが。(実装されているリゾルバーはまだないw)

1.5. 毒盛とは

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

1.5.1. 2014 年にあらたな展開

/2014

http://www.e-ontap.com/blog/20140415.html 長年放置されてきた DNS の恐るべき欠陥が明らかに

/委任インジェクション はNS毒盛に属する攻撃(の一部)にJPRSがつけた呼び名です。

JPRSは注意喚起を出すはずだったが、Kaminsky流攻撃が増えているとの注意喚起だけでお茶を濁した。

このページも続きが出なかった。http://www.geekpage.jp/blog/?id=2014/4/25/1

1.5.2. 攻撃手法

/キャッシュ毒盛 /雨だれ攻撃 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 返答パケットで分割を引き起こすとすり替えやすい。

1.6. 経緯

1.6.1. Kaminsky 攻撃

Kaminsky 手法は「キャッシュされていない名前を問い合わせる」ことにより、「毒を送りつける機会を増やす」ものである。

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

1.6.2. Mueller の委譲返答攻撃

Mueller は偽委譲返答(NSなど)を送りこむ攻撃が考えられると言っています。 DNS/毒盛/Mueller手法

Mueller paper の指摘では

 キャッシュにないレコードを毒として注入します。ここでもTTLは関係しません。(ランキングも)

ここまでが2008年に明らかになったことです。(それに世界が気づいていなかったとしたら不思議です。)

問い合わせポートのランダム化である程度の防御ができるからでしょう。

DNS/NSレコード/返答中のNS

1.6.3. Ghost Domain Names

そして、2012年にはDNS/GhostDomainNames脆弱性が指摘されています。(これもキャッシュへの毒盛です)

unbound などのキャッシュサーバ(実装)での対策も追加されていますが、十分利用されているとは言えません。 -- ToshinoriMaeno 2014-03-22 23:56:19

1.7. いまも残る脅威

A レコード(web サーバやDNSゾーンサーバ) はキャッシュされていることが多いので、対象としません。

リゾルバー側で簡単に実装できる対策が存在するにもかかわらず、なぜか実装されないために、 残っている脆弱性があります。

1.7.1. NSレコード

Mueller 手法にある NSレコードを狙うのが有効そうです。

RFC2181 では参照返答に含まれるNSレコードでキャッシュを上書きしてよいか、あいまいです。

正規の返答がNXDOMAINであるような問い合せを送るので、
 毒盛したいNSレコードがキャッシュさせられることがない。
これにより効果的な攻撃になります。

--> Kaminsky 流の「存在しない下位の名前」を問い合せて、一段上位のNSを返答します。

1.7.2. NSレコードをもたないノード

現実のDNSゾーン構成を観察すると、簡単に毒盛できそうなケースが多数見つかります。

NSレコードを持たないノードです。たとえば、co.jp などの属性型JPドメイン名のおおもとです。

1.7.3. キャッシュの上書き

/移転通知インジェクション

Internet Week 2014 ランチセミナー 未熟なDNSと今後どう付き合うべきか

移転通知インジェクション攻撃
– 移転通知(子のNS)は委任応答(親のNS)よりも信頼度(trustworthiness)が上
• RFC 2181 5.4.1. Ranking data
– 上記仕様に準拠しない実装では攻撃は成立し}ない

1.8. いますぐ確認して欲しいこと

ゾーンサーバとキャッシュサーバは分けていますか。

キャッシュサーバのポートランダム化はお済みでしょうか。

http://snoopy.e-ontap.com/   http://snoopy.e-ontap.com/announce.html

1.9. 毒盛に使う毒

Answer Section ではなさそうですね。

Mueller にあるように Authoriyt Section 内の NS レコードが一番狙われ易い。

なかでも、DNS/委譲毒盛 はターゲットを発見できれば、すぐにも毒盛できてしまう危険な手口です。

1.10. キャッシュにあっても危ないかも

キャッシュが優先されて、置き換えが起きないのなら、 余計なお節介のNSレコードも毒盛防御には役にたっているのかもしれない。

でも、置き換えられるのではないか。 DNS/RFC2181/s5 /root-servers.net

「毒入れの原理」という言葉を使うひとはどういう意味で使っているのだろう。

毒が入れられるような「DNS(実装)の欠陥」、あるいは「DNS設計の欠陥」という方がふさわしい呼び方だと考える。 -- ToshinoriMaeno 2015-11-10 06:23:59

1.11. 参考情報

Comprehensive DNS Resolver Defenses Against Cache Poisoning

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 森下)