Bitwardenにパスワード窃取という不可解な「ユースケース」

パスワード管理ソリューションは、アカウントへのアクセスを侵害されないようにするために推奨されることの1つです。パスワード管理ツールは、多数のアカウント認証情報を安全に保存し、ユーザーにはパスワード1つを覚えてもらうだけで良しとする（または、生体認証でロック解除するよう設定される）という考えのもとで作られています。

パスワード管理ツールには、複雑なパスワードを生成する、複数のデバイス間で同期する、拡張機能としてブラウザ内に統合する、などの多くの機能が備わっていることがあります。最後に挙げた機能は、たった数回のクリックでWebアカウントに快適にログインすることを可能にします。この機能を提供するブラウザ拡張機能は当然ながら、保存されたユーザー認証情報をどこに入力するかを認識している必要があります。認証情報は、本物と証明されたログインフォームに入力され、それ以外のどこにも入力されてはなりません。

ところで、物事は常に簡単とは限らず、時には妙なWebデザインが特別な扱いを求めることがあります。Flashpointの脆弱性調査チームは、人気のパスワード管理ブラウザ拡張機能であるBitwardenの挙動を評価した際、Webページに埋め込まれたiframeが通常と異なる方法で扱われていることに気づきました。これがどうして問題なのかを理解するには、iframeとは何なのかの基本を理解することが重要です。

*本記事は、弊社マキナレコードが提携する米Flashpoint社のブログ記事（2023年3月7日付）を翻訳したものです。

インラインフレームという要素

MozillaのHTMLに関する資料によると、HTML要素の <iframe>は、入れ子式のブラウジングコンテンツを表し、表示されているページの中に別のHTMLページを埋め込みます。

よくあるユースケース例は、地図データをWebアプリケーションの中に埋め込むことです。ただし、iframe要素のブラウジングコンテンツは、親ページや、オリジン（生成元）の異なる別ページのコンテキストからは隔離されます。これを定義するのが、ドメインを越えての任意のアクセスを防止するSame-origin Policy（同一生成元ポリシー、SOP）です。これは、重要なセキュリティ上の概念とされ、全ての主要ブラウザに実装されています。

同一生成元ポリシーを視覚的に表現したもの

この隔離は非常に重要です。というのも、Webページが別のオリジンからの秘密のWebリソースをiframeに埋め込み、そのコンテンツにアクセスしたりするのを防ぐためです。

Bitwardenの自動入力の挙動

先述のように、Bitwardenのブラウザ拡張機能によるiframeの扱い方は興味深く、詳細に見るべき理由が十分ありました。Bitwardenの拡張機能は、ユーザーの認証情報が保存されたページ上にいると判断すると、各ログインフィールドを埋める提案をすることができます。「Auto-fill on page load（ページロード時に自動入力する）」というオプションが有効であれば、拡張機能はそれをユーザーの操作なしに行います。

ただ興味深いことに、この拡張機能は、埋め込まれたiframe内に定義されたフォームにも（たとえフォームが異なるドメインを起源とする場合でも）自動入力します。

埋め込まれたiframeは、親ページにあるどのコンテンツにもアクセスしないものの、ログインフォームへの入力を待って、入力された認証情報をユーザーによる追加の操作なしに遠隔のサーバーに転送することがあります。

Bitwardenの資料には、「侵害された、または信頼されていないWebサイト」がこれを悪用して認証情報を盗む可能性があるとの警告が記されています。

Webサイト自体が侵害されている場合、認証情報の窃取を防ぐために拡張機能にできることはほぼ皆無です。一方で、周知の通り、広告などの様々な理由から外部のiframeを埋め込む、通常の（侵害されていない）Webサイトは複数存在します。よって、攻撃者はWebサイト自体を侵害する必要は必ずしもなく、iframeのコンテンツを掌握するだけで良いということになります。

私たちは少数の主要Webサイトを選んで検査し、ログインページ上のどこにiframeに埋め込まれているかを調べましたが、まさにこの設定にマッチすると判明した事例の数は非常に少数であったため、潜在的なリスクは低いです。しかし私たちは、この脆弱性を実証するProof-of-Concept（概念実証、PoC）を構築した際に、Bitwardenの拡張機能が認証情報を入力するページを決定する方法に、もう1つの弱点があることに気づきました。

BitwardenのデフォルトURIマッチング

デフォルトURIマッチングとは、ブラウザ拡張機能がどうやって自動入力ログインを提案すると決めるかを定義する設定のことです。これは、表示されているページのURIの一部を、拡張機能の保管庫内の保存済みアイテムにおけるWebサイトエントリと比較することで行われます。デフォルトの設定は「ベースドメイン」になっています。つまり拡張機能は、ベースドメイン（つまり、トップレベルおよびセカンドレベルドメイン）がマッチするページであればどこでも、自動入力機能を提供するということです。

Webソリューションやコンテンツプロバイダーを十分に見てきた方からすれば、これが問題であることは明らかです。コンテンツホスティングプロバイダーの中には、プロバイダーの公式ドメイン（プロバイダーのログインページをも提供する）のサブドメイン下に、任意のコンテンツをホスティングすることを許すものもあります。例えば、ある企業がログインページをhttps://logins.company.tldに設置し、ユーザーにhttps://<clientname>.company.tldの下でコンテンツを提供するのを許している場合、これらのユーザーはBitwardenの拡張機能から認証情報を盗むことができます。

想定される攻撃手法

安全でない自動入力の挙動とデフォルトURIマッチングを組み合わせることで、以下のような、認証情報を盗む様々な攻撃が可能になります。

・侵害されていないWebサイトが攻撃者の管理下にある外部iframe（サンドボックス化されていない）を埋め込み、「Auto-fill on page load」オプションが有効になっている。

・攻撃者が特別に細工されたWebページをホスティングプロバイダーなどのサブドメイン下にホストし、このプロバイダーはログインフォームを同一のベースドメイン下に設置している。

私たちは調査において、少数の主要Webサイトがまさにこの環境を提供していることを確認しました。Bitwardenのブラウザ拡張機能を持つユーザーが、これらのWebサービス内にホストされた特別に細工されたページを訪問した場合、攻撃者は各ドメインに関連する保存された認証情報を盗むことができます。

先述の通り、「Auto-fill on page load」オプションが有効な場合、追加のユーザーによる操作は不要です。ただ私たちは、ユーザーがコンテキストメニューを使ってログインフォームを埋めた場合に、iframe内に埋め込まれたフォームも入力されることを確認しました。

例1 ：「Auto-fill on page load」（PoC）

例2：コンテキストメニューによる自動入力（PoC）

不可解なベンダーの回答

私たちはBitwardenに連絡し、協調的な公表を試みました。驚いたことに、ベンダーはこの問題をよく認識している模様でした。私たちは2018年11月8日付のセキュリティ評価レポートへのリンク付きで回答を受け取りました。このレポートはiframeハンドリングに関する脆弱性（BWN-01-001）を説明しています。「ユーザーは、別のドメインからの埋め込みiframeが存在する場合にサービスにログインできることが望ましい」ため、この問題は修正されませんでした。つまり、この脆弱性は4年以上の間、記録済みかつ公表済みだったと考えることができるのです。

私たちは、漏洩認証情報が攻撃者によるアクセス権獲得の第一ステージとして重要であることを踏まえ、ベンダーが2018年に行った評価は間違っていると考えます。Bitwardenによる結論の見直しにつながることを期待し、私たちはこれが悪用され得る方法を実証する2つの例を作成、提供しました。また、説明されたユースケースを、最初のレポートに含まれなかった実証済みの攻撃を踏まえて評価し直すべきである理由についても明らかにしました。1つの例は一般的なPoCであり、もう1つは主要なホスティング環境における機能するエクスプロイトでした。このエクスプロイトは、攻撃者によるアカウント認証情報の開示を可能にした後、そのプラットフォーム上の全サービスへのアクセスを許可します。

Bitwardenは回答の中で、iframesがこの方法で扱われる必要のある理由に関するユースケースを提供しました。一方で、報告されたホスティング環境を自動入力機能から除外することを計画する一方で、一般的なiframesの機能を変更する計画はありません。つまり、根本原因には手がつけられておらず、1つの攻撃手法にだけ手がつけられているということです。セキュリティや私たちのレポートへの回答より、自らのユースケースを優先することは憂慮されることであり、組織は同製品におけるセキュリティ上の懸念を認識した方が良いでしょう。また、他のパスワード管理拡張機能を簡易的に評価した結果、これらの中に別のオリジンからのiframeを自動入力したり、別のオリジンからのiframeについて警告を表示したりするものはありませんでした。これは現在のところ、Bitwardenの製品に固有のものである模様です。

脆弱性の修正をFlashpointで

無料トライアルにご登録いただくことで、この問題のほか、CVEとNVDで見つからない9万7千件の脆弱性について深く知ることができます。

VulnDBのお客様には、この脆弱性（VulnDB ID 313593）に関するより詳しい記事を提供しています。私たちは、脆弱な拡張機能を用いる全ての方に対し、「Auto-fill on page load」機能を無効化することと、「デフォルトURIマッチング検知」の設定を「Host」または「Exact」に設定することを推奨します。これは、ホスティングプロバイダのサブドメインを通じた攻撃を緩和するものです。ただし、Webアプリケーションが攻撃者の管理下にある恐れのあるiframeをログインページに埋め込んでいる場合の認証情報の開示を防ぐものではない点にご注意ください。

※日本でのFlashpointに関するお問い合わせは、弊社マキナレコードにて承っております。

また、マキナレコードではFlashpointの運用をお客様に代わって行う「マネージドインテリジェンスサービス（MIS）」も提供しております。

詳しくは以下のフォームからお問い合わせください。