パスワードマネージャーの自動補完の脆弱性と拡張機能のマルウェアリスクを調べてみた
最近、パスワードマネージャーの自動補完機能に潜むセキュリティリスクについてのニュースを見ました。Koi SecurityのRedDirection調査（2025年7月公開）でも、ChromeやEdgeの拡張機能にマルウェアが仕込まれていた事例が話題になりましたが、この件も拡張機能に関連してるようです。勉強した内容として、自動補完の脆弱性の仕組み、拡張機能のマルウェアリスク、対策についてまとめました。
学んだポイント：
- 自動補完が攻撃に悪用される原因
- 拡張機能のマルウェア（RedDirection調査の事例）
- ユーザー、開発者、企業それぞれの対策
- 関連する攻撃手法（サブドメイン窃取やサイト改竄）
自動補完の脆弱性の仕組み
パスワードマネージャーの自動補完が攻撃に悪用される主な原因は、悪意あるDOM要素の挿入です。以下がその仕組み：
- 攻撃者が悪意あるブラウザ拡張機能を配布。ユーザーがインストールすると、Webページに偽のフォーム（例:
<input type="text" autocomplete="username">）が挿入される。 - パスワードマネージャーは、HTMLのinputタグを基に認証情報を自動入力するが、偽フォームを正規のものと誤認する。
- 入力された認証情報は攻撃者のサーバーに送信される。
DOM操作を利用してパスワードマネージャーの挙動を悪用するんですね。
拡張機能のマルウェア：RedDirection調査
Koi SecurityのRedDirection調査では、18個のChromeおよびEdge拡張機能がマルウェアを含み、230万人以上に影響を与えたことが報告されました。これらの拡張機能（例: 「Color Picker, Eyedropper — Geco colorpick」など）は、公開時は無害でしたが、その後のアップデートで悪意あるコードが追加されている点が特に悪質です。
パスワードマネージャーの脆弱性と直接の関連はないけれど、拡張機能機能にひそむマルウェアとしては共通ですね。
関連する攻撃パターン
拡張機能以外にも、類似のリスクがあります。
-
サブドメイン窃取とサイト改竄
攻撃者がDNS設定の改竄、または正規のサブドメインの期限切れDNSレコードを悪用し、正規のサブドメイン（例: login.example.com）に偽ログインページを設置。
→パスワードマネージャーが正規サイトと誤認する。 -
正規サイトの改竄
Webサイトの脆弱性を突いて悪意あるスクリプトを埋め込み、DOM操作で偽フォームを追加。
これらは、DOMやページの信頼性を悪用する点で、拡張機能の攻撃と共通しています。
対策
脆弱性への対策を、ユーザー、開発者、企業それぞれの視点で整理しました。
ユーザー側の対策
-
拡張機能の選定
Chrome WebストアやEdge Add-onsで、開発者情報やレビューを確認。信頼できない拡張機能はインストールしない。RedDirectionの事例では、検証済みバッジを悪用したケースもあった。 -
自動補完の設定
パスワードマネージャーの自動補完を手動トリガーに変更し、すべてのフォームでの自動入力を避ける。 -
サイトの確認
URLをチェックし、偽サブドメインや改竄ページにアクセスしない。HTTPSでも偽サイトの可能性を考慮。 -
マルウェアスキャン
定期的にシステムをスキャンし、怪しい拡張機能の影響を排除。
パスワードマネージャー開発者側の対策
-
DOM構造の検証
ページのDOMツリーを保存し、入力時に変更を検知。不自然なinput要素があれば警告。 -
フォームの透明性チェック
偽フォームがopacity: 0やdisplay: noneで隠されるケースに対応。入力先が非表示なら入力を停止。 -
コンテキスト判定
URLや証明書情報を厳密にチェックし、正規サイトか検証。
企業側の対策
-
DNSSECの導入
DNS改竄を防ぐプロトコルを有効化。 -
DNSレコードの監査
不正なサブドメイン作成を防ぐため、定期的に確認。 -
セキュリティ管理
DNS管理の委託先を含め、セキュリティ意識を徹底。
学んだこと
この勉強を通じて、パスワードマネージャーの自動補完がDOM操作に依存しているため、拡張機能やサイト改竄によるリスクが大きいとわかりました。RedDirection調査では、拡張機能のアップデートでマルウェアが仕込まれる手口が巧妙で、信頼性の判断が難しいです。DNS管理の重要性も、ユーザー側のリスク軽減に直結する点で新たな気づきでした。
まとめ
パスワードマネージャーの自動補完脆弱性は、DOM操作や偽サイトを利用した攻撃が原因です。RedDirection調査の拡張機能マルウェアは、類似のリスクを示しています。ユーザー側は拡張機能の選定や設定変更、開発者はDOM検証や透明性チェック、企業はDNS管理を強化することで対策可能だと思われます。
Discussion