2008-08-11 「今日は涼しい感じだよねー。気温は。。。37度だってさー」「！？」
今更だけどDNSキャッシュポイズニングについて簡単に説明するよ！ - そして、DNSポイズニングがなかなか対応されない理由。
ネット | | 
先日IIJの一日インターンに行ってきました。
NDAがあるので、事細かに書くことは出来ないのですが、教育的なプログラムが組まれていて非常に面白かったです。
そこで、色々お話しして、その中でDNSポイズニングがなかなか対応されない理由、当たり前の理由が聞けたので、「DNSポイズニングって何がヤヴァイのか良くわかんね」って人に向けた簡単な解説とあわせて書きたいと思います。
まず、DNSキャッシュポイズニングの何が怖いか?
簡単に言うと、
「googleに繋いだはずが全く別サイトに繋がっちゃう！」
って話です。
本当に繋ぎたいサイトと違うサイトに繋いじゃう事が出来るので、例えば
実在するショッピングサイトそっくりの偽サイト作って、ショッピングさせて。クレジットカードの番号ゲットしちゃったり、住所ゲットしちゃったり。
夢が広がる怖い事が出来ちゃいます。
きちんとしたセキュリティ対策していれば大丈夫なのですが……結構な数のサイトさんが、酷いセキュリティのまま運用されてたりしますので、不可能じゃないのです！詳しく知りたい人は「オレオレ証明書」とかで検索してみよう！
DNSの簡単な説明。
- ドメイン名(たとえば2ch.netとかgoogle.comとか)をip(コンピュータの住所みたいなもん)に変換してくれるDNSさんがおいでやす。
- このDNSさん、自分が「直接」知らないドメイン名だったら、他のDNSさんに聞きに行く。
- ほかのDNSさんも、知らなかったら聞きに行く。
- 最初に一番お偉いさんに聞いて、そして階層的に一つ下のレベルの人に聞きに行く。それでも分からなかったら、その一つ下のレベルの人に……それの繰り返し。
- そして、一度聞いた分については覚えて(キャッシュして)おく。
こんな感じかな！
ルータの設定に「DNSのアドレス」とかいう欄があると思うよ！
んで、どうやって汚染するの?
他のサーバに聞きに行くときに、ポートと呼ばれる窓口を通して聞きに行きます。
んで、このポートってのは65535個あるんだけど、ランダムに聞きに行くのが理想。
それと、一回聞きに行くごとに違うID(0-65535)を付けて送っています。
でも、これらの番号がもし予想しやすかったら?固定されていたら?
そこに目がけて嘘のデータを投げ込んでしまえば、嘘の住所をDNSが覚えちゃう。つまり、googleに繋ぎたい人を全く別のサイトに接続させたりすることが出来ちゃう！
ポート番号とクエリidがそれぞれ一致しないと、この汚染攻撃は成功しないんだけど、どっちかが予測可能であったら65535通り試す程度で済んじゃうよね。
今回の問題としては、そのポート番号のランダム性が足りなかったり、決め打ち(53番)だったりする事です。
ヤバイ、ヤバイね！
そして、問題点は?
DNSってのは、「2ch.netは。。。206.223.154.230か。DNSさんが言っているんだから間違っていないはず！」って信用されていています。
だから、暗号化通信のSSLも、このDNSを基本にして動いています
全ての基本になっているのです。
なので
接続先のサイトが信用出来なくなってしまうのです。
自分が繋いでいるサイトは本当にgoogleなの?いつものショッピングサイトなの?クレジットカードの番号入れてもいいの?
そして、それを確実に確認する方法は、ありません。信用出来るDNSでなければ、です。
但し、きちんとSSLによって暗号化されており(アドレスがhttp://〜でなく、https://で始まっているページ)、尚且つエラーが出なかった場合は大丈夫です。
で、今は安心できるの?
YAHOO BBは対応されているそうです。
確認したい人は、こちらで確認できます。POORって出たら、残念なDNSを使っているプロバイダって事です。
そんで、何で対応しないプロバイダがあんのさ。
「そんなヤバイのに、何でなかなか対応しない所があるのさ。」って思う人が殆どだと思います。
そして、今回それを尋ねてみました。何で対応しないプロバイダが多いのか、と。
頂いた返答としては
- 面倒。
- パフォーマンス(性能)が落ちる。
って事だそうで。
DNSのプログラムを新しいのに入れ替えるのもプロバイダとかのレベルになると大掛かり。んで、53番とか決め打ちしちゃってる方が勿論簡単で、機器の負荷が少ない。
後は、地方プロバイダとかの小さい所になると、技術者一人が担当する範囲が広くて、それぞれの部分について知識がそんなに無い=よく分からないから、デフォルトの設定(53番決め打ち)で使っている、とかいう理由もあったりするみたいで。
「良くわかんないけど、ウィルス対策ソフトってパソコンが重たくなるから切っちゃった。ウィルス感染なんて、滅多にしないよね！」的な事ですかね。
あとがき
って、これ書いている実家のプロバイダ「おりべネットワーク」のケーブルテレビインターネットのDNSはﾜﾛｽ状態。
ポート番号が連続していて一直線。「ランダム性?何それ?おいしいの?」
後で問い合わせてみようかなぁ。
thanks id:kidmin!
追記 8/13 0:30
"SSL証明書がオレオレでなく、警告が出ていないのならば本物のサーバ(アドレスバーに表示されたURLのドメインの本物サーバ)である。"
という事です。
ソースは高木先生。
http://takagi-hiromitsu.jp/diary/20070407.html
お詫びして訂正致します。
ってな訳で、やっぱりオレオレ証明書使ってるショッピングサイトさんとかはどうにかして欲しいですね。
後、そもそもSSLも使ってないサイトとか。あるんですよ、本当にそういうサイト。某ソフトハウス、ソフパル(のいじ的な意味で)や、プルトップ(遙かに仰ぎたくなるような意味で)の通販ページとか
追記 9/18
独立行政法人情報処理推進機構より、この問題についてのページが作成されました。
非常に良い資料ですので、一度目を通しておく事をお薦めします。
- 816 http://www.google.co.jp/url?sa=t&rct=j&q=dnsキャッシュポイズニング&source=web&cd=2&ved=0CCkQFjAB&url=http://d.hatena.ne.jp/m-bird/20080811/1218450245&ei=iEiETqvvNtCgm
- 690 http://www.google.co.jp/search?q=DNSキャッシュ・ポイズニング&lr=lang_ja&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ja:official&client=firefox-a
- 615 http://b.hatena.ne.jp/hotentry
- 422 http://www.google.co.jp/search?hl=ja&q=DNSキャッシュポイズニング+プロバイダー&btnG=検索&lr=
- 417 http://www.google.co.jp/search?q=キャッシュポイズニング 確認方法&btnG=検索&hl=ja&lr=lang_ja&client=firefox-a&rls=org.mozilla:j
- 407 http://www.google.co.jp/search?hl=ja&source=hp&q=dnsキャッシュポイズニング&lr=&aq=9&oq=ＤＮＳ
- 401 http://search.yahoo.co.jp/search?p=DNSキャッシュポイズニング FireWall 設定&ei=UTF-8&fr=top_ga1_sa&x=wrt
- 389 http://www.google.co.jp/url?sa=t&rct=j&q=キャッシュポイズニング&source=web&cd=1&sqi=2&ved=0CCMQFjAA&url=http://d.hatena.ne.jp/m-bird/20080811/1218450245&ei=YjqETtTPAa
- 305 http://reader.livedoor.com/reader/
- 276 http://search.yahoo.co.jp/search?p=キャッシュポイズニング unix&ei=UTF-8&fr=top_ga1_sa&x=wrt
DNS Cache Poisoningでインターネッツ終了のお知らせですね。わかります。
「よく分かるDNS Cache Poisoning」のpdfがあったので http://www.nttv6.net/files/DKA-20080723.pdf
えらいこっちゃで鯖缶の中の人は大変そうですね。
せっかくなので、Randomizeパッチだけじゃなくて、将来的なSecure DNSの導入とか、根本的な対策と今後の展望についてもお願いします＞＜；
大変遺憾だけど、当面は OpenDNS を利用することに。
ceekz氏が言うとおり、OpenDNSの利用とかかなぁ。
んで、鯖管的な対策としては、トラバ元の
http://d.hatena.ne.jp/famnet/20080812/1218502884
とか。
>ceekz
Interlink,早く対応して欲しいですよね。
すでに2回通報してるんだけどねぇ。
IPA 経由の方が良いのかな。
ギガビットイーサのローカルLANなどでは、まだ無防備だということも書いていく必要がありそう。
http://tech.slashdot.org/article.pl?sid=08/08/09/123222
http://tservice.net.ru/~s0mbre/blog/devel/networking/dns/2008_08_08.html
でも、総当たりで攻撃したらいつかヒットするんじゃ？。
> でも、総当たりで攻撃したらいつかヒットするんじゃ？
その通りだと思います。本来ならばDNSSECの導入が根本的な解決になるけど、普及してないので、ヒット率をおさえる対策をしたのが今回の修正。基本的には根本的な解決というよりも、ワークアラウンドだと思っています。
これみるといいですよ。
http://www.isc.org/index.pl?/sw/bind/forgery-resilience.php
DNSSEC is the only definitive solution for this issue. Understanding that immediate DNSSEC deployment is not a realistic expectation, ISC is releasing patched versions of BIND that improve its resilience against this attack.
補足どもです。
今回のエントリについては、さわりとして書いたものなので、そこまで細かく書くつもりが無かったので、触れていませんでした。というか、ここまで読まれるんだったら、もちょっと推敲すべきだったと後悔していたりorz
>happy_siroさん
確かにそうですね。
ただ、ポート固定だったりすると、エントロピーが低すぎてアレげ過ぎるので、きちんとランダムにしましょうねー、って事ですね。
> そこに目がけて嘘のデータを投げ込んでしまえば
TCPでどうしてそんなことできんの？と思ってたのですがUDPだから絨毯爆撃が可能なんですね。
次URL参照で理解しました http://www.janog.gr.jp/meeting/janog19/files/DNS_Minda.pdf
違います。
あうち、どもですー
フルリゾルバからDNSコンテンツサーバに問い合わせに行くポート（兼結果を待ち受けるポート）は53番ではないのでキャッシュポイズニングとは関係ないですってことかな？