DNS キャッシュポイズニング続報 27
ストーリー by hayakawa
まだ対策をなさっていない方はお早めに 部門より
まだ対策をなさっていない方はお早めに 部門より
/.Jでも取り上げられたDNSキャッシュ汚染に関する脆弱性についてですが、JPCERT/CCのプレスリリースによると、当初は2008年8月に発表される予定であった詳細情報が、2008年7月22日に誤って公開されてしまったようです。また他のプレスリリースによると、その2日後に本脆弱性を狙った攻撃ツールが公開されているようです。
すでに攻撃ツールが公開されておりますので、早めにこの問題が修正されたバージョンにアップデートされることをおすすめいたします。なお、「セキュリティホールMEMO」にも詳細情報がまとめられているようです。
誤って、なのかな？ (スコア:3, 興味深い)
http://japan.cnet.com/news/sec/story/0,2000056024,20377804,00.htm?ref=rss [cnet.com]
Re: (スコア:0)
exploit は ruby (スコア:1)
＃いや、まぁ、それだけです。
ふと思ったのだが。 (スコア:0, 参考になる)
ブロードバンドルータがDNSサーバになってる事って結構多いわけだし。
＃内容が多少アレなのでACで。
Re:ふと思ったのだが。 (スコア:4, 参考になる)
それとも、最近のルータにはキャッシュ機能があるんでしょうか
YAMAHAのRTシリーズはDNSサーバになるようですが。
http://www.rtpro.yamaha.co.jp/RT/FAQ/Security/VU800113.html [yamaha.co.jp]
ポートのランダムだけでは単なる軽減ですよ (スコア:0)
Re:ポートのランダムだけでは単なる軽減ですよ (スコア:3, 参考になる)
どのくらい軽減かが問題ではないでしょうか。
いままで 16bit の ID で識別していたのを、さらに port をランダムにすることにより 16bit の識別できる情報が付加されたことになります。16bit であれば 65535通りで、これがまぐれ当たりする確率は誕生日のパラドックス [wikipedia.org]のために以外に高いということですが、さらに 16bit あれば実用上はなんとかなると思います。
たとえば、（サーバ攻略成功の確率50%を超えるのに）いままで 1時間かかるところが 16bit 増えることにより 60,000時間＝6.8年になれば、単なる軽減ではなく当面は十分な軽減だと思いますが。
これでいいのか TTL [janog.gr.jp] (PDF) が信用できるとすると、port が 53 固定の場合で伏字の著名サイトで攻略可能性50%までの時間を 16時間～数年と計算しています。単純に 16bit 倍してはいけないと思いますが、桁数で考えても数年かかるのではと思います。計算式があるので計算してみてはどうでしょう。
Re:ポートのランダムだけでは単なる軽減ですよ (スコア:1)
実装の弱さ（疑似乱数の弱さ）を突いた攻撃をしてくれば何bit追加されても意味なし．
Re: (スコア:0)
ですので従来手法の何千・何万倍も効率良く攻撃できるので，
「今まで１時間かかるところが」の部分が「いままで数十秒かかるところが」に変わってしまったのが
現状なのだと思います。
なので，サーバへのパッチ当てが行われない場合，ポートの分散だけでは
軽減として十分とは言えないかもしれません。
Re:ポートのランダムだけでは単なる軽減ですよ (スコア:5, 参考になる)
[基本]
・汚染に成功させるためには ID と ポートを的中させる必要がある
・また本物のサーバからの応答との競争に勝つ必要がある
・本物のサーバとの競争に勝つ可能性が 1/2 と仮定すると、防御方法が
ポート固定で ID だけがランダムの場合には16ビットなので
65536 * 2 / 2 となり平均65536回の試行で汚染に成功する
[従来]
・今までのバースデイアタックでは一度失敗すると TTL が切れるまで
再攻撃が成功しなかった。
・よって従来方式で TTL 300秒ならば 300 * 65535秒 = 平均 227日の
かかる計算になる。
[今回]
・今回の方法では TTL に関係がなくサーバマシンの性能限りの速度で
攻撃が可能。最近の高速環境だと 10000 query/sec くらいは軽い。
・よって防御方法が ID だけだと 65536 / 10000 で平均6.5秒もあれば
汚染に成功する
[対策]
・サーバに今回の対策パッチを当てるとポートがランダムになる。
・ポートは16ビットあるが、さすがに全部は使えないので半分の
32768種類を使うとすると、攻撃に必要な時間は
6.5 * 32768 ≒ 213000秒 ≒ 平均2.5日になる。
[結論]
・パッチを当ててない状態だと、もはや致命的。
・パッチを当てたからといって安全確実ではないが、当てないよりマシ。
・firewall とかでDNSパケットの流量制限してれば、もう少し安全かもしれない
・根本的な対策は DNSSEC ということになるけど、普及には時間がかかりそう
Re:ポートのランダムだけでは単なる軽減ですよ (スコア:4, 参考になる)
どうもそのようです。私のコメントは誤解を生むものでした。申し訳ありません。
DNS脆弱性、発見者の意図に反して詳細が明らかになった事情 [zdnet.com]をみると、外部に再帰検索を許可した Open なキャッシュサーバであることを利用しているように見えます。だとすると、対策は（これまでもたびたび言われてきた基本ですが）キャッシュサーバをネームサーバから分離して、外部からアクセスできないところに置いてしまうことではないでしょうか。この場合、外部からの直接攻撃については防げそうです。（分離しても前のコメントの方法は成立すると思うので port のランダム化はいずれにせよ必須ですが）
DNS Cache Poisoningの概要と対処 [nttv6.net] (PDF) というのが公開されていました。キャッシュサーバ側の対応の他、ドメイン管理者側でネームサーバ台数を増やすという方法が載っています。だとすると BIND のような多数の IP アドレスに bind できるサーバを使用していてグローバル IP アドレスに余裕があれば、自分のサイトが偽装される率を落とすことができそうです。
キャッシュサーバのチェックツール：自分が使用できるキャッシュサーバのポートがランダムかどうかは、porttest.dns-oarc.net の TXT レコードを検索すると結果をテキストで返してくれるようです。
だめじゃん… （26回問い合わせに 26個のポートを使っているが標準偏差（だと思う）が 7.65 と小さい） 完全にダメな場合は from 1 port と表示されます。
OK の場合はこうなるようです。
nslookup でも「nslookup -q=txt porttest.dns-oarc.net チェック対象サーバ」でチェックできると思います。もしタイムアウトになったら 10秒置いてもう一度実行するとキャッシュから結果が引けると思います。
Re:ポートのランダムだけでは単なる軽減ですよ (スコア:2, 参考になる)
https://www.dns-oarc.net/oarc/services/dnsentropy [dns-oarc.net]
だと図示されて説得力があります（中央の Test My DNS をクリック）
ちなみにインターネットに出て行くところで NAPT 機構が噛んでいて、フルリゾルバがその内側にいる場合、
bind / djbdns / unbound / PowerDNS recursor などでソースポートランダム化がおこなわれても
実際にインターネットに出て行くソースポートは全部インクリメンタルに整列されてしまって
対策意図が台無しということがありますので要注意
（上記 URL だと一目瞭然）
Re:ポートのランダムだけでは単なる軽減ですよ (スコア:1)
リンクされている ZDNet の記事を読みましたが、「外部に再帰検索を許可した Open なキャッシュサーバであることを利用している」という印象をなぜ持たれたのかよくわかりませんでした。いずれにしても、外部から直接攻撃する代わりに、攻撃対象のネットワークの中の善意のユーザーに攻撃を肩代わりさせる方法も以前からあるようです。なので、今回新たに見つかった攻撃方法は、内部向けのキャッシュ DNS サーバーを外部向けの DNS サーバーから分離するだけでは防げないと思います。
なお、「今回新たに見つかった攻撃方法」と書きましたが、正確には、 full-disclosure メーリングリストのメール「The cat is indeed out of the bag [seclists.org]」 (の最後の 4 個の段落) に書いてある攻撃方法のことを指しています。これが Dan Kaminsky さんが 8 月に発表予定の脆弱性というのと同じかどうかは知りません。
「前のコメントの方法」がどれを指しているかわからないので、もしかしたら同じことを意図されているのかもしれませんが。
Re:ポートのランダムだけでは単なる軽減ですよ (スコア:3, 参考になる)
dnscacheのように元からソースポートを分散させている場合は、パッチ当ては必要無い(パッチ自体が無い)です。
ですから、ソースポートを固定にする設定を行っている場合は、パッチを当てるだけでは効果が無いので、設定も見直す必要があります。
他にも、外部からの再帰的な問い合わせには答えないようにするのも重要です。
外部からの再帰的な問い合わせを無視すれば、それによる外部への問い合わせも行わないので、詐称も出来なくなります。
当然内部からの攻撃の対策にはなりませんが、外部からの攻撃を防げるだけでも十分に意味があると思います。
Open RecursionだとDNS amp攻撃の問題もあるので、この機会に是非とも対応を行って欲しいです。
これって (スコア:0)
Re:これって (スコア:2, 参考になる)
社内のクライアント(Windows）とDNSサーバ（Windows Server / Linux）は
すでに対応を終えましたが、よく考えると上流のキャッシュサーバが
汚染されたら意味無いんですよねぇこれって。
社内のDNSサーバは回線業者のDNSキャッシュサーバにforwardしてるので
サポートに問い合わせてみたら
* （JPCERT/CCから発表されている）DNSの脆弱性については知っている
* 順次対応はしているが対応状況はお知らせできない
という回答を得ました。
別件で某社の某Linuxアプライアンス(DNS入り）を使ってますが、
対応状況を確認したら
* 8月末のUpdateで対応予定
という回答を得ました。
後者については社内から参照しないDNSサーバではありますが
外向けのコンテンツサーバ（キャッシュサーバ機能もアリ）なので
早めに対策したいところです。
全社についてはモロ社内ユーザに影響が出るので「お答えできない」
では話にならないから別途連絡を寄こすよう申し伝えてますが
まだ連絡はありません。
今日は家で契約しているISPのサポセンに問い合わせてみます。
Re:これって (スコア:1)
これが問題。パフォーマンスは下がるしろくなことはない。
直接ルートサーバを引きに行くようにするべき。
Re:これって (スコア:1)
そうしたいのは山々なんですが、トラフィック増大の原因となるのでDNSは全て弊社（回線業者）のDNSキャッシュサーバを参照しやがってください、って説明がされてるんですよ。
DNSクエリなんてそんなトラフィック食わないと思うんですが。試しに週明けにルートサーバ見に行くようにこっそり変えてみます。
これ言うとどの回線業者か分かる人は分かると思いますが、この回線業者はICMPなTraceroute（Windowsのtracertとか）を網内でブロックしてくれちゃってて、その理由が「ウイルス感染防止のため」とかワケわからんこと言う業者なんで個人的にはダメダメだと評価はしてます。
Re: (スコア:0)
過去にICMPのリクエストを大量に送って感染先ホストを探すワームが大流行したからでしょう。
どこがおかしいですか？
Re:これって (スコア:1)
＃オフトピ失礼
ありましたねぇ、過去に。
それ用の対策としてICMPなtracerouteが通らないようにブロックするのは（回線業者がそれをやっていいもんかどうかは別として）わかるとして、今現在もまだそれ用の対策をしておく必要ってホントにあるのか、というのが私の感想です。
＃「ウイルス感染防止のため」と言ってる割には135/TCPは筒抜けだったりどういう基準なのか・・・。
ちなみに他に2社の回線で確認してみましたが、そちらは特にブロックされるということはありませんでした。
Re: (スコア:0)
安全性の為に一旦制限をかけてしまったら、不便だけを理由に解除できないということでしょうね。
「ワームは根絶されたのでICMP制限はもう必要ありません」と言ってあげたらどうでしょう。
# 本当に根絶されたかまでは確認していません。
Re: (スコア:0)
次に起きること (スコア:0)
キャッシュは危険 (スコア:0)
けっして貧乏だからではありません
Re:キャッシュは危険 (スコア:1)
#予約してたフィギュアが纏めて届いた時、次のカード請求が怖かったりするのよね、単価8kとかだと（苦笑）。
Re: (スコア:0)
あ…ありのまま 今起こった事を話すぜ！
「アマゾンドットコムを見てたら、いつのまにか貯金が減りアマゾンポイントが増加していた」
な… 何を言ってるのか わからねーと思うが
おれも何をされたのかわからなかった…
頭がどうにかなりそうだった…
欲しいものリスト公開とか予約していたのにkonozamaとか
それも怖いが、そんなチャチなもんじゃあ断じてねえ
もっと恐ろしい、「アマゾンポイントを購入している」片鱗を味わったぜ…
Re: (スコア:0)
金を借りているだけでもアウトになるということです。
透明連帯保証人制度みたいなもの。
＃だんだんよくわかんなくなったのでAC