フィッシングページは、本物のページだった

共有ドキュメント、警告されたサインイン、請求書 ― そんなメッセージが 届きます。あなたはクリックします。Microsoftのログインページが開き、 それは本物です。正しいフォント、正しいロゴ、フィールド間をタブで 移動したときの小さなアニメーション、あなたのスマートフォンを震わせる 本物の多要素認証プロンプト。あなたはそれを承認します。ログイン完了 です。何もおかしく感じませんでした。実際、ほとんど何もおかしく なかったからです。あなたが入力したページは、Microsoftのログイン ページでした。ただ、それと対話していたのは、あなたではなかった のです。

6月下旬、NetcraftのHarry Everettは、Bluekitと呼ばれるフィッシング キットがこの飛躍を遂げたことを 記録し、 BleepingComputerも同じ週に 報じました。 Bluekitはサービスとして販売されています。Outlook、Gmail、iCloud、 GitHub、そして一つや二つの暗号資産ウォレット向けのテンプレートを 備えたホスト型フィッシングキットに、おとりメールを書くための 組み込みアシスタントが付くのです。その新しい手口には、ある名前が ついています。mr.d0xとして知られる研究者が2022年に記述して以来、 ずっと取り沙汰されてきた名前 ― browser-in-the-middleです。

本物のページが、あなたへ配信される。

旧来のフィッシングは、偽物を作ります。誰かがログインページを複製し、 よく似たドメイン上にホストし、あなたがアドレスバーを見ないことを 期待します。守りはそれを軸に育ちました。偽物を見破り、URLの タイプミスを捕まえる、というものです。

次に登場したのが、Evilginxのようなリバースプロキシ型のキットです。 これはページを複製しません。接続の途中に座り ―「adversary in the middle」として ― あなたのトラフィックを本物のサイトへ通過させながら、 流れていくセッションクッキーをすくい取ります。（このクッキーとは、 ログイン後にサイトがあなたのブラウザへ手渡す小さなトークンで、これに よってクリックのたびにパスワードを尋ねられずに済みます。）これを盗む ことで、大半の多要素認証ログインが破られます。攻撃者はパスワードでは なく、完了したログインの証を手にするからです。

browser-in-the-middleは、もっと奇妙で、ある意味でもっと単純です。 攻撃者は自分のサーバー上で実際のブラウザを動かし、それを本物の ログインページに向けます。ユーザーセッションの再生のために作られた rrwebというオープンソースのライブラリが、その生きたページを シリアライズし、WebSocket ― あなたのブラウザと攻撃者のブラウザの あいだの永続的な双方向チャネル ― を通じてあなたへ配信します。あなたの ブラウザは、まるで自分で読み込んだかのように本物のページの構造を 描画します。あなたが見ているのは、スクリーンショットでも動画でも ありません。あなたは、本物の店内に置かれたブラウザを遠隔操作して いるのであり、あなたのキー入力、マウス、そして多要素認証の承認は、 そのブラウザへと中継されます。ログインが完了するとき、それは攻撃者 のブラウザの中で完了し、攻撃者のサーバーがセッショントークンを 発行します。最初の一秒から、あなたのセッションは彼らのものだった のです。

なぜそこまで手をかけるのか。クローンには決してできないやり方で、人を 納得させるからです。間違えようのある偽ページが存在しません。そして 攻撃者が本物のサイトとやり取りするのに一貫した一つのブラウザを使う ため、ログインは、リバースプロキシ型のキットを時に露呈させる フィンガープリント不一致の警報（あなたの端末とプロキシのあいだの 小さな食い違い）を作動させません。Netcraftは、わずか一週間でおよそ 七十もの真新しいBluekitのホスト名を数えました。これは、一つの製品の 生産物です。

これを止められないもの。

悪い知らせから始めましょう。たくさんあるからです。

多要素認証は、その一般的な形では、これを止めません。ワンタイム コードもプッシュ承認も、同じこと ― いま、まさにログインが起きて いること ― を証明しますが、この攻撃はそのログインが起きることを 必要としています。サインインしているのは攻撃者だからです。証明する のはあなた。セッションを得るのは彼らです。

より新しいセッション堅牢化は、期待するほどには助けになりません。 Netcraftは、セッションクッキーを発行された端末に結びつける仕組みで あるDevice Bound Session Credentialsについて、「Adversary-in-the-Middle に対してはある程度の保護を提供するが、Browser-in-the-Middleに対しては 保護できない」と述べています。セッションは攻撃者の端末で生を受ける ため、それをその端末に結びつけることは、あなたではなく攻撃者を守る ことになります。ログイン後に取り付けられたものはすべて、手遅れで 到着します。その時点ではもう、攻撃者が正当な権利としてセッションを 握っているからです。

アイソレーションもまた、これを止めません。そしてそれは、はっきり 言っておく価値があります。私たちのブラウザのように、あらゆるタブを 使い捨ての仮想マシンで動かすブラウザは、ページがあなたの コンピュータに対してできることを封じ込めます。browser-in-the-middle は、あなたのコンピュータには何もしません。それは一度のログインの ためにあなたの手を借り、その結果を、あなたが決して目にすることの ないサーバーに保管します。あなたはタブを閉じた瞬間に、自分の セッションを捨てることができます。けれど、本当に問題となる複製は、 初めからあなたの側になく、捨てようがありません。使い捨て性は、長い リストに並ぶ攻撃から身を守ってくれますが、browser-in-the-middleは そのリストには載っていません。

これを止められるもの。

より優れた偽ページ検出器も、ここでは役に立ちません。偽ページが 存在しないからです。解決策は、攻撃者が書き写すことのできない資格 情報です。

パスワードとワンタイムコードは、一つの致命的な性質を共有しています。 どちらも文字列だということです。あなたが配信されたページに文字列を 打ち込むと、回線がそれを運び、向こう側のブラウザがそれを再生します。 それがビジネスモデルのすべてです。

パスキーは、あなたの端末上に存在し、決してそこを離れない秘密鍵です。 サインインとは、あなたがTouch IDで承認したあと、あなたのMacが ワンタイムのチャレンジに署名することを意味し、Macが返す署名は、 あなたがそのパスキーを作った当のウェブサイトに結びついています。 ここから二つの帰結が導かれ、そのどちらもがbrowser-in-the-middleを 破ります。

第一に、打ち込むものが何もないため、中継するものも何もありません。 秘密は決してページに現れず、決してWebSocketを渡らず、rrwebが 配信し返すためのフォーム項目に決して収まりません。攻撃者のブラウザは 好きなだけ要求できますが、署名が行われるのは、攻撃者のサーバーが 到達できない、あなたのMacの中のチップ上なのです。

第二に、あなたの本物の銀行のためのパスキーは、その本物の銀行の ドメインに登録されています。攻撃者のホストが目の前のページを配信 するとき、あなたのMacはそこに存在しないパスキーを探し、何も差し 出しません。本来なら一度のタップで済むサインインが、起こらないのです。 その沈黙 ― 決して発火しない自動入力と、一覧に並ばないパスキー ― こそが、かつて偽のアドレスバーがあなたに与えてくれ、もはや与えられ なくなった警告なのです。

Macの資格情報を貸す、二つの方法。

ここではブラウザの設計が効いてきます。パスキーは、あなたがログイン する場所まで届いてはじめて、あなたを守るからです。

Bromureは、各ブラウジングセッションを、あなたのMac上の使い捨ての Linux仮想マシン ― ウィンドウを閉じると消去する、独立した小さな コンピュータ ― の中で動かします。これは敵対的なページをよく封じ 込めますが、一つの明らかな問いを呼びます。ブラウザが使い捨ての マシンの中に存在するなら、あなたの保存済みのログインはどこから来る のか? Bromureは、プロファイルごとに選ばせ、その選択を意図的に 二つのスイッチに分けています。

それらを分けていることこそが要点です。キーチェーン全体をセッションに 共有するのが便利な既定値であり、パスキーだけを共有するのが、この 記事で扱う攻撃に免疫を持つ選択肢です。パスキー限定には専用のスイッチが 用意されているので、フィッシング耐性のある選択は、セキュリティ プロジェクトではなく、一つのトグルで手に入ります。あなたは、認証の 手段をちょうど一つだけ ― あなたの画面から配信され得ない手段だけ ― に絞ったプロファイルを運用できるのです。

これが解決しないこと。

トグルは万能の盾ではなく、その限界は見過ごせません。

いちばん大きな点は、繰り返す価値があります。あなたが browser-in-the-middleのページを通じてパスワードでログインすれば ― たとえその後ろにワンタイムコードやプッシュがあっても ― 攻撃者は機能 するセッションを手にし、使い捨てのVMも巧妙なブラウザも、それを取り 返してはくれません。パスキー限定の共有が守るのは、あなたがパスキーを 使うログインだけであり、それ以外は守りません。いまだ多くのサイトが パスキーを提供しておらず、それらに対しては、古い助言だけが唯一の助言 です。メッセージのログインリンクをたどらず、自分でサイトを開くこと。

検知は役に立ち、Bromureはそれを使っています。既知の悪意あるドメインを ブロックするフィルタ付きDNSと、あなたが行動する前にページのURLと フォーム構造を採点するAIフィッシングチェックです。どちらも確率を 狭めます。どちらも保証ではなく、browser-in-the-middleは検知を難しく するように設計されています。週に七十もの真新しいホスト名は、大半の ブロックリストを振り切り、コンテンツスキャナーが見つけて警告すべき 偽ページもありません。検知は、不注意な攻撃者を捕らえます。フィッシング 耐性のある資格情報は、注意深い攻撃者を捕らえます。

そして、何より当たり前の限界。人は、多くのことを言いくるめられて しまいます。説得力のあるメッセージがあなたをパスキーのないサイトへ 連れていき、あなたがどこか別の場所で使い回したパスワードを打ち込めば、 そのループの中にブラウザの設定は初めから存在しません。パスキー限定の 共有は、あなたを無敵にはしません。けれど、もっとも重要なログイン ― あなたのメール、コードホスト、IDプロバイダ ― については、攻撃者が 狙ってやって来た文字列を取り除き、彼らが手の届かない鍵を残すのです。

偽のアドレスバーは、引退しつつある。

私たちが二十年にわたり繰り返してきた助言 ― URLを確認し、鍵マークを 探し、ページを疑え ― は、攻撃者が何かを偽造しなければならないことを 前提にしていました。browser-in-the-middleは、何も偽造しません。本物 そのものをあなたに手渡し、その後ろで袋を広げて待ち構えているのです。

率直な結論。セキュリティ第一のブラウザも、これに対する免疫をあなたに 与えはしません。私たちは、そうでないふりをするより、そう認めるほうを 選びます。答えは、あなたの目から、あなたの資格情報へと移りました。 本物と見分けのつかないページに対して、長持ちする守りは、書き写すことの できない何か ― あなたのMacで署名され、本物のドメインに結びつき、 攻撃者のドメインには決して差し出されないパスキー ― でサインインする ことです。Bromureの担う部分は、小さく、具体的です。プロファイルに パスキーだけを共有させ、それ以外は共有させないことで、それを簡単な 既定値にします。Bromureをインストールし、失うわけにいかない アカウントについてパスキー限定をオンにして、次の完璧に見えるログイン ページに、あなたがもう渡さずに済む秘密を求めさせてやりましょう。