雑記

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|
2007|01|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|09|11|
2009|02|03|05|06|07|08|10|11|12|
2010|01|03|04|05|06|07|08|09|10|
2011|05|06|09|10|
2012|03|07|09|12|
2013|01|02|04|05|07|08|10|11|
2014|04|05|08|10|12|
2015|01|05|
2016|09|

2014-04-16 [長年日記]

OpenSSLの脆弱性のメールサービスへの影響

更新履歴:

`flat` ;4/17

Outlookとの組み合わせ時の説明をちゃんと書きました

先日公開されたOpenSSLの脆弱性については、Webサービスを対象にした解説や対策が多いですが、他のサービスも危ないよね、という話です。

まず、前提となるOpenSSLの脆弱性についての告知や解説については以下を参照してください。

さらに昨日(15日)になって、JPRSからDNSサーバの設定の再確認についての緊急告知が発表されました。

これに呼応して、以下のような情報も公開されました。

このキャッシュポイズニングに関するJPRSからの緊急告知の冒頭には、

最近、日本の大手ISPにおいてカミンスキー型攻撃手法によるものと考えられるキャッシュDNSサーバーへのアクセスが増加している旨、JPRSに報告がありました。

とありますが、「アクセスが増加」した原因として(あくまで個人的な憶測ですが)OpenSSLの脆弱性を突いてSSL証明書の秘密鍵情報の入手に成功した人々が、ユーザを偽サイトに誘導するためにDNSへのキャッシュポイズニング攻撃を始めた、という見方も1つの可能性として考えられます。つまり、

  1. OpenSSLの脆弱性を突いて秘密鍵の情報を取得
  2. 取得した秘密鍵をつかって偽サーバを構築
  3. DNSキャッシュポイズニングで一般ユーザを偽サーバに誘導

という状況が、すでに始まっているのかもしれません。

私の目についた範囲では、この件については主にWebサービスでの脅威が解説されています。が、OpenSSLはWeb以外のサービスの実装でも使われており、そうしたサービスでも同様に危険はあります。ここではメールサービスを例に、その危険性について記述します。

ここで少し{=昔話=}背景の説明をすると、電子メールはいわゆるインターネット黎明期から存在するサービスで、ftpやtelnetなどと同様、平文でのパスワード認証が普通であった、牧歌的だった時代から続いているサービスです。その後の時代の要求に従い、認証は平文からAPOPやCRAM-MD5, DIGEST-MD5といった暗号化方式を採用する方向へと進んでいきましたが、メールの内容の重要性の高まりとSSLの登場により認証だけでなく通信全体を暗号化する方向へと変わっていきました。さらにクライアント側での暗号化方式の認証への対応の差や、乱立した認証方式に全て対応しようとするとサーバ側に生パスワードを保存しなければならない等の事情もあいまって、平文認証はSSLとの組み合わせという形で今なお現役の認証方式として残り続けています。

さて、ここまで読めばなんとなく気づくかと思いますが、メールサービスをターゲットとして、

  • OpenSSLの脆弱性を突いて秘密鍵の情報を入手する
  • 入手した秘密鍵を使って偽メールサーバを立てる
  • この偽サーバのIPアドレスを返すようにDNSポイズニングを仕掛ける
  • アクセスを中継してユーザには通常のサーバと見分けがつかないようにする

という中間者攻撃を仕掛ければ、メールサーバとの通信内容を盗聴することができ、さらに{ユーザが平文認証を使っている}という条件が重なると、{{~orangered:その証明書が有効な期間は偽サーバを経由するメールアカウントのパスワードが盗み放題~}}になってしまいます。

この状況に対処するためには、サーバ側では

  • OpenSSLを脆弱性の無いバージョンにアップデートする
  • SSL証明書を再発行する
  • それまで使っていた証明書はRevokeする

という対応が必要です。Revokeまでやらないと、盗み取った古い証明書を使った偽サイト側も相変わらず正規のサイトと判定され、問題のある状態が継続されるはずです。

ユーザ側でこの問題に対処するには、SSL通信を使っている場合でも暗号化された認証方式を利用するようにします。例えばThunderbirdなら、

  1. [ツール]→[アカウント設定]を開く
  2. 各アカウントの「サーバ設定」をクリックする
  3. セキュリティ設定で接続の保護を"SSL/TLS"に、認証方式を"暗号化された認証方式"にする

という手順で設定できます。OutlookはExpressの頃から 統合 Active Directory 認証およびローカル Windows アカウント認証のみをサポートとなっており、手元のOutlook 2010で試したところ、Courier-imapサーバでは暗号化された方式での認証はできないようでした。

さらっと書いてしまいましたが、非MSなメールサーバでOutlookに対応しようとするとSSL+平文による認証を許可するしか無い、というのが現状で、今回のOpenSSLの脆弱性のインパクトはかなり大きいと言えるでしょう。

`green`