パスワードを忘れた? アカウント作成
30965 story
セキュリティ

DNS キャッシュポイズニング続報 27

ストーリー by hayakawa
まだ対策をなさっていない方はお早めに 部門より

elderwand 曰く

/.Jでも取り上げられたDNSキャッシュ汚染に関する脆弱性についてですが、JPCERT/CCのプレスリリースによると、当初は2008年8月に発表される予定であった詳細情報が、2008年7月22日に誤って公開されてしまったようです。また他のプレスリリースによると、その2日後に本脆弱性を狙った攻撃ツールが公開されているようです。

すでに攻撃ツールが公開されておりますので、早めにこの問題が修正されたバージョンにアップデートされることをおすすめいたします。なお、「セキュリティホールMEMO」にも詳細情報がまとめられているようです。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by niratama (2175) on 2008年07月25日 13時25分 (#1390398) ホームページ 日記
    DNS脆弱性、発見者の意図に反して詳細が明らかになった事情(CNET Japan)
    http://japan.cnet.com/news/sec/story/0,2000056024,20377804,00.htm?ref=rss [cnet.com]
    • by Anonymous Coward
      ガラパゴスの中で「みんなと同じように」一般公開まで秘密を守らない奴は死刑、なんてルールを作っても無意味なことがよくわかりますね。
  • by elderwand (34630) on 2008年07月25日 10時54分 (#1390314) 日記
    元のタレコミにあった exploit code へのリンクは、編集者の判断で削除されたようですが、Ruby で書かれているようです。(探せばすぐに出てくるでしょうけど)

    #いや、まぁ、それだけです。
  • by Anonymous Coward on 2008年07月25日 10時05分 (#1390303)
    端末やサーバにパッチ当てても、ブロードバンドルータも対応しておかないと拙いんじゃ…?
    ブロードバンドルータがDNSサーバになってる事って結構多いわけだし。

    #内容が多少アレなのでACで。
  • by Anonymous Coward on 2008年07月25日 10時52分 (#1390313)
    ポートのランダムだけでは単なる軽減ですよ
    • > ポートのランダムだけでは単なる軽減ですよ

      どのくらい軽減かが問題ではないでしょうか。

      いままで 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 倍してはいけないと思いますが、桁数で考えても数年かかるのではと思います。計算式があるので計算してみてはどうでしょう。
      親コメント
      • たしかに攻撃者が総当り(もしくは真の乱数)で攻撃をしてくるならその通りなんだけど,
        実装の弱さ(疑似乱数の弱さ)を突いた攻撃をしてくれば何bit追加されても意味なし.
        親コメント
      • by Anonymous Coward
        今回明らかになったDNSサーバの問題は,TTLの設定に関係なく連続して攻撃が可能なものの様です。
        ですので従来手法の何千・何万倍も効率良く攻撃できるので,
        「今まで1時間かかるところが」の部分が「いままで数十秒かかるところが」に変わってしまったのが
        現状なのだと思います。

        なので,サーバへのパッチ当てが行われない場合,ポートの分散だけでは
        軽減として十分とは言えないかもしれません。
        • by Anonymous Coward on 2008年07月25日 18時52分 (#1390632)
          今回の問題に色々と誤解している人もいそうなので、少し計算してみる

          [基本]
              ・汚染に成功させるためには 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 ということになるけど、普及には時間がかかりそう
          親コメント
        • > 今回明らかになったDNSサーバの問題は,TTLの設定に関係なく連続して攻撃が可能なものの様です。

          どうもそのようです。私のコメントは誤解を生むものでした。申し訳ありません。

          DNS脆弱性、発見者の意図に反して詳細が明らかになった事情 [zdnet.com]をみると、外部に再帰検索を許可した Open なキャッシュサーバであることを利用しているように見えます。だとすると、対策は(これまでもたびたび言われてきた基本ですが)キャッシュサーバをネームサーバから分離して、外部からアクセスできないところに置いてしまうことではないでしょうか。この場合、外部からの直接攻撃については防げそうです。(分離しても前のコメントの方法は成立すると思うので port のランダム化はいずれにせよ必須ですが)

          DNS Cache Poisoningの概要と対処 [nttv6.net] (PDF) というのが公開されていました。キャッシュサーバ側の対応の他、ドメイン管理者側でネームサーバ台数を増やすという方法が載っています。だとすると BIND のような多数の IP アドレスに bind できるサーバを使用していてグローバル IP アドレスに余裕があれば、自分のサイトが偽装される率を落とすことができそうです。

          キャッシュサーバのチェックツール:自分が使用できるキャッシュサーバのポートがランダムかどうかは、porttest.dns-oarc.net の TXT レコードを検索すると結果をテキストで返してくれるようです。

          $ dig +short porttest.dns-oarc.net TXT @192.168.xx.xx
          z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
          "xx.xx.xx.xx is POOR: 26 queries in 3.1 seconds from 26 ports with std dev 7.65"

          だめじゃん… (26回問い合わせに 26個のポートを使っているが標準偏差(だと思う)が 7.65 と小さい) 完全にダメな場合は from 1 port と表示されます。

          $ dig +short porttest.dns-oarc.net TXT @127.0.0.1
          z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
          "xx.xx.xx.yy is GOOD: 26 queries in 3.0 seconds from 26 ports with std dev 16362.04"

          OK の場合はこうなるようです。

          nslookup でも「nslookup -q=txt porttest.dns-oarc.net チェック対象サーバ」でチェックできると思います。もしタイムアウトになったら 10秒置いてもう一度実行するとキャッシュから結果が引けると思います。

          親コメント
          • >キャッシュサーバのチェックツール
            https://www.dns-oarc.net/oarc/services/dnsentropy [dns-oarc.net]
            だと図示されて説得力があります(中央の Test My DNS をクリック)

            ちなみにインターネットに出て行くところで NAPT 機構が噛んでいて、フルリゾルバがその内側にいる場合、
            bind / djbdns / unbound / PowerDNS recursor などでソースポートランダム化がおこなわれても
            実際にインターネットに出て行くソースポートは全部インクリメンタルに整列されてしまって
            対策意図が台無しということがありますので要注意
            (上記 URL だと一目瞭然)

            親コメント
          • DNS脆弱性、発見者の意図に反して詳細が明らかになった事情 [zdnet.com]をみると、外部に再帰検索を許可した Open なキャッシュサーバであることを利用しているように見えます。だとすると、対策は(これまでもたびたび言われてきた基本ですが)キャッシュサーバをネームサーバから分離して、外部からアクセスできないところに置いてしまうことではないでしょうか。この場合、外部からの直接攻撃については防げそうです。

            リンクされている ZDNet の記事を読みましたが、「外部に再帰検索を許可した Open なキャッシュサーバであることを利用している」という印象をなぜ持たれたのかよくわかりませんでした。いずれにしても、外部から直接攻撃する代わりに、攻撃対象のネットワークの中の善意のユーザーに攻撃を肩代わりさせる方法も以前からあるようです。なので、今回新たに見つかった攻撃方法は、内部向けのキャッシュ DNS サーバーを外部向けの DNS サーバーから分離するだけでは防げないと思います。

            なお、「今回新たに見つかった攻撃方法」と書きましたが、正確には、 full-disclosure メーリングリストのメール「The cat is indeed out of the bag [seclists.org]」 (の最後の 4 個の段落) に書いてある攻撃方法のことを指しています。これが Dan Kaminsky さんが 8 月に発表予定の脆弱性というのと同じかどうかは知りません。

            (分離しても前のコメントの方法は成立すると思うので port のランダム化はいずれにせよ必須ですが)

            「前のコメントの方法」がどれを指しているかわからないので、もしかしたら同じことを意図されているのかもしれませんが。

            親コメント
        • なので,サーバへのパッチ当てが行われない場合,ポートの分散だけでは
          今回のパッチ当て(主にBIND?)というのは、問い合わせ時のソースポートを分散させる為のものです。
          dnscacheのように元からソースポートを分散させている場合は、パッチ当ては必要無い(パッチ自体が無い)です。
          ですから、ソースポートを固定にする設定を行っている場合は、パッチを当てるだけでは効果が無いので、設定も見直す必要があります。

          他にも、外部からの再帰的な問い合わせには答えないようにするのも重要です。
          外部からの再帰的な問い合わせを無視すれば、それによる外部への問い合わせも行わないので、詐称も出来なくなります。
          当然内部からの攻撃の対策にはなりませんが、外部からの攻撃を防げるだけでも十分に意味があると思います。
          Open RecursionだとDNS amp攻撃の問題もあるので、この機会に是非とも対応を行って欲しいです。
          親コメント
  • by Anonymous Coward on 2008年07月25日 14時14分 (#1390437)
    要するに、対策してないDNSサーバーを参照しているクライアントに対して、フィッシングやり放題ってことですよね? それって滅茶苦茶ヤバい話のような。ウェブ登場以後のインターネットでトップ3には確実に入りそうなぐらいヤバいんじゃ? その割に、あんまり騒がれてない気がするんですが・・。
    • Re:これって (スコア:2, 参考になる)

      by petit.torrija (31677) on 2008年07月26日 12時26分 (#1391065)
      私個人もそう思うんですが、本当にあまり騒がれてないので複雑な気分です。

      社内のクライアント(Windows)とDNSサーバ(Windows Server / Linux)は
      すでに対応を終えましたが、よく考えると上流のキャッシュサーバが
      汚染されたら意味無いんですよねぇこれって。

      社内のDNSサーバは回線業者のDNSキャッシュサーバにforwardしてるので
      サポートに問い合わせてみたら

       * (JPCERT/CCから発表されている)DNSの脆弱性については知っている
       * 順次対応はしているが対応状況はお知らせできない

      という回答を得ました。

      別件で某社の某Linuxアプライアンス(DNS入り)を使ってますが、
      対応状況を確認したら

       * 8月末のUpdateで対応予定

      という回答を得ました。

      後者については社内から参照しないDNSサーバではありますが
      外向けのコンテンツサーバ(キャッシュサーバ機能もアリ)なので
      早めに対策したいところです。
      全社についてはモロ社内ユーザに影響が出るので「お答えできない」
      では話にならないから別途連絡を寄こすよう申し伝えてますが
      まだ連絡はありません。

      今日は家で契約しているISPのサポセンに問い合わせてみます。
      親コメント
      • by wildcard (416) on 2008年07月26日 15時36分 (#1391146)
        >社内のDNSサーバは回線業者のDNSキャッシュサーバにforwardしてる

        これが問題。パフォーマンスは下がるしろくなことはない。
        直接ルートサーバを引きに行くようにするべき。
        親コメント
        • by petit.torrija (31677) on 2008年07月26日 16時18分 (#1391165)

          直接ルートサーバを引きに行くようにするべき。

          そうしたいのは山々なんですが、トラフィック増大の原因となるのでDNSは全て弊社(回線業者)のDNSキャッシュサーバを参照しやがってください、って説明がされてるんですよ。

          DNSクエリなんてそんなトラフィック食わないと思うんですが。試しに週明けにルートサーバ見に行くようにこっそり変えてみます。

          これ言うとどの回線業者か分かる人は分かると思いますが、この回線業者はICMPなTraceroute(Windowsのtracertとか)を網内でブロックしてくれちゃってて、その理由が「ウイルス感染防止のため」とかワケわからんこと言う業者なんで個人的にはダメダメだと評価はしてます。

          親コメント
          • by Anonymous Coward

            これ言うとどの回線業者か分かる人は分かると思いますが、この回線業者はICMPなTraceroute(Windowsのtracertとか)を網内でブロックしてくれちゃってて、その理由が「ウイルス感染防止のため」とかワケわからんこと言う業者なんで個人的にはダメダメだと評価はしてます。

            過去にICMPのリクエストを大量に送って感染先ホストを探すワームが大流行したからでしょう。
            どこがおかしいですか?

            • by petit.torrija (31677) on 2008年07月26日 16時56分 (#1391176)

              #オフトピ失礼

              ありましたねぇ、過去に。

              それ用の対策としてICMPなtracerouteが通らないようにブロックするのは(回線業者がそれをやっていいもんかどうかは別として)わかるとして、今現在もまだそれ用の対策をしておく必要ってホントにあるのか、というのが私の感想です。
              #「ウイルス感染防止のため」と言ってる割には135/TCPは筒抜けだったりどういう基準なのか・・・。

              ちなみに他に2社の回線で確認してみましたが、そちらは特にブロックされるということはありませんでした。

              親コメント
              • by Anonymous Coward

                安全性の為に一旦制限をかけてしまったら、不便だけを理由に解除できないということでしょうね。
                「ワームは根絶されたのでICMP制限はもう必要ありません」と言ってあげたらどうでしょう。

                # 本当に根絶されたかまでは確認していません。

            • by Anonymous Coward
              どれだけリクエストを送ろうが、正しい対策がなされていれば感染することはないので、ICMPブロックは解決手段として不適当。
      • by Anonymous Coward
        SSLのホスト不一致警告を「よくあること」だと思って無視して引っかかったフィッシングの被害報告
  • by Anonymous Coward on 2008年07月25日 14時42分 (#1390463)
    だからポイズニングされないよう、現金持たない主義なのです
    けっして貧乏だからではありません
    • by uippi (9904) on 2008年07月25日 19時47分 (#1390651) 日記
      何か(趣味とか)にポイズニング(毒)されて、キャッシュ(現金)が無くなっているってオチじゃなくて?

      #予約してたフィギュアが纏めて届いた時、次のカード請求が怖かったりするのよね、単価8kとかだと(苦笑)。
      親コメント
      • by Anonymous Coward
        >何か(趣味とか)にポイズニング(毒)されて、キャッシュ(現金)が無くなっているってオチじゃなくて?

        あ…ありのまま 今起こった事を話すぜ!

        「アマゾンドットコムを見てたら、いつのまにか貯金が減りアマゾンポイントが増加していた」

        な… 何を言ってるのか わからねーと思うが
        おれも何をされたのかわからなかった…

        頭がどうにかなりそうだった…

        欲しいものリスト公開とか予約していたのにkonozamaとか
        それも怖いが、そんなチャチなもんじゃあ断じてねえ

        もっと恐ろしい、「アマゾンポイントを購入している」片鱗を味わったぜ…
    • by Anonymous Coward
      こいつが怖いのは、あなたに現金を与えてくれる人が
      金を借りているだけでもアウトになるということです。

      透明連帯保証人制度みたいなもの。

      #だんだんよくわかんなくなったのでAC
typodupeerror

普通のやつらの下を行け -- バッドノウハウ専門家

読み込み中...