MoinQ:

Contents

  1. DNS/毒盛/2014
    1. 結論と警告
    2. 再考
    3. 観察
    4. 毒盛/Kaminsky
    5. Mueller 手法
    6. 現実の構成
    7. ポートランダム化対策
    8. ポートランダム化以外の対策
    9. 被害を受けるのはだれか
    10. どうやって公表するか
    11. まとめ
  2. DNS/毒盛2014/まとめ
    1. 毒盛しやすいみっつのケース
    2. キャッシュ側での対策

Vulnerability Note /VU#800113 https://www.kb.cert.org/vuls/id/800113

1. DNS/毒盛/2014

概要: /経緯 Mueller手法によるNS毒盛が容易なケース(ENT)を見つけたので、 JPRSに連絡したら、ENT以外に他にもいくつか見つかった。

JPRSはこっそりと修正している。整合性のない説明を繰り返した。

2月に連絡したのに、連休直前まで警告をせず、その警告もポートランダム化を促すだけのものだった。

tssさんによる説明 http://www.e-ontap.com/dns/endofdns.html

tssさんが学会で公表することになった。http://www.e-ontap.com/dns/pandora_ieice.pdf 

co.jp のように資源レコードをもたないドメイン名にはNS毒を入れやすいという指摘をした。

手法はMuellerが2008年に書いているとおりだが、身近のco.jpという影響の大きい名前が見逃されていた。

JPサーバーが属しているdns.jpにも波及して、dns.jpドメインのNS変更(分離)を引き起こした。

JPRSは安定運用のためとだけしか説明していない。JPRSの姿勢が問われている。 -- ToshinoriMaeno 2017-11-04 06:30:03

実際に行われた警告はport randomizationの奨励だけだった。

/ENT

通称「DNSキャッシュポイズニング」 のことをここでは （DNS）毒盛と呼んでいます。

コメントは twitter @beyondDNS 宛にお願いします。

/経緯

DNS/脆弱性/歴史

筆者はDNSなんて信用して使うものではないという立場です。それでも、キャッシュ毒盛は気になります。

2008 年に公表されている /Mueller手法 を理解することが重要です。 それだけで十分とも言えます。

そして、DNS/キャッシュサーバの動作が実装依存であることを知ることです。　-- ToshinoriMaeno 2014-07-07 23:37:14

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

1.1. 結論と警告

NS レコードには毒盛されやすい。毒盛されたときの影響が大きい。 

 1.  NS レコードを持たないドメイン名は毒盛され易い。　
 2.  NS レコードがキャッシュに保持され難いドメインは毒盛され易い。
   親子ゾーンが同居している場合の子ドメイン側のNS
 3.  NS レコードは上書き(毒盛）されやすい。 (NS移転返答を装う毒) RFC2181, 実装不良である。

以上のみっつのケースが別々に指摘されている。　1,2 は Mueller 手法を適用するだけです。 DNS/毒盛/成立の要件

/容易なケース で詳しく説明してみます。　-- ToshinoriMaeno 2014-05-27 22:15:39

/対策 にあるような対策をしてあれば、あまり心配する必要はないでしょう。

../毒盛 は散らかりすぎなので、整理してみる。

1.2. 再考

DNS/キャッシュ毒盛/2014 

NSキャッシュの上書き問題については、遅くとも２０１２年の Ghost Domain Names 脆弱性で
気づいていなければならなかった。

RFC２１８１ 上書きについては検討不十分なため、今後の課題ということにします。 DNS/毒盛再考/root-servers.net

http://www.e-ontap.com/dns/pandora_ieice.pdf

移転の便宜のためのはずが、毒盛に使えるという心配が： DNS/コンテンツサーバ/移転/JPRS手順

DNS/ゾーンサーバの移転手順再考

TTL は毒盛防止のためにあるわけではないし、毒盛防止には役立たない。

JPNIC解説： https://www.nic.ad.jp/ja/newsletter/No40/0800.html

/e-ontap : tss さんのサイト

1.3. 観察

こんな観察が公表されている。 毒盛攻撃は始まっていると思うべきでは。　（2008 年から続いているのかも） 

Auth servers often fail, if they stay up they usually give back NXDOMAIN
Recently we also see NODATA, NOERROR returned

「実際に見たことがない」というひとがいたので、紹介しておく。

https://www.cert.org/blogs/certcc/post.cfm?EntryID=206

1.4. 毒盛/Kaminsky

DNS/毒盛/Kaminsky手法 -- /Kaminsky手法 : 2008 年の BlackHat 講演で公表されたもので、原理は簡単です。

1.5. Mueller 手法

/Mueller手法 Kaminsky とほぼ同時期に公表されたもので、これも原理は簡単です。

ほぼすべての www に毒盛可能だということが指摘されていましたが、重視されなかった。（なぜだろう。）

tss さんはキャッシュの上書き（RFC2181 ranking)を利用した毒盛も試しています。　http://www.e-ontap.com/dns/endofdns2.html （実装依存なので、自分では手を出さないことにしています。）

参考： The Hitchhiker’s Guide to DNS Cache Poisoning 　DNS/毒盛/Guide/議論

1.6. 現実の構成

NSレコードが存在していない（つまりキャッシュされていない）ドメイン名（例： co.jp ) が身近にあることに気づいた。 (2014-02)

-- ToshinoriMaeno 2014-05-15 21:35:55

JPRSはキャッシュサーバの運用者にポートランダム化対策などを呼びかけただけだった。 (2014-04-15)

JPCERTにも連絡してあるはずなのに、これだけの注意喚起しかない：

1.7. ポートランダム化対策

ポートランダム化対策すらしていないキャッシュサーバが IP アドレスにして 10% も残っている。

インターネットはこういう管理者がいることを前提に使っていくしかないものだと思っている。

1.8. ポートランダム化以外の対策

UDPを使っていると時間をかければ、毒盛はいつかは成功する。(DNSSECを使えばいいのかもしれないが）

あまり普及していないようだが、いろいろ対抗手段はある。別途/対策で取り上げる。　

Kaminsky 攻撃が公表されてから6年が過ぎようとしているのに、

http://tools.ietf.org/html/draft-barwood-dnsext-fr-resolver-mitigations-08

1.9. 被害を受けるのはだれか

/gouv.fr も co.jp と同様の問題があるのだが、nic.fr のひとは指摘を理解できないようだ。

2008 年にKaminskyが攻撃手法を公開したときに、もっとしっかり洗い出ししていればと思う。

いまは早く広く知らせることが重要だと考える。-- ToshinoriMaeno 2014-05-17 00:25:09

1.10. どうやって公表するか

脆弱な構成を知る前から、毒盛の危険性があることは警告しつづけていた。

(JPRSはなにをやっていたか） 

co.jp のことを見つけて（2/15 に通告)からは、Mueller 手法の紹介、解説を続けた。

DNSをある程度理解していれば、「co.jp が毒盛に弱い」という指摘だけで攻撃を開始するだろう。 

それでも、JPRSがどのような注意喚起をするかを見定めるまでは公表は控えた。

だが、co.jp などが危ないということを知っていながら、 

いつまでも警告しないのもまずい。　　　

4/15 づけのJPRSの注意喚起では不十分ということで、tssさんがblog に書いたのと合わせて、 自分のwikiでも、co.jp が危ないということが見えるようにした。（2014-04-15)

-- ToshinoriMaeno 2014-05-27 22:19:51

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

1.11. まとめ

「キャッシュ毒盛」、「ゾーンサーバの移転トラブル（浸透まち）」、「Ghost Domain Names 脆弱性」 などはすべて同じ 問題から生まれています

それはDNSで、ドメインを分割管理するための委譲（委任）方法がきちんと定義されてないからだと考えます。

-- ToshinoriMaeno 2014-06-08 08:35:28

2. DNS/毒盛2014/まとめ

結論：

2.1. 毒盛しやすいみっつのケース

  1. NS レコードを持たないドメイン名は毒盛され易い。　（ドメインの構造・構成による）　
  2. NS レコードがキャッシュされることが少ないと、毒盛され易い。
    • 親子ゾーン同居などでは、子孫側のNSがキャッシュされることがまれである。
  3. NS レコード自体が上書き(毒盛）されやすい。（RFC2181）
    • NS移転通知を装う毒が可能な実装が多い。

2.2. キャッシュ側での対策

  1. 問合せポートをランダム化
  2. アクセス制限 (やった方がよいが、内部からの攻撃もありえる）
  3. 共用キャッシュの提供中止 （内部からの攻撃もありえる）
  4. UDPを使わない。（TCPにより問合わせる）
  5. 毒盛攻撃の検知と即時対応

  6. ../NS 毒盛対策を強化したキャッシュの利用： 1. 問合せしなおし、2. 余計なお世話を排除

  7. その他（DNSSEC?)　DNSCurve もある。

中間者攻撃対策にはDNSSECは手間がかかるので、DNSCurveを検討するのがよいだろう。 -- ToshinoriMaeno 2015-04-09 00:22:30

MoinQ: DNS/毒盛/2014 (last edited 2021-11-25 00:53:38 by ToshinoriMaeno)