パスワードを忘れた? アカウント作成
12707362 story
暗号

クロスプロトコル攻撃が可能となるSSLv2の脆弱性「DROWN」 21

ストーリー by hylom
古い規格は積極的にオフにしましょう 部門より
headless 曰く、

クロスプロトコル攻撃が可能となるSSLv2の脆弱性「DROWN (Decrypting RSA with Obsolete and Weakened eNcryption)」の詳細が公表された(The DROWN AttackOpenSSL BlogRed Hat Security BlogJVNVU#90617353)。

SSLv2の安全性が低いことは知られているが、多くのサーバーでSSLv2のサポートが有効になっている。TLSをサポートするサーバーとクライアントとの間では、SSLv2が有効になっていても実際の通信に使われることはないため、サーバーによるSSLv2のサポートはセキュリティーリスクとみなされていなかった。

DROWNではサーバーとクライアントがTLSで通信していても、攻撃者はSSLv2接続でパディングオラクル攻撃を仕掛けて暗号を解読できる。サーバーがSSLv2を有効化している場合のほか、クライアントが接続しているサーバーでSSLv2を有効化していなくても、秘密鍵を共有する他のサーバーでSSLv2を有効化している場合にはDROWNの影響を受ける。たとえば、SSLv2がメールサーバーで有効になっていて、SSLv2を無効にしたWebサーバーと秘密鍵を共有している場合、メールサーバーにパディングオラクル攻撃を行い、Webサーバーでの暗号化された通信を解読できる。

The DROWN Attackによると、HTTPSサーバー全体のうち17%がSSLv2を有効化しており、16%がSSLv2を有効にした他のサーバーと公開鍵を共有している。合計するとDROWNの影響を受けるHTTPSサーバーは全体の33%となり、上位100万ドメインでも25%に上るという。

サーバー管理者はSSLv2を無効化することでDROWNに対処できる。ただし、SSLv2の無効化はサーバーソフトウェアによって複雑な処理が必要なこともある。OpenSSLの場合は、簡単な対処方法として最新版への更新が推奨されている。IISではバージョン7.0以降、NSSではバージョン3.13以降で、SSLv2がデフォルトで無効となっている。これらのソフトウェアを使用している場合でも、The DROWN Attackが提供している脆弱性チェックツールでの確認が推奨される。

DROWNはサーバー側での対処が必要であり、クライアント側では特にできることはない。利用するWebサイトがDROWNの影響を受けるかどうか、上述の脆弱性チェックツールで確認しておくといいだろう。The DROWN AttackではAlexaトップ10,000サイトで脆弱性のあるドメインをリストアップしているが、リストには日本のWebサイトも多数含まれている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • TLSをサポートするサーバーとクライアントとの間では、SSLv2が有効になっていても実際の通信に使われることはないため、サーバーによるSSLv2のサポートはセキュリティーリスクとみなされていなかった。

    の一文にビックリ。
    要求されさえすればいつでも脆弱なプロトコルで応えるようになっていることが、なぜリスクにならないと考えられるのか…。
    世のサーバー管理者のセキュリティ意識ってそんなものなの…違うよね?
    SSLv2のリスクが小さい(許容できる)と見ていたとしても、それは「有効になっていても通信に使われることはないため」が理由じゃないよね?
    ってかこれはDROWN以前のセキュリティ一般論だよね?

    秘密鍵を共有する他のサーバーでSSLv2を有効化している場合にはDROWNの影響を受ける。

    鍵が共有ならセキュリティの強度は一番脆い所で決定される、これもDROWNに限らないセキュリティ一般論だと思うのだけど、何でこのコンテキストで述べられているのだろう?
    以前にSSLの脆弱性が明らかにあった時にWebサーバー以外がアウトオブ眼中の管理者が多かった、ってこと?

    何か、DROWN脆弱性そのものとは異なるレイヤレベルの危険性ばかり述べられている印象を受けるんだけど。
    DROWNが危険っていうんじゃなくて、危険なSSL運用が多いよ、って感じ。
    セキュリティ啓発の一種、なのか?

    • by Anonymous Coward on 2016年03月04日 22時03分 (#2974903)

      TLSをサポートするサーバーとクライアントとの間では、SSLv2が有効になっていても実際の通信に使われることはないため、サーバーによるSSLv2のサポートはセキュリティーリスクとみなされていなかった。

      この記述はThe DROWN Attack [drownattack.com]の元ページからの引用です。
      (タレコミが引用であることを明示していないのは良くないと思います)

      一見おかしな記述のようですが、そうではありません。

      このDROWN攻撃を利用すると、SSLv2によるパディングオラクル攻撃により、TLSで行っている通信を解読できます。
      そのため、クライアントがTLSで通信しても、サーバがSSLv2をサポートしていると、通信を解読されてしまうことになります。

      従来は、クライアントがTLSをサポートしている状況であれば、サーバのSSLv2サポートはセキュリティリスクではないと考えられていたが、実はそうではなかったということです。

      元論文によれば、

      In order to decrypt one TLS session, the attacker must passively capture about 1,000 TLS sessions using RSA key exchange, make 40,000 SSLv2 connections to the victim server and perform 250 symmetric encryption operations.
      (攻撃者は、1つのTLSセッションを解読するのに、約1,000回のTLSセッションをキャプチャーし、標的サーバに対して40,000回のSSLv2接続を行い、さらに250回の対象鍵暗号化操作を行う必要がある)

      とのことです。

      親コメント
      • なるほど、「サーバーでのSSLv2サポートはTLSのみサポートするクライアントにとっても脅威」という意味での言い回しだったんですね。
        表現はヘンテコだけどまあ理解できました。

        親コメント
      • by Anonymous Coward

        元コメントは「そもそもSSLv2を有効なまま放置しているのが問題だ」という意味、つまり「クライアントがTLSをサポートしている状況であれば、サーバのSSLv2サポートはセキュリティリスクではない」という考え方自体に問題があると言っているのです。

        おかしな記述云々という意味ではありません。
        あなたの言っていることは理解したうえで、そもそもその考え方が間違っていると言っているのです。

        • by Anonymous Coward

          別人ですが、例えば
          webサイトが単一方向の情報発信系で、電子証明書も暗号化目的では無く実在証明だとして、
          クライアント側から意図して低いレベルの通信できたあげく、
          通信中に内容が改ざんされても、サーバ運営者では無く閲覧者の責任ではありませんか?

          非常事態用にHTTP接続でも可能なログイン経路を残した金融機関もありますね。
          もちろん利用は自己責任の注意書きで。

  • by Anonymous Coward on 2016年03月04日 17時53分 (#2974775)

    そんなサーバ無いやろ…(管理してるサーバをチェックしつつ)

    • by Anonymous Coward on 2016年03月04日 19時39分 (#2974833)

      OpenSSLは今回のバージョンアップまでデフォルトでSSLv2が有効だったそうな。「対策」とはSSLv2をデフォルトで無効にすること。

      親コメント
      • by Anonymous Coward on 2016年03月04日 19時51分 (#2974836)

        POODLE [wikipedia.org] 問題でSSLv3にさえも仕様そのものに脆弱性が見つかっているわけですし、RFC 6176 [ietf.org], RFC 7568 [ietf.org]の推奨通りSSLv2/SSLv3は廃止すべきだと思うんですがねぇ・・

        親コメント
        • by Anonymous Coward on 2016年03月04日 20時22分 (#2974861)

          LibreSSLやBoringSSLはとっくに廃止してるね。NSSも現在削除パッチを絶賛レビュー中。

          親コメント
          • by Anonymous Coward on 2016年03月04日 22時08分 (#2974908)

            自分が管理している機械で外に向けてTLSを喋るデーモンがリンクするライブラリは
            OpenSSLからLibreSSLにほぼ差し替え終わった。(まだ僅かに残っているが)
            もはやOpenSSLを使ってること自体が結構なリスクだと思う。

            今回の件はOpenBSDチームがOpenSSLの体制や現状にぶち切れた理由そのままで草も生えんわ

            親コメント
    • by Anonymous Coward on 2016年03月05日 10時04分 (#2975073)

      古い特殊な端末は、SSL v2のみサポートってあるんですよ。それに接続されるサーバは当然ながらSSL v2をサポートし続けなくてはなりません。
      泣きたい

      親コメント
    • by Anonymous Coward on 2016年03月04日 21時56分 (#2974901)

      スマホでなく最新のガラケー()使っている層もいますので
      ガラケー対応を切れないサイトはあるんじゃないかね

      # キャリアやメーカーに見捨てられるのはAndroidだけではない

      親コメント
      • by Anonymous Coward

        最新のガラケー事情を知らないので聞きたいのだけど、直近5年以内でSSLv2でないとダメな端末ってどれくらいあるの?

        • by Anonymous Coward

          なぜ5年?

          • by Anonymous Coward

            特に根拠はないが、そんだけの期間のSSLv2必須端末の数がわかれば、
            対応を切る、切らないの判断がざっくりできるのでは?ってこと。
            一台でもあったらサポートを切らないという判断もあると思うけど、一般にそれは過剰品質だよね。

typodupeerror

物事のやり方は一つではない -- Perlな人

読み込み中...