Microsoft Authenticatorの欠陥でMFAアカウントが上書きされ、ユーザーがロックアウトされる現象
(csoonline.com)- MFAの利用が増える中、Microsoft AuthenticatorではQRコードで追加した新しいTOTPアカウントによって既存アカウントが上書きされ、ユーザーがロックアウトされる可能性がある
- 衝突の核心は、アカウント識別にlabelだけを使う設計にあり、Google AuthenticatorやOktaなどのようにissuerとlabelを併用していない点にある
- 上書きはすぐには表面化しないため、ユーザーは数週間後あるいは数か月後に既存アカウントへアクセスしようとして初めてアクセス不能に直面する可能性がある
- 回避策は別の認証アプリを使うか、Secret Keyを手動入力する方法だが、企業環境の一般ユーザーにとっては実用性が低い
- Microsoftは意図した動作であり警告メッセージを提供していると説明し、その後は一部発行元のissuer欠落を理由に挙げつつ、将来的な改善の可能性だけを残した
QRスキャンが既存のMFAアカウントを上書きする仕組み
- Microsoft Authenticatorは、新しいアカウントをQRスキャンで追加する際、同じユーザー名を持つ既存アカウントを上書きすることがある
- ユーザー名にはメールアドレスがよく使われるため、複数サービスのMFAアカウントが同じlabelを共有する状況は珍しくない
- Google Authenticatorや他の大半の認証アプリは、銀行や自動車会社のようなissuer名も併用して衝突を避ける
- Microsoft Authenticatorはissuerを使わず、ユーザー名だけでアカウントを識別する
- 上書き後は、新しく作成したアカウントと上書きされた既存アカウントの両方で認証上の問題が発生する可能性がある
原因に気づきにくいロックアウト
- ロックアウトが起きると、ユーザーはMicrosoft Authenticatorではなく認証を提供した会社側の問題だと誤解する可能性がある
- その結果、企業のヘルプデスクは自社が引き起こしたわけではない問題の解決に時間を費やすことになる
- どのアカウントが上書きされたのかを簡単に確認するのは難しい
- 既存アカウントが消えた事実は、ユーザーがそのアカウントを再び使おうとする時点まで表面化しないことがある
- その時点は数週間後、あるいは数か月後かもしれない
回避策と長年の不満
- 最も簡単な回避策は、Microsoft Authenticatorの代わりに別の認証アプリを使うことだ
- QRコードスキャンを使わず、Secret Keyを手動入力すれば問題を避けられる
- Microsoftアカウントに属する認証アカウントでは、この問題は発生しないように見える
- CSO Onlineはこの問題に関する苦情を2020年までさかのぼって確認しており、問題自体はMicrosoft Authenticatorがリリースされた2016年6月から存在していたようだ
- 2020年にはあるユーザーがIdentity ProviderのSecret Keyを手動入力する回避策に言及していたが、企業環境の平均的なエンドユーザーがランダム文字列を扱う方法としては助けにならないとみられている
現場で再現された上書き
- オーストラリアのITコンサルタントBrett Randallは、ベンダーのトレーニングセッションで参加者がMicrosoft AuthenticatorでMFA QRコードをスキャンした際、別のアプリケーションのTOTPキーを上書きしてしまう状況を経験した
- Randallによれば、MFA QRコードは複数の値を含む文字列を生成し、他のアプリはlabelとissuerを組み合わせてそのキーの一意なIDを作る
- Microsoft Authenticatorはこの標準的な動作ではなくlabelだけを使っており、そのlabelは通常メールアドレスだ
- 同じメールアドレスを使った最後のTOTPキーが新しいキーで上書きされる可能性がある
- Randallは、Microsoftにこの問題を認識させて対処させるのはほとんど不可能だったと述べている
セキュリティ・IT専門家の反応
- CSO Onlineが複数のセキュリティ・IT専門家に問題の再現を依頼したところ、全員が再現に成功した
- IllumineXのfractional CTO、Gary Longsineはこれを設計上の欠陥とみなし、Microsoft Authenticatorは勧めないと述べた
- Wallarmの製品担当VP、Tim Erlinは、同じメールアドレスを使う2つ目の項目を追加すると衝突が発生し、上書き後にはどのアカウントが上書きされたのか分からなくなると述べた
- Erlinは、ユーザーが原因を把握できない可能性があるため、この問題は実際よりも知られていないのではないかと言及した
- Netographyのchief product officer、David Meltzerは自ら再現したうえで、これは明確なバグでありMicrosoftが比較的簡単に修正できる問題だとみている
- Googleの広報担当Kimberly Samraは、Google Authenticatorはコードを上書きしない、それは明示的な判断によるものだと回答した
Microsoftの見解と警告文
- Microsoftは問題を確認したものの、バグではなく意図された動作だと説明した
- 最初の書面回答では、ユーザーがQRコードをスキャンすると、アカウント設定を上書きし得る操作の前に確認メッセージを受け取ると説明した
- 実際の警告文は “This action will overwrite existing security information for your account. To prevent being locked out of your account, continue only if you initiated this action from a trusted source.” である
- この文言は、ユーザー自身が開始し、信頼できるソースである場合にのみ続行するよう案内している
- 銀行やホテルのような正規サービスで、ユーザー自身がQRスキャンを開始した場合、通常はこの2条件を満たす
- 指示どおりに進めると、アカウント上書きが発生し得る
- 警告ダイアログは、認証の試行自体を取りやめる以外に上書きを避ける手段を提供していない
issuer欠落をめぐる責任の押し付け合い
- Microsoftはその後、より長い2回目の回答で、一部のサイトやベンダーがlabelにissuer、つまりサイト名やIdentity Provider名を含めていないと説明した
- 同じlabelを持つ既存アカウントがある場合、アプリは新たにスキャンしたTOTPアカウントで既存アカウントを上書きしようとする可能性がある
- Microsoftは、このような状況ではユーザーは常に上書き確認メッセージを受け取り、続行するかどうかを選べると述べた
- 「製品改善を継続しており、これを考慮して今後の改善に反映する」という文が、Microsoftがこの問題を修正する可能性を示した唯一の部分だった
他の認証アプリとの比較
- Randallは、エンドユーザーが他のアプリのキーを誤って上書きしないようにする方法は2つあるとみている
- すべてのアプリケーションのotpauthを監査し、各社に誤実装を修正するよう説得する
- Microsoftが一度修正し、その後は同じ心配をしなくて済むようにする
- Randallは14種類の他の認証アプリで同じ衝突動作をテストしたが、Microsoft Authenticatorと同じ動作をするものはなかったと述べた
- テスト対象のアプリには、Google Authenticator、Okta Verify、Duo Mobile、LastPass Authenticator、2FA Authenticator、Twilio Authy、Salesforce Authenticator、OneAuth、ForgeRock Authenticator、Authenticator 7、Authenticator App、Auth0 Guardian、OTP Auth、Authenticator 2FA Sentinelが含まれていた
1件のコメント
Hacker News の意見
使い勝手のないセキュリティという大きな問題を示す小さな例として、本当に腑に落ちる
「セキュリティ」という名目で経験する理不尽なことを考えればいい。強制的な定期パスワード変更、狂ったようなパスワード規則、試行錯誤で突き止めるしかない文書化されていない要件、セキュリティ専門用語だらけの複雑なエラーメッセージ、答えを覚えていない「秘密の質問」などだ
ところが肝心のこうしたシステム自体のセキュリティは、ざるのように穴だらけだ。データ流出や情報漏えいがほぼ毎日のようにニュースになるのに、なぜずっと見過ごされているのか不思議に思うことが多い
何カ月もの間、ログインするたびに「アカウントを探す」を使う必要があり、そのたびにユーザー名をまたメールアドレスに設定していた。ほぼ10年にわたってそれがログイン資格情報だったのだから当然だった
ユーザー名に
@や.を使えないという制限は、ログイン時まで一度も強制されず、結局数カ月たってから別の値に変えなければならないと分かった元のアカウントは ING Direct で、その後 Capital One 360 になり、Capital One のほかの混沌としたシステムに完全に統合されたので、このユーザー名問題もそれに関係していると思う
Webサイト：「特殊文字と数字を含む8文字以上の複雑なパスワードを選んでください」
パスワードマネージャーを開き、128文字のランダムパスワードを生成して満足する
次回訪問時のWebサイト：「パスワードの31文字目、98文字目、102文字目を入力してください」
英国の住宅ローンサイトだった
今考えると、これをやるにはパスワードを平文保存しているか、少なくともハッシュではなく暗号化していて、いつでも復号できるという意味になる
以前のバージョンのアルゴリズムで作ったパスワードだったのかと思って再試行しても失敗する。結局パスワードリセットを押し、メールを受け取ってリンクをクリックし、アルゴリズムで生成したパスワードを新しいパスワードとして入れると「その特殊文字は使えません」と表示される
自分のルールに従ってその特殊文字を次の文字に変えて入れると、今度は「現在のパスワードではリセットできません」と出る
記憶では「単語禁止」「直近24個のパスワード再利用禁止」「一部の特殊文字を除外」「秘密の質問5個」、そのほか複数のパスワード要件があった
秘密の質問が大文字小文字を区別するのかは誰にも分からない
アカウント作成情報が真実で本人であることを認証しなければならず、虚偽または誤解を招く情報を提供すると罰金や禁錮、またはその両方を科される可能性がある、という文言まであった
辞書にある単語を4つ以上使えば優れたパスワードセキュリティが得られるし、秘密の質問の回答にも同じ方法を使える。無料・有料のパスワードマネージャーも多く、すべての秘密値を覚えなければならない問題を解決してくれる。二要素認証のシークレットのバックアップにも向いている
「複雑なエラーメッセージ」が、ユーザーに自力で直すことを期待するエラーなら、むしろ一般的なエラーと固有IDを返してサポートに問い合わせさせればいい。専門用語の爆撃は腹立たしいが、セキュリティ特有の問題というより、エラー説明ができない人間によくある無能さに近いように見える
ほとんどの組織は、事業全体としては成功していても同時に多くのことを台無しにしており、セキュリティもその一つだ。十分に大きな組織なら、無能な人が無能なことをするのは避けにくいと思う
これは複数の層で理解できない。Microsoft Authenticator は項目をラベルだけを基準に保存しているということなのか。内部キーのようなものも作らないのか
そのうえで、Webサイトが発行者を本来あるべき issuer フィールドではなくラベルに入れるのが問題だと主張しているのか
Microsoft で実際に自社の Authenticator を使っている人が誰もいないのか気になる。何か見落としているのでなければ、メールアドレスをあるサイトで使った瞬間に別のサイトには追加できなくなるので、ほぼすべてのアプリケーションで使えなさそうだ
ところが iOS 版には検索欄がある。いったいなぜなのか分からない
巨大な Piper リポジトリの中には、1つの変更リストで差し込めるローカル検索ライブラリが既にありそうだが、それは大規模言語モデルではないのだろう
そしてかなり多くの人は、そもそも使わないだろうと思う
ただし、ユーザーに間違ったコードを見せてしまうUI の問題は見つけた。画面に表示されている最初の数アカウントのコードは30秒ごとに更新されるが、画面外にあるコードは更新されない
スクロールして画面外のコードを表示すると古いコードが見え、あるケースでは正しいコードより4ローテーション遅れたコードが表示された
奇妙なことに、Microsoft からフィッシングのように見えるがそうではなさそうなメールを受け取った。
内容は「対応が必要です: 2024年10月15日までにテナントで多要素認証を有効にしてください」というもので、「グローバル管理者」だから受け取っているとしつつ、組織名はなく UUID だけが書かれていた。
2024年10月15日から Azure ポータル、Microsoft Entra 管理センター、Intune 管理センターへのサインインに MFA が必要になるので、それまでに MFA を有効化せよという案内だった。できない場合は施行日の延期を申請するように、とも書かれていた。
問題は、Microsoft でどの組織も管理していないということだ。個人の Office365 Family アカウントのようなものしかなく、そのアカウントにはすでに 2 段階認証を設定している。
メールには自分の名前も、いわゆる組織名もなく、ID だけだったので、何のことかまったく分からない。それでも Microsoft から来たメールなのは確かだった。
Gmail アカウントを作ったあと、国とコンピュータを変えるうちにいくつか失った。ログインしようとすると、Google はパスワードは正しいがデバイスと IP が見慣れないと言った。
復旧用アドレス経由の復旧がなぜ機能しなかったのか正確には覚えていないが、復旧用メールアドレスにはまだアクセスできたのに失敗した。おそらく Google に復旧用メールアドレスが何かを答える必要があり、私は復旧用アドレスにランダムな
+サフィックスを使っていたのかもしれない。以前は Gmail アカウントに Google Authenticator を使っていたが、Google が特に救済策を用意してくれない状況で、壊れうる要素がもう一つ増えるのが怖くてオフにした。
パスワードは約 96 ビット超のエントロピーを持ち、
/dev/urandomから 256 ビットを取り出して多倍長整数にし、divmodで数字・小文字・大文字・記号からそれぞれ 1 つずつ選び、残りは全文字集合から選んだうえで、余ったエントロピーで Fisher-Yates シャッフルを実行し、先頭文字が常に数字にならないようにしている。サイトごとのパスワードで、2000年代初頭に自作した gpg ベースのパスワードマネージャに保存している。
多要素認証は進行中の能動的な侵害の一部には役立つが、データベース侵害によるパスワードハッシュのダンプには役立たない。パスワードを知っているのに、復旧用メールアドレスで復旧できないのは本当につらい。
数か月間どこからもログインしておらず、正しいパスワードを持っているなら、少なくとも復旧用アドレスを答えさせるのではなく、検証リンクかコードを復旧用アドレスへ送るべきだ。送信先がどこかを明かす必要はないが、復旧用アドレスをもう一つ覚えなければならないパスワードにするのは本当に腹立たしい。
Google には、すでに渡したデータと、どうしても渡さなければならないデータ以上は、もう信用していない。
国際的な移住を予定しているので、深刻な問題が起きる前に、メール生活をテスト中の有料アカウントである Proton Mail へ移すペースを上げる必要がある。
Gmail が無邪気に見えていた頃、行政手続きのオンライン化が始まったときに、税務、医療、公的機関などに Gmail を連絡先として渡し始めた。それがうまく機能し、何度もの国際的な移住を経るうちに、Gmail は重要な行政ツールになった。
あちこちに休眠アカウントもあるが、いつか必要になるかもしれない重要な用件が残っている。たとえば、数年間有効なオーストラリアの渡航許可のようなものだ。
大規模監視が加速したあとも、Gmail はそれなりに無害に見えたし、自分がどの機関とやり取りしているかという事実以外には、本当の秘密や深い個人事情はほとんどなかった。
しかしオンライン行政が事実上必須になり、他の手段が最小限しか残っていない今では、Gmail は不快なほど中心的な存在になっている。自動化されたボットが、疑いを持たないユーザーに対して慈悲も異議申し立てもなく行う不安なことのせいで、移行を始めざるを得なかった。
あまりに広く使ってしまったので全部を探し回る時間が足りず、忘れられたアカウントはかすかな記憶を掘り起こさなければならず、拷問のようだ。それでもやらなければならない。
双子の娘たちが公的な用事にメールを必要とする年齢になったとき、Google ボットの慈悲に委ねられるようにはしたくない。
toフィールドからランダムなサフィックスを突き止められるかもしれない。おそらく管理者に言えばリセットはできるだろうが、個人情報を渡すまでアカウントを事実上人質に取るのはかなり不快だ。
仕事用アカウントのために Microsoft のものを使ってきた。どうせ Office365 に深く組み込まれているので、使わない理由がなかった。
そういうダイアログは見たことがないし、追加したアカウントにも問題はなかった。仕事用アカウントなので、99% はアカウント名として自分の会社メールアドレスを共有している。
つまり、自分が使ったサイトが十分に一意なラベルを提供していて運が良かったということなのだろうか？ 問題が正確に何なのか、完全には理解できていない気がする。
結局、時間は過ぎていくし、これは家族の生活費を稼ぐ仕事ではなく、ログインするために何をすべきか掘り下げるだけの面倒事にすぎないので、以前の職場で強制されていた Microsoft のものを使うことにした。
オンラインアカウントを使うために、意味のあることをする代わりに、こういうものをいじってすでにあまりにも多くの時間を無駄にしている。
オンラインの本人確認全体が深刻に信頼できず、大きな穴とさらに大きなリスクだらけなのに、私たちはその上に生活全体を築いている。
何十年もの間、パスワードの脆弱性で深刻な被害が出てきたのに、いまだにパスワードを使い、絆創膏を貼ったりペンキを塗ったりして取り繕おうとしている。
ほぼ毎週のように、どこかのオンラインシステムが悪用しやすい大量の個人情報を漏らしているのに、私たちは燃えている部屋の真ん中でコーヒーを飲む犬のミームみたいに「大丈夫、大丈夫」と座っている。
すべてのシステムで異なる8文字以上のパスワードを使えば安全だと言いながら、大丈夫だと信じている。
そう期待するなら、Microsoft 製品は自分で発行者をラベルに入れるだろうから問題ないはずだ。
問題は、同じメールアドレスを識別子として使いながら、発行者を保存するためにある issuer フィールドに発行者を入れる別のプロバイダーを使うときに起きる。ずいぶん変わったことをするものだ、という感じだ。
Safari にも似たようなバグがあり、何の警告もなくパスキーを上書きして、アカウントから完全に締め出されるようにした。後に修正されたが、このせいで GitHub へのアクセス権を失った。
https://bugs.webkit.org/show_bug.cgi?id=270553
Safari には今でも、異なるサブドメインにホストされた Web サイトをハードコードされた例外以外では区別できないバグがあり、あるサブドメインのパスワードを別のサブドメインのものとして上書きする。毎月経験している。
だが、こうした愚かさがもっと深いところまで続いているとは思わなかった。
セキュリティ上の脆弱性があっても、SMS 多要素認証がユーザーに人気な理由はまさにこれだ。
通常、SIM スワップ攻撃の標的にされない限り十分に問題ない。大半の人は標的にはならないが、多要素認証キーを失う問題に遭う可能性はかなり高い。
YubiKey のようなより安全な方式が一般大衆に広まらなかった理由もこれだ。面倒で分かりにくい。
今は単にランダム生成パスワードに頼っている。
どこかにログインする必要があれば、財布からカードを取り出して携帯電話やノート PC にかざす方式だ。
有料顧客がいる会社なら、代替認証方式をサポートするより、顧客がカードを持っていないときに物理的に郵送するほうが合理的なくらい、十分に安くあるべきだ。
ほとんどのサービスには、第二の認証レイヤーすら必要ないかもしれない。誰かが財布を盗んだからといって、本当に Reddit アカウントまで気にするだろうか、という話だ。
試してみたが、同じアカウント名・メールアドレスを使う複数のアカウント間で衝突はなかった。
各項目には発行者アイコンも正しく表示され、発行者が各項目に登録されている。
MS Authenticator を何年も使っているが、この種の問題に遭ったことはなく、当然ながらアカウント名やユーザー名にはいつも同じメールアドレスを使っている。
単にテスト結果を書いているだけだ。これで Authenticator や Microsoft に対する考えが変わるとは思わないが。
しばらく更新していなかったあとで MS Authenticator を更新したとき、自分にもこれが起きた。
すべてのデータが消え、すべてのアカウントから締め出された。MS Authenticator は慎重に作られた製品ではない。
約1年前、Google Authenticator アプリが新バージョンに自動更新されたとき、似たようなことがあった。
更新の過程ですべてのアカウントを失い、確かにいくつか教訓を得た。