Microsoft Edgeは未使用時でもすべてのパスワードを平文でメモリに保存する

• Microsoft Edgeは保存されたパスワードを起動時にすべて復号し、その認証情報をプロセスメモリ上に平文のまま常駐させる
• ユーザーがその認証情報を使うサイトを訪れていなくても、この動作は発生する
• EdgeのPassword Manager UIは同じパスワードを表示する前に再認証を要求するが、ブラウザープロセスはすでにすべてのパスワードを平文で保持している
• テストしたChromiumベースのブラウザーの中ではEdgeだけがこの方式で動作しており、Chromeは保存済みパスワードを単にプロセスメモリから読み取って抽出することがより難しい設計になっている
• Chromeは認証情報が必要なときにだけ復号し、App-Bound Encryption(ABE) によって復号を認証済みのChromeプロセスに結び付け、他のプロセスがChromeの暗号化キーを再利用できないようにする
• この制御により、平文パスワードは自動入力時やユーザーが直接表示するときにだけ短時間現れ、広範なメモリスクレイピングの効果が低くなる

リスクシナリオと公開状況

• 共有環境では、平文パスワードをメモリに保持するリスクが大きくなる
• 攻撃者がターミナルサーバーで管理者権限を取得すると、ログイン中のすべてのユーザープロセスのメモリにアクセスできる
• デモでは、管理者権限のあるユーザーアカウントを乗っ取った攻撃者が、Edgeを実行中の別の2人のログインユーザー、または接続が切断されたユーザーの保存済み認証情報を閲覧できた
• この動作はMicrosoftに報告されており、公式回答はこの動作が「by design」だというものだった
• ユーザーと組織が認証情報の管理方法を判断できるよう、責任ある公開として共有する方針をMicrosoftに伝えた
• 4月29日水曜日、Palo Alto Networks NorwayのBigBiteOfTechでこの内容を公開し、パスワードがメモリに平文で保存されているかを簡単に確認できるシンプルなツールを実演した
• 概念実証ツールはGitHubで公開されており、C#とGitHubでの配布経験があまりないためフィードバックを求めている: EdgeSavedPasswordsDumper

[GN⁺]

Hacker Newsの意見

• これはすでに気密ハッチの向こう側に入り込まれている状況に近い。任意のプロセスメモリを読めるなら、そのユーザーになりすましてパスワードをそのままダンプできる位置にいる可能性が高い。
  攻撃者がターミナルサーバーの管理者権限を得れば、ログイン中の全ユーザーのプロセスメモリにアクセスできるし、管理者権限があればすべてのChromeプロセスにデバッガを付けてパスワード復号を強制することもできる。
  実際の違いはコールドブート攻撃くらいだが、それですら攻撃を少し容易にするだけなのか、それとも本来不可能な攻撃を可能にするのかは不明だ。
  [1] https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
  • この理屈はChromiumの脅威モデルと完全に一致している。攻撃者が管理者権限を得た時点で、定義上ゲームオーバーだ。
    Edge固有の問題である可能性は低そうで、Microsoftが上流プロジェクトよりブラウザを安全でなくする理由もない。
    Chromeは物理的にローカルな攻撃を脅威モデルの外に置いており、ユーザーが自分のデバイスに自分としてログインしているか、自分のOSユーザー権限でソフトウェアを実行できるなら、Chromeであれ他のアプリであれ防御する方法はないと考えている。
    そのような攻撃者は実行ファイルやDLLの改変、PATHのような環境変数の変更、設定ファイルの変更、ユーザーアカウントデータの読み取りと外部送信まで可能なので、Chromeが提供できる実質的な防御保証はないという立場だ。
    https://chromium.googlesource.com/chromium/src/+/148.0.7778....
  • ここ数年では、一般ユーザー権限だけで任意メモリ読み取りが可能だったブラウザ脆弱性もあった。ただし低速だったり、位置制御が完全ではなかったりした。使用直後に資格情報をできるだけ早く消すのは、堀をもう一本増やす程度だとしても、かなり合理的な予防策だと思う。
  • セキュリティは白黒ではない。ログイン情報を書いた付箋をモニターに貼っておくのは、鍵のかかっていない引き出しに入れておくより明らかに危険である、というように段階がある。
  • ユーザーの立場では、パスワードを貼り付けようとするたびにまず生体認証でログインしなければならないのに、どのユーザープロセスでもメモリからパスワードを釣り上げられるということか？
    何を見落としているのかわからない。
  • Cloudbleedのことをもう忘れたのか？
    [0] https://en.wikipedia.org/wiki/Cloudbleed
• 参考までに、GoogleはChromeがメモリ内のパスワードを暗号化して保存し、他のプロセスがChromeになりすまして平文パスワードにアクセスできないよう昇格サービスを使っていると説明している: https://security.googleblog.com/2024/07/improving-security-o...
• はっきり言えば、あり得る攻撃経路の1つは、コンピューターをロックせずに5分ほどトイレに行っている間に、悪意あるハッカーが戻る前にすべてのパスワードをダンプするというものだ。
  これは考慮する価値があると思う。パスワードマネージャーが10分後にマスターパスワードやパスキーを再度要求するのには理由がある。
  Chromeが暗号化されたセキュア領域に依存していると思っていたので、root権限があってもパスワードを簡単に抽出するのはかなり難しいと考えていた。
  もちろんコンピューターを放置すべきではない。しかし、避けられないミスを致命的に悪用しやすいように製品を設計してよい、という意味にはならない。
• このツールは同じマシン上で実行中のEdgeインスタンスにアクセスするのか？ それなら保存済みパスワードをそのままエクスポートすればいいのではないか？
  https://support.microsoft.com/en-us/topic/export-passwords-i...
  • パスワードマネージャーは、メモリ内のパスワードを安全に保つためにかなり多くの工夫をしていることが多いが、そうしたツールの攻撃モデルが十分理解されていないことも多い。
    たとえばKeePassのようなツールはブラウザプラグインの登録にかなり気を使うが、一般ユーザー権限しかなくても、ブラウザからそのキーを抜き取って何でもできてしまう。
    Webアプリの「このブラウザを信頼する」のような仕組みも、クッキーストレージを簡単に読めるなら奇妙に感じる。
• LinuxのPAMでも似たようなことができそうだ。gdbをopensshやgettyのログインプロセスにアタッチすればよい。
• この .exe のソースコードへのリンクはあるのか？ どうやって抽出しているのか見てみたい。
• 本当の失敗は、いまだに単純なパスワード認証を使っていることだ。チャレンジレスポンスや公開鍵認証を使うべきだ。
• 公平に言えば、メモリにロードすることと保存することは同じではない。
  • タイトルには「メモリに保存」とあるが、私にはほぼ同じことのように聞こえる。メモリに「ロード」することと「保存」することの違いをどう見ているのか説明してもらえるか？
• 間違っていたら訂正してほしいが、ChromeもWindowsでパスワードを生テキストで保持していた、少なくとも以前はそうだったと思う。2021年版のChromeで、友人が忘れたパスワードを取り出したことがある。
  • 数年前のことだが、Googleの開発者たちが、ローカルファイルシステムにアクセスできるならすでに終わりだと言って議論していたのを見た記憶がある。
  • Chromeは2024年にクッキーファイルへアプリバインディング暗号化を追加した。