mSecure、インシデント後にパスワード変更を顧客に呼びかけ

mSecureの顧客は、パスワードマネージャー内に保存した認証情報を保護するよう求められています。対応は、マスターパスワードを1つ変更するだけにとどまりません。

開発元のmSeven Softwareは11月3日、mSecureに関連する不審なアクティビティを発見したとして、現在および過去の顧客に通知しました。同社は即時の保護措置として、パスワードの変更、二要素認証のリセット、既存のパスキーの削除などを推奨しています。

その後、顧客が共有したサポートからの返信によると、暗号化されたmSecure Cloudのデータベースが盗まれたとみられます。ただし、攻撃者がその中身を読み取れるかどうかは別の問題であり、まだ判明していません。

mSecureが公表した内容

mSevenはメールで、調査を開始し、緩和措置を講じ、外部のサイバーセキュリティ専門家にも協力を依頼したと説明しました。 このメールはmSecureのサポートフォーラムで顧客が転載しています。

通知には、原因、インシデントの発生日、影響を受けた顧客の数、保存されていたシークレットが漏えいしたかどうかは記載されていませんでした。

その後、別の顧客が mSevenからのものとされるサポート回答を投稿しました。回答によると、権限のない第三者が、現在および過去のユーザーの情報を含む暗号化されたデータベースを入手したということです。影響を受けたのはmSecure Cloudの同期ユーザーで、mSevenは、攻撃者がその中の機密情報にアクセスした証拠は確認していないと述べています。

BleepingComputerも11月4日に同じ説明を報じました。顧客が共有したサポート回答を根拠としています。同メディアによると、mSevenは追加のセキュリティ対策を実施済みで、mSecureアプリが現時点で安全でないことを示す証拠はないとしています。

ただし、これはあくまで同社自身の評価であり、第三者による保証ではありません。サポート回答は当初の通知より詳しいものの、インシデントに関する完全な公開報告書の代わりにはなりません。

マスターパスワードの変更は対応の一部にすぎない

パスワードマネージャーのマスターパスワードと、その中に保存された認証情報は、役割が異なります。マスターパスワードを変更しても、メール、銀行、業務サービスなどへのサインインに使うパスワードが自動的に変わるわけではありません。

mSecure自身の アカウント保護ガイダンスは、こうした変更を各サービスの公式アプリまたはWebサイトで行う必要があるとしています。ただし、このガイダンスは一般的なアカウント復旧の手順を説明したものであり、今回のインシデントの経緯を示すものではありません。

パスワードマネージャーが認証情報をどのように保存・管理しているかを理解すると、対応に複数のアカウント変更が必要になる理由が見えてきます。

また、暗号化されていても、盗まれたデータベースが無害になるわけではありません。設計や攻撃者の手元にある秘密情報によっては、コピーされたVaultに対してオフラインで保護の突破を試みられる可能性があります。ただし、これはmSecureの暗号化が破られたことを意味するものではありません。

顧客が優先すべきアカウント

調査が続いている間の現実的な予防策は、他のサービスの突破口になり得るアカウントや、被害が最も大きくなるアカウントから着手することです。

• 主要なメールおよび復旧用アカウント: 公式サービス上でパスワードを変更し、復旧用の情報とアクティブなセッションを確認する。
• 金融・業務アカウント: 強力で固有のパスワードに変更する。mSecureに会社の認証情報が入っている場合はIT部門に連絡し、共有アクセスや特権アクセスを見直せるようにする。
• mSecureに保存した二要素認証のシークレット: 各サービスのセキュリティ設定で、影響を受けた認証アプリを再登録することを検討する。その際、利用可能な復旧手段は確保しておく。
• mSecureに保存したパスキー: 別のサインイン手段を確保したうえで、サービス側で古い登録を取り消し、新しいパスキーを作成する。

これらは予防策であり、すべての認証情報が漏えいした証拠ではありません。Malwarebytesは 重要なアカウントを優先して対応することを推奨しており、新しい認証情報の保管には一時的に別のパスワードマネージャーを使うことも提案しています。これはMalwarebytesによる予防的な助言です。一方、mSevenは、アプリが現時点で安全でないことを示す証拠はないとの立場だと伝えられています。

今回の警告は、 強力なパスワードだけではアカウントのあらゆるリスクに対処できない理由も浮き彫りにしています。パスワードに加えて、復旧手段や認証情報にも注意が必要です。

企業がインシデント対応を終える前に確認すべきこと

IT部門がまず行うべきは、従業員がmSecure Cloudを使っていたか、どの業務アカウントがそこに保存されていたかの特定です。管理者権限、金融関連、復旧用のアクセスを優先し、パスワード、認証アプリの登録、パスキーのうち、どれを交換済みか記録します。

別のサービスへ移行するだけでは、すでにコピーされた可能性のある認証情報は無効になりません。同様に、同期サービスを切り替えても、過去に盗まれたデータベースを取り戻すことはできません。各サービス側で変更を確認し、アクセスログに不正利用の形跡がないかを調べ、影響を受けたデータと封じ込めの状況についてmSevenに書面で説明を求めるべきです。

今回のインシデントは、パスキー全般に欠陥があることを示すものではありません。 Googleパスワードマネージャーの同期パスキーに関する別の調査は、サインイン方式そのものと並んで、認証情報を保管するシステムのセキュリティが重要であることを示しています。

対応を完了したとみなす前に、組織は、誰のデータが関係したのか、何がそのデータを保護していたのか、mSevenがどのようにインシデントを封じ込めたのかについて、詳細を求めるべきです。mSevenはアプリが現時点で安全でないことを示す証拠はないと述べていると伝えられていますが、より詳しい技術的な開示があれば、残るリスクを評価しやすくなります。それまでの間、影響の大きいアカウントの認証情報を交換し、その変更を確認することが、顧客にとってリスクを減らす具体的な手段になります。

関連記事: Snowflakeの顧客での侵害は、盗まれた認証情報と多要素認証の欠如によって、侵害されたログインが大規模なデータ窃取につながり得ることを示しています。