KDDIのISP向けメールから760万人のパスワード漏洩 疑問点を整理する

KDDIによるISP事業者向けメールシステムに対する不正アクセスでは、約760万人分のパスワードが漏洩したことが話題になっています。

6月23日の第一報に続き、7月6日の第二報では具体的な漏洩の実態が明らかになりました。各社からの発表を踏まえて、疑問点を整理してみます。

パスワード漏洩の疑問点を整理

一連の発表に対する疑問の声として多いのが、「パスワード」がどういう状態で漏洩したのかという点です。

KDDIからの第一報では「パスワードにはハッシュ化・暗号化されたものも含む」となっていたことから、平文のパスワードが含まれていることを示唆していました。

果たして平文のパスワードは含まれていたのか、第二報を踏まえてKDDIに確認したものの、技術的な詳細は開示しないとの回答になりました。理由は「不正アクセスの攻撃者に情報を与えることになるため」（KDDI広報）としています。

詳細は不明ですが、各社がパスワードリセットなどの対策に踏み切っている以上、利用者側でも平文のパスワードが漏洩したと想定した上で、他のサービスでも同じパスワードを使い回している場合は速やかに変更したほうがよさそうです。

パスワードが漏洩した人数の761万6173人という数字については、「ISP事業者が保有する契約者情報と突合し、解約済みアカウントやテストデータなどの契約者情報を有していないものを除外した、実際に漏洩を確認した契約者数」（KDDI広報）としています。

KDDIが公表した漏洩人数のデータ（KDDIのプレスリリースより）

次に気になるのが、漏洩した情報が悪用されていないのかという点です。約186万人のパスワードが漏洩した@niftyではこれまでの経緯を公開しており、不正アクセスの発生後に急激な負荷上昇が確認されたとしています。

@niftyが公開している不正アクセスの経緯・原因（ニフティのWebサイトより）

この際、メールボックスへの不正アクセスがあったのではないかという不安の声はあるものの、「具体的な形跡や二次被害は確認されておりません」（ニフティ広報）としています。

約463万人のパスワードが漏洩したBIGLOBEにも確認したところ、「メールボックスへの不正アクセスという特定の事象に限らず、二次被害は現時点で確認されておりません」（ビッグローブ広報）としています。

KDDIによれば、現時点で漏洩が確定しているのはメールアドレスとパスワードのみとしており、それ以外の情報については「可能性は否定できませんが、詳細は確認できず特定は困難」（KDDI広報）との見解を示しています。

なお、BIGLOBEメールの利用者からは、自分のアドレスで大量のフィッシングメールを「送信させられた」との報告がSNSなどで見受けられます。

こうした報告についてはBIGLOBE側でも把握しているようですが、「今回漏洩した情報を用いたフィッシングメール大量送信であるという直接的な関連性は確認されていません」（ビッグローブ広報）としています。

BIGLOBEでは利用者の約8割が直近2か月でメールサービスを利用していないとのことですが、まずは自分のアカウントの状態を確認したほうがよさそうです。また、通常は有料となるメールアドレス変更サービスを無料で提供しています。

@niftyによる経緯の中でもう1つ気になるのは、最初に不正アクセスが発生したのは5月24日で、「KDDIからの報告で後日判明」となっています。リアルタイムでは気付けなかったことになりますが、どういう事情があったのでしょうか。

背景として、このメールシステムの開発や運用管理をしているのはIMAPサーバーを含めてKDDI側とのこと。@nifty側では「KDDIから提供されたログをもとに利用状況を監視しており、その過程で通常利用を大きく超える負荷を確認したため、速やかにKDDIへ報告を行い、原因究明の調査を開始いたしました」（ニフティ広報）と説明しています。

根本的な原因とする第三者製ソフトウェアについて、KDDIは6月17日時点でベンダーが認識していない脆弱性だったと明かしています。これも詳細は開示していないものの、「ベンダー側で脆弱性情報の公開に向けた取り組みを進めています」（KDDI広報）とのことから、準備が整った段階で公開すると考えられます。

原因となった第三者製ソフトウェアの名前は開示していない（KDDIのプレスリリースより）

セキュリティ上の理由から開示できない情報が多いのはやむを得ないとはいえ、利用者目線では不安が残る部分もあることから、引き続き調査や情報提供を期待したいところです。

なぜ平文のまま保存されていたのか

膨大な数のパスワードが漏洩したことから、さまざまな疑問も出てきています。特に多いのが、一部が平文だった可能性があることから、「なぜパスワードをハッシュ化せず平文のまま保存していたのか」という疑問です。

詳細は各社に説明を求めたいところではありますが、歴史的な経緯を考えると、かつてメールプロトコルでは通信経路上での暗号化がされていなかったため、「チャレンジ・レスポンス認証」のような方式が考案されました。

この方式ではサーバー側にも平文のパスワードが必要になるのですが、この時代は経路上でパスワードを窃取される恐れがあったので、それを防ぐためならサーバー側に平文で保存するほうがマシという判断だったように記憶しています。

その後はSSL/TLSによって通信経路を暗号化する方式が確立し、サーバー側はハッシュ化したパスワードを保存するだけで済むようになったはずです。ただ、それは最近15年くらいの話であり、30年以上の歴史があるISPの内部では互換性維持などの理由で平文が残っている可能性はありそうです。

一方で、「ハッシュ化されていれば安全」という点にも、やや注意は必要です。いわゆるレインボーテーブル対策としてパスワードに適当な文字列（ソルト）を付け足す対策はよく知られていますが、最近はGPUを用いた総当たりも考慮する必要があるようです。

こうした要件を踏まえた適切な実装がされていれば、少なくとも漏洩が判明してから利用者がパスワード変更やリセットをするまでの時間稼ぎにはなりますし、攻撃者にとっても割に合わなくなると考えられます。

いずれにしても、サービスごとに異なる十分に長いパスワードを使うことが重要です。サービス側が対応しているなら、パスワードの漏洩対策として2要素認証、フィッシング対策としてパスキーも有効といえます。