MoinQ:

1. DNS/脆弱性/歴史

Contents

  1. DNS/脆弱性/歴史
  2. 2020
  3. あらまし
  4. djbdns 以前
  5. 1999 年 djbdns 公開
  6. 2002 ?
  7. 2005 年 e-ontap.com
  8. 2008 年 Kaminsky, Mueller
  9. 2009年
  10. 2011 年 （東北大地震）
  11. 2012 年 Ghost Domain Names 脆弱性
  12. 2012 共用ゾーンサービスの危険性
  13. 2014 年 毒盛再考Mueller手法
  14. 2015年 NSキャッシュを上書きする危険性
  15. キャッシュでの対策
    1. ランダムポートだけでは足りない
    2. DNS/TCP のすすめ
    3. DNSSEC はどうなったのか

2. 2020

DNS/毒盛/2020/saddns.net

3. あらまし

http://www.networkworld.com/article/2838356/network-security/dns-is-ubiquitous-and-its-easily-abused-to-halt-service-or-steal-data.html

2008年にKaminskyに指摘されても、まともな対応をしてこなかったことをはっきりさせようと、 経過を整理してみている。

落ちていることは、適宜追加してください。 (Kaminsky Blackhat 2009 も参考になる。事実とは限らないが）

DNSSECを推進に熱心だったのに、なかなかうまく行かないために、 DNSSECを使えという宣伝はでてこない。 事情はよく分かっていません。 http://dnssec.jp 

DNSSECジャパン設置期間終了のお知らせ
By dnssecjp, on 7月 17th, 2012

4. djbdns 以前

DNS返答を偽造するまでもなく、ゾーンサーバが偽情報を送りこめた時代もあった。 (Kashpureff, alternic) 

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.

「TTLによる保護」というまやかし

5. 1999 年 djbdns 公開

DJB: DNS/実装/djbdns(発表時はdnscache) 　

DNS/実装/djbdns/DNSキャッシュをDNSサーバから分離することの重要性

6. 2002 ?

DNS Cache Poisoning – The Next Generation By Joe Stewart, GCIH <jstewart@lurhq.com>

https://www.ida.liu.se/~TDDC03/literature/dnscache.pdf

7. 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サーバの登録と設定の確認

JPRSがDNSサーバの危険な設定を削除開始 http://jprs.co.jp/topics/2006/060112.html

8. 2008 年 Kaminsky, Mueller

Kaminsky, Mueller の指摘　「TTLによる制約を受けない攻撃が可能であること」

民田らのスライド(Answer Section + Authority + Additional による毒)

http://www.atmarkit.co.jp/ait/articles/0809/24/news141.html

https://www.dns-oarc.net/oarc/services/dnsentropy

9. 2009年

Kaminsky のさらなる指摘。 DNSSEC に目をむけたのは失敗だったようだ。 (Blackhat 2009)

ポート固定問合せを送ってくるキャッシュ利用者への警告サイトを作成（これをやっておいてよかった）。

JPRSなどはoarcを紹介するだけで、たいした活動をしてこなかったと思う。 

  2010 年 退職

10. 2011 年 （東北大地震）

http://www.e-ontap.com/blog/20110208.html 浸透いうな

鈴木による BIND 不良説確認 http://www.e-ontap.com/dns/bindmatrix.html

http://www.e-ontap.com/blog/20111018.html カミンスキー毒入れ攻撃の真実

別件： ゾーンサーバ移転時の「浸透しない」問題がRFC２１８１からみの動作だとはっきりしたのに、

（東北大地震と福島原発でDNSどころではなかった。）

11. 2012 年 Ghost Domain Names 脆弱性

DNS/GhostDomainNames

ここでも 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の委任のしくみや関係する諸問題に関する深い理解が得られます

理解していないことが、明らかになったひとが言ってもねえ。

12. 2012 共用ゾーンサービスの危険性

共用ゾーンサービスの危険性 (さくらなど） 未解決

このときに共用ゾーンサービスの危険性に気づいたのも不幸なめぐりあわせだったかも。w

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による説明

キャッシュサーバの動作は「きちんと」決められておらず、（偽返答を棚上げしても）怪しげな動作だとあります。

https://www.nic.ad.jp/ja/newsletter/No51/0800.html

13. 2014 年 毒盛再考Mueller手法

co.jp など（本来NSレコードを持たないドメイン名）には簡単にNS毒が入ることに気づく。

Mueller 手法でほぼDNSは全滅状態だと分かっていたから、ほかのことは考えなかっただけ。

JPRSはこのことから目をそらすために、dns.jp の問題を持ち出したように見える。

DNS キャッシュがAmp 攻撃に利用されている。

dns.jp ゾーンへの毒盛が容易：

NSキャッシュを上書きする実装の危険性はtssさんがBINDなどを対象にして、実験で確かめた。(NS移転通知型）

JPRSが公開の場で、脆弱性を認めた。　https://yukar.in/note/ckFPy5

信学技報, vol. 114, no. 216, IA2014-20, pp. 35-40, 2014年9月.

14. 2015年 NSキャッシュを上書きする危険性

2014年のJPRSの注意喚起以降のJPRSの講演でも、キャッシュを上書きする毒入れ手法はきちんと説明されていない。

15. キャッシュでの対策

15.1. ランダムポートだけでは足りない

query source port randomization をしたとしても、攻撃の検知は欠かせない。　

攻撃があったときにどう対応するかも難しい。キャッシュに対する要請しだいだから。

saddns (2020)

15.2. DNS/TCP のすすめ

TCPを使えばいい。 UDPでは偽パケットを見分けるのが困難だから。

TCPを使う負荷に耐えられないゾーンサーバはあるとしても、root, TLD くらいだ。

UDPを使いつづけたいのであれば、エントロピーを増やす改造をすべきなのに、やってきていない。

15.3. DNSSEC はどうなったのか

JPRSはDNSSEC推進をやめたのだろうか。 http://jprs.jp/dnssec/ 

期間限定の組織ということで発足し、2年半程の活動を経て解散となりますが、
まだまだDNS、DNSSECを取り巻く環境には課題が山積しています。 
DNSSECジャパンでの活動は終了しますが、今後とも業界内で連携して課題解決に取り組んで行くことができると信じています。

これが最後のメッセージらしい。 -- ToshinoriMaeno 2014-09-08 21:04:32

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

MoinQ: DNS/脆弱性/歴史 (last edited 2020-12-05 00:27:44 by ToshinoriMaeno)