研究者らによると、攻撃者が企業の防御を突破しマルウェアを仕込むことに成功した場合、信頼された正規のワークフローが悪用され、パスキーで保護されたアカウントが乗っ取られる可能性があります。アナリストらは、この問題はパスキー自体の欠陥ではなく、それを支える一連のプロセスの不備にあると指摘しています。
パスワードに代わる手段として企業に広く普及しているパスキーですが、Palo Alto Networks傘下のUnit 42がその保護機構を回避する手口を明らかにするレポートを公表し、アナリストの間で懸念が広がっています。ただし、実証された攻撃はあくまで攻撃者による侵入が成功した後にしか成立しない点は強調しておくべきだとアナリストらは述べています。
また、今回の問題は厳密にはパスキー自体の欠陥によるものではなく、それを取り巻く手続き上の弱点に起因するものだとも指摘しています。
「研究者たちは、根幹となる暗号技術を破ったわけではありません。彼らが突いたのは、その周辺にある隙間、つまりオンボーディングのフロー、リカバリー(復旧)の仕組み、そして十分に検証されていなかった信頼シグナルです」と、コンサルティング企業Acceligenceの最高経営責任者(CEO)であるJustin Greis氏は述べています。「この違いは重要です。実際のリスクがどこに存在するのかを示しているからです」
Palo Altoのレポートによると、実証された攻撃は「侵害されたエンドポイント上のマルウェアが、オンボーディング、リカバリー、デバイス信頼のワークフローを悪用し、パスキーで保護されたアカウントを乗っ取る仕組みを示している」ほか、「攻撃者がユーザー操作なしに認証を行い、ユーザー検証要件を回避し、同期済みのパスキー秘密鍵をすべて抜き出す方法」も示しているといいます。
Palo Altoは、総称して「Pass-ta-key」と呼ばれる3種類の攻撃カテゴリーを説明しています。1つ目は「Pass-ta-key」で、被害者のデバイス上で動作するマルウェアを使い、権限昇格やデバイスのロック解除、ユーザー操作を必要とせずに、Googleで同期されたパスキーによって保護されたアカウントを攻撃者が乗っ取るというものです。2つ目は「Silver Pass-ta-key」で、攻撃者がGoogle Cloud Authenticatorを騙し、被害者が生体認証でデバイスのロックを解除したと誤認させることで、認証時に被害者のデバイスを一切使わずにアカウントを完全に乗っ取ります。3つ目は「Golden Pass-ta-key」で、同期済みのパスキーをすべて抜き出し、認証情報の闇市場で共有・売買できる形式にするというものです。
世界規模の企業における攻撃対象領域(アタックサーフェス)は総じて複雑であることから、レガシー環境や仮想環境が混在するインフラにパスワードレスのプロセスを適応させることに苦労してきたCISOも少なくありません。 パスキーは、パスワードレス戦略を実装する第一歩として、企業のCISOの間で最近になって採用が進んでいます。
アナリストやコンサルタントの大半は、Palo Altoが報告した欠陥は重大なものであるという見解で一致しています。ただし、これは攻撃者がすでに環境への侵入を果たし、マルウェアの設置に成功していることを前提としています。残念なことに、そうした侵入は権限を持つユーザーがたった一人でもどこかで悪意あるリンクや添付ファイルを不用意にクリックしてしまえば成立してしまうため、この「事前侵入」という前提は十分に現実的だと言えます。
問題の本質は実装上の不備
このレポートが明らかにしているのは、パスキーそのものに内在する欠陥というよりも、それを取り巻く多岐にわたる仕組みに十分な注意が払われてこなかったという点です。
Greis氏によれば、CISOは今後、ユーザーの行動が必ずしも想定通りにはならないという前提に立ち、何をすべきか、そして何をテストすべきかに注力する必要があるといいます。
レポートで取り上げられた複数の事例において、問題は「規格そのものに欠陥があるからではなく、実装が規格に追いついていないから」発生したと同氏は指摘します。「これはセキュリティの世界で繰り返し目にしてきた構図と同じです。仕様は健全でも、それを実装するエコシステムには濃淡がある、ということです」
コンサルタントで、FormerGovのエグゼクティブディレクターを務めるBrian Levine氏もこれに同意しています。
「自組織がリライング・パーティ(認証結果を利用する側)となっているサービスについては、ユーザー検証を必須とし、認証レスポンス内のユーザー検証フラグが実際に検証されているかどうかを確認する必要があります」と同氏は述べます。「研究者たちは、このフラグなしでログインを受け入れてしまう実在のサービスを発見しました。これでは、多要素認証によるログインが気づかぬうちに単一要素のログインへと後退してしまいます」
IDCでセキュリティ担当グループ・バイスプレジデントを務めるFrank Dickson氏は、この攻撃はあくまで事前の侵入が成功していることを前提としている点をCISOに強調したいと付け加えました。
「これはインターネット越しにパスキーがハッキングされるという話ではありません。[攻撃者が]すでに家の中に入り込んだ後に何をするか、という話です。つまり本当の見出しは、エンドポイントがクリーンな状態でなくなった瞬間、『フィッシング耐性』は耐性ではなくなる、ということです」と同氏は述べています。
「検証をオプション扱いにするのはやめるべきです」と同氏は助言します。「検証を必須設定に切り替え、サーバー側で毎回チェックを行い、YubiKeyのようなハードウェア紐付けの鍵は、最も重要なアカウントのために温存してください。物理デバイスから決して外に出ない鍵は、攻撃者が一括で収集することが絶対にできない鍵なのです」
Secret Double Octopusでマーケティング責任者を務めるOr Finkelstein氏も、CISOたちがシステムのパスキー対応の在り方について慢心してきたという点に同意しています。
「CISOはおそらく、ユーザー検証がどのように強制されているか、登録(エンロールメント)とリカバリーがどのように機能しているかを点検し、認証情報を同期させるのかデバイスに紐付けるのかについて明確かつ実効性のあるポリシーを持ち、さらに疑わしいエンドポイントや認証器を迅速に無害化できるITDR(ID脅威検知・対応)システムを備えておくべきでしょう」と同氏は述べています。「多くの本格的な企業環境では、EDRとデバイス管理によって初期段階の攻撃が発生する可能性は低減できますが、侵害後に取り得るすべての攻撃経路を塞げるわけではありません」
不十分なサポートプロセスがパスキーを弱体化させる
十分に堅牢とは言えないサポートプロセスの欠如こそが、実はパスキーの能力を弱め、こうした仕組み本来の存在意義を損なっているのだと主張する声もあります。
IANSの教員陣の一人であり、長年サイバーセキュリティのコンサルタントを務めるJ. Wolfgang Goerlich氏は、そもそもFIDO2の元々の仕様は、秘密鍵を物理的な認証器に紐付けることで認証情報の窃取を排除するものだったと指摘します。ところが、同期型パスキーによって認証情報の可搬性が再び持ち込まれ、その結果、Palo Altoのレポートで指摘されたような形の認証情報窃取リスクも再び生まれてしまったというのです。
「パスワードレスのシステムの強度は、それを再確立するフロー(再登録のプロセス)の強度と全く同じです」と同氏は述べます。「ここで挙げられている本格的な手口はいずれも、まずデバイスに再登録を強制させることから始まります。多くのセキュリティチームは、こうした事態を一度もモデル化したことがなく、監視したこともなければ、対応訓練を行ったこともありません」
Goerlich氏がCISOに向けて助言するのは、権限を持つアクセスや機微なアクセスすべてについて、ハードウェアトークンやコンピューターといったデバイス紐付け型の認証器を必須とすることです。リスクの低いアクセスについてはウォレット(パスキーを保存するアプリやサービス)の利用を認める余地もあるとしつつ、同氏はこう付け加えました。「とはいえ、Webブラウザ上のパスワードが長らくリスクにさらされてきたのと同じように、今やブラウザ内のパスキーも容認できないリスクとみなすべきです」
Evan Schumanは、本人が認めたがらないほど長年にわたりIT分野を取材してきたジャーナリストです。小売業界向けテクノロジーサイトStorefrontBacktalkの創刊編集長であり、CBSNews.com、RetailWeek、Computerworld、eWeekでコラムニストを務めてきました。また、BusinessWeek、VentureBeat、Fortuneから、The New York Times、USA Today、Reuters、The Philadelphia Inquirer、The Baltimore Sun、The Detroit News、The Atlanta Journal-Constitutionに至るまで、数多くの媒体に署名記事を寄稿してきました。EvanはCIO、CSO、Network World、InfoWorldの常連寄稿者でもあります。
Evanは、次の記事で2025年のAZBEE賞(エンタープライズ・ニュース部門)の金賞を受賞しました: Design flaw has Microsoft Authenticator overwriting MFA accounts, locking users out
連絡先は[email protected]で、LinkedInでもフォローできます。