「Pass-ta-key」攻撃が明らかにした、同期されたパスキーのリスク

Windowsデバイス上で既に実行されているマルウェアが、Googleパスワードマネージャーから被害者の同期されたパスキーを直接取得できるようになった。これは、新たな調査結果によるものである。 Unit 42による「Pass-ta-key」に関する調査 , 、ここでは「Pass-ta-key」と総称される3つの攻撃について詳しく説明されている。‘

こうした攻撃は、同期されたパスキーのような一般消費者向けソリューションが、必ずしも企業での利用ケースに適しているとは限らない理由、そしてほとんどの従業員向け利用事例では、デバイスに紐づいたパスキーを採用する方が無難である理由を如実に示しています。 ITおよびセキュリティチームは常に、セキュリティと利便性のバランスを取る必要があります。政府機関、金融サービス、および規制の厳しい業界にとって、「Pass-ta-key」の事例は、同期型パスキーがデバイスの信頼性、復旧、および認証情報のライフサイクルのその他の段階に関連する新たなリスクをもたらし得ることを改めて認識させるものです。.

ここでは、「Pass-ta-key」攻撃とは何か、組織がこれらの攻撃から学ぶべきセキュリティ上の教訓、そしてセキュリティを最優先する組織が、安全でフィッシング攻撃に強いパスワードレス認証を導入する際に優先すべき機能について確認していきましょう。.

基本的な「Pass-ta-key」攻撃では、権限のないマルウェアが信頼されたデバイスを装い、PINや生体認証、あるいはユーザーの操作を一切必要とせずに、被害者のパスキーの1つに対する署名付き認証応答を要求することができます。.

2つ目の攻撃「Silver Pass-ta-key」は、さらに一歩踏み込んだものです。マルウェアは、デバイスにGoogleのクラウド認証アプリへの再登録を強制し、被害者の認証キーの代わりに自身の認証キーを登録します。 Googleはこの新規登録を受け入れます。なぜなら、クラウド認証システムは、新しいキーが信頼できるハードウェアから発行されたものかどうかを確認しないからです。この時点から、攻撃者は被害者のデバイスにアクセスすることなく、まったく別のマシンから認証を行うことが可能になります。.

3つ目の「Golden Pass-ta-key」は、セキュリティチームにとって最も懸念すべきものです。これは、Googleがアカウントに同期されたすべてのパスキーを暗号化するために使用するマスターキーである「セキュリティドメインシークレット」を抽出します。このキーは、デバイスの登録や復旧の際にChromeへ一時的に送信されますが、Unit 42の調査により、ブラウザのプロセスメモリ内でこのキーにアクセスできることが判明しました。.

攻撃者がセキュリティドメインのシークレットを入手すれば、そのアカウントに同期された過去および将来のすべてのパスキーを復号化することが可能になります。Googleはこの報告を受けてChromeのログからシークレットを削除しましたが、メモリ内での根本的な情報漏洩は依然として残っており、キーをローテーションする手段はまだ存在しません。.

推奨される対策、すなわち、より厳格なユーザー認証チェック、再登録プロセスの強化、およびマスターキーをブラウザのメモリに保存しないようにすることなどは、Googleに限らず、同期型認証情報ストアを運用するあらゆるベンダーにとって有益なアドバイスである。.

「Pass-ta-key」とは、パスキー自体が脆弱であることを意味するわけではありません。これは、1つのマスターシークレットの下で、ログイン済みのすべてのデバイス間でユーザーの秘密鍵データを同期させるという仕組みこそが、まさにこれらの攻撃の標的となっている機能であることを意味しています。.

この違いは、個人の消費者よりも企業にとってはるかに重要であり、セキュリティ担当者がこの調査から学ぶべき3つの点が浮かび上がります：

1. 企業は、同期されたパスキーの使用には慎重を期すべきである. 同期されたパスキーの最大の利点は、スマートフォンに登録された認証情報が、ノートパソコンや今後購入するデバイスでも利用でき、そのすべてが、Google、Apple、Meta、あるいはユーザーに代わって管理を行う他のプロバイダーが保持する単一の秘密鍵によって保護されている点にあります。これは、スマートフォンを買い替える消費者にとっては妥当なトレードオフと言えます。 しかし、従業員用の認証情報に関しては、ほとんどの場合、これは受け入れられません。なぜなら、電子的にコピー可能な認証情報では、その認証情報が正当な所有者によって安全に管理されているという保証が著しく低下してしまうからです。.

RSAでは、秘密鍵はどこにも同期されません。. RSA 認証機能 各パスキーを、そのパスキーを作成した登録済みデバイス1台に紐付けます。同様に、 RSA iShield Key 2 この認証情報は、トークンの外部に秘密鍵を一切公開しない専用のFIDO2ハードウェアに格納されています。また、メモリ上にマルウェアが抽出できる共有秘密鍵が存在しないため、マルウェアがそれを抽出することもできません。そもそも、そのような共有秘密鍵は存在しないからです。.

2. フィッシング対策は第一歩であり、最終段階ではない. Pass-ta-keyは、認証情報を脅かすリスクがフィッシングだけにとどまらないことを示しています。この攻撃は、デバイスに埋め込まれたマルウェアを通じて行われ、認証情報の保存場所そのものを標的とします。フィッシングには耐性があるものの、侵害されたエンドポイントへの対策が講じられていない認証方式では、問題の半分しか解決できていないことになります。.

RSAモバイルロック これは、その方程式のもう半分をカバーするものです。つまり、認証情報が保存されているデバイス上のマルウェアやその他の脅威を検知するため、侵害されたエンドポイントが、盗まれたパスキー保管庫となる前にフラグが立てられます。フィッシング対策認証とデバイスレベルの脅威検知は、それぞれ異なる攻撃経路をカバーします。政府機関、金融サービス、および高度なセキュリティが求められる組織には、その両方が必要です。  また、セキュリティを維持するためには、これらの組織はフィッシング対策にとどまらず、高度な脅威から防御し、認証情報のライフサイクル全体を通じて保護するソリューションを必要としています。.

3. パスキーソリューションには、さまざまな種類があります。. Google Password Managerは、スマートフォンやノートパソコンを所有しているものの、IT部門のサポートがない一般ユーザーが簡単にログインできるように設計されました。これは、一部の企業にとっては妥当な設計目標です。しかし、重要インフラや、規制対象データ、個人識別情報（PII）、あるいは機密性の高い知的財産（IP）にアクセスできる従業員にとっては、不適切な選択となります。.

メンバーとして FIDOアライアンス また、エンタープライズ向けワーキンググループにおいて主導的な役割を果たしているRSAは、お客様が求める高度なセキュリティ要件を満たすため、標準規格の策定を推進しています。これまでの経験から、FIDOでは、RSAが自社でどのように導入しているかを詳しく解説しています。 パスワードレス・ソリューション 当社のグローバルな従業員全体において。独自のテストを通じて、利便性を最優先した設計とエンタープライズグレードの設計は、単にブランド名が違うだけの同じ機能ではないことが分かっています。これらは異なる脅威モデルに対応して構築された別々の製品であり、こうした研究を通じてその違いが明らかになるのです。.

規制対象の業界で働いている場合、「Pass-ta-key」は、パスワードレスに関する以下のベストプラクティスを思い出させてくれる良いきっかけとなります：

• リスクベースのアプローチを採用する. リスクが最も高いユーザー、ユーザーグループ、およびワークフローを優先的に対応してください。組織は、自社の最重要資産を保護する上で、利便性をセキュリティよりも優先させる余裕はなく、必要に応じてデバイスに紐づいたセキュリティキーやハードウェアセキュリティキーの使用を義務付けることを検討すべきです。.
• フィッシング対策にとどまらない管理措置を講じる。. 「Pass-ta-key」はフィッシング攻撃ではなく、マルウェアによるものでした。同様に、MGMリゾーツが侵害された際も、攻撃者はヘルプデスクに対してソーシャルエンジニアリングを仕掛け、認証情報をリセットさせました。認証情報がフィッシングによって詐取されたり盗まれたりしたわけではありません。組織がフィッシング耐性のある認証を導入するのは正しい対応ですが、確実性を確保するためには、その他の対策も必要です。 安全な登録, ～から守る マルウェア, 、 ヘルプデスクでの不正行為を防止する.
• あらゆる機能を網羅した、パスワード不要のソリューションを探しましょう。. パスワードレスは、あらゆるユーザーや環境において機能してこそ、その真価を発揮します。政府機関、金融サービス、および高度なセキュリティが求められる組織は、クラウド、デスクトップへのログイン、データセンターに対応できるパスワードレスソリューションを優先的に導入すべきです。 また、これらのソリューションには、オフラインアクセスや共有ワークステーションといった多様な実利用シナリオに対応できる俊敏性に加え、SaaS、プライベートクラウド、オンプレミス、エアギャップ環境など、あらゆる場所に展開できる柔軟性も備わっている必要があります。.

RSAに連絡する 当社がパスワードレスをどのようにサポートしているかについて、詳しくはこちらをご覧ください。 金融サービス また、 政府. あるいは RSA ID Plusを試してみてください クラウド、ハイブリッド、オンプレミス環境において、パスワードレスなどの技術をどのように導入しているかをご覧ください。.