fkasler/cuddlephishペネトレーションテスター向けの武器化されたBrowser-in-the-Middle (BitM)
ペネトレーションテスター向けの、多ユーザー対応ブラウザ・イン・ザ・ミドル（BitM）攻撃ツールです。この攻撃は、多くの高価値ウェブアプリケーションで多要素認証をバイパスするために使用できます。セッショントークンを使用しないアプリケーションでも機能するため、従来のトークン窃取攻撃では悪用できなかったアプリケーションにも対応します。これはソーシャルエンジニアリングツールであり、ターゲットサービスの技術的な欠陥を悪用するものではありません。
このツールは専用のウェブサーバーです。Debian 11（Bullseye）Linuxサーバー上で動作するように設計されており、管理機能を保護するためにパブリックIP情報に依存しています。ローカルでテストするにはかなりの手間が必要になることを想定してください。
警告：ChromiumはARMではサポートされていません。技術的にはARM用のChromiumバイナリを強制的に使用することは可能ですが、puppeteer-extraの追加機能や保護機能はすべて失われます。
このセットアップ例では、Caddyを使用してTLS、SNIを処理し、各リクエストに'X-Real-IP'などのカスタムヘッダーを追加しています。CuddlephishでCaddyを使用する必要はなく、NginxやApacheなどでも同じリバースプロキシを設定できます。Dockerで簡単にインストールでき、ほとんどのドメインレジストラ向けにLetsencrypt証明書を管理するプラグインがあるため、私はCaddyが好きです。サンプルのCaddyfileは、Gandi用の設定方法を示しています。お使いのレジストラのドキュメントを確認してください。
Docker、Node、XVFB、およびその他の依存関係をインストールします：
git clone https://github.com/fkasler/cuddlephish
cd cuddlephish
sudo bash install_deps.sh
その後、Dockerを使用して、お使いのレジストラ用のワイルドカード証明書プラグインを備えたCaddyをビルドできます。例はGandi用です。ドキュメントはこちらで、DNSプロバイダーモジュールのリストはこちらで確認できます。ビルド前に、Dockerfileをお使いのレジストラ用に変更できます：
sudo docker build -t caddy .
次に、Caddyfileを編集してドメインとGandi（または他のレジストラ）のAPIキーを置き換え、Caddyを起動します。screenまたはtmuxウィンドウで起動し、後で別のウィンドウでNodeサーバーを実行できるようにすることをお勧めします：
sudo docker run -p 80:80 -p 443:443 -p 2019:2019 -v $PWD/Caddyfile:/etc/caddy/Caddyfile --network=host caddy:latest
Caddyが80番と443番ポートでトラフィックを処理しているので、いよいよツールを実行できます！
Nodeの依存関係をインストールします：
npm install
いくつかの設定調整： 重要な手順：サンプルのconfig.jsonを変更して、管理者アクセス用の承認済みパブリックIPを追加してください。このIPのホワイトリストが、「/admin」ウェブインターフェースへのアクセスを制御します。また、デフォルトのソケットキーをより安全なものに変更する必要があります。
デフォルトではログインをターゲットにする設定はされていないため、追加する必要があります。この手順を簡単にするための 'add_target.js' スクリプトがあります。スクリプトを実行し、プロンプトが表示されたらターゲットにしたいログインポータルのURLを貼り付けてください：
node add_target.js
これにより、サービス名、タブのタイトル、ファビコンが取得され、エントリが 'targets.json' に追加されます。このスクリプトは複数回実行でき、新しいターゲットが追加されます。スクリプトはドメインに基づいてサービス名を付けますが、トップレベルは除かれます。したがって、'https://www.example.com/login.php' の場合、実行時にターゲットを指定する際のサービス名は 'example' になります。
実行！
node index.js example
数秒後、最初の自動化されたChromeインスタンスがWebSocket経由でチェックインしたときに、コンソールにメッセージが表示されます。これで、フィッシングサイトへの訪問者は、ターゲットのログインページのように見えるが、実際には自動化されたブラウザインスタンスのビデオフィードであるものを見ることができます。また、ブラウザインスタンスと対話し、あなたの代わりにログインすることもできます。
config.json で管理者IPを正しく設定していれば、特別な '/admin' ウェブインターフェースを表示して、ユーザーの追跡、キーログの表示、ログイン済みブラウザインスタンスの制御の引き継ぎ、Cookieの窃取、不要なブラウザインスタンスの削除などができます。
注意：管理者ページには、犠牲者がいない限り何も表示されません。犠牲者が現れると、そのブラウザインスタンスが管理UIに表示されます。
「真っ白なページ」に関する問題を何度か報告いただいていますが、これは多くの可能性がある問題の症状であり、それ自体が問題ではありません。漠然とした症状名で問題を報告しないでください。代わりに、ユーザー側で白いページが表示される場合は、まず以下を確認してください：
大まかに言えば、フロントエンドに白いページしか表示されない場合、「Start WebRTC」→「Select Tab to Broadcast」→「Negotiate ICE with Victim's Browser」→「Stream Video」というデータフローのチェーンのどこかで障害が発生していることを意味します。上記のトラブルシューティング手順は、このプロセスを通じてデータを追跡するのに役立ちます。正常に動作している場合、サーバーには次のようなログストリームが表示されるはずです：
これらの手順が問題解決に役立つことを願っています。いつものように、問題を一貫して再現するための十分な情報が、さらなる調査のために問題を提出するための前提条件です。
JavaScript経由で犠牲者のシステムにペイロードを手動でダウンロードさせます。各ターゲットは最初、テストペイロードとして 'payload.txt' を持っています。targets.json のファイルの場所を変更して、カスタムペイロードを送信してください。
window.location を変更して犠牲者を実際のログインポータルに送ります。ユーザーは強制的に再認証されているように見え、あなたがコントロールを奪っているのを見るのを防ぎます。コードを変更すれば、この一般的な手法で他の派手なこともできるかもしれません ;)
管理ポータルから直接ブラウザインスタンスを操作できます。インスタンスの制御を停止するには、ESCAPEキーを押します。注意：これによりフィッシング被害者から制御が奪われ、先に追い出さない限り、あなたの操作を見ることができます。ご注意ください。
自動化ブラウザインスタンスの制御をユーザーに手動で戻すことができます。これは、ITを装ったソーシャルエンジニアリングのシナリオで役立ちます。ユーザーにヘルプセッションを開始すると伝え、制御を奪ってターゲットサービスに移動し、制御を戻してログインさせ、再び制御を奪うなどができます。
ブラウザインスタンスからすべてのCookieとローカルストレージアイテムを抽出し、JSONファイルとしてダウンロードします。この認証情報をローカルシステムのブラウザインスタンスに注入するには、プロジェクト内の 'stealer.js' スクリプトを使用します。これはサーバーではなく自分のマシンで実行することを意図しているため、使用するにはプロジェクトのNodeコンポーネントをシステムにインストールする必要もあります。
node stealer.js ~/Downloads/cuddle_asdf1234.json
不要になったブラウザインスタンスを強制終了します。ユーザーが完全にログインしてくれない場合、WebRTC接続が失敗した場合、セッションがタイムアウトした場合などに、管理ポータルから役に立たないブラウザインスタンスをクリーンアップできます。
各ブラウザは、独自のランダムな「ブラウザID」と、プロジェクトの "user_data" フォルダ内の対応するユーザーデータディレクトリとともに生成されます。'stealer.js' が機能しない場合、そのインスタンスのユーザーデータも複製する必要があるかもしれません。これは、「このブラウザを記憶する」機能が実装方法に応じてターゲットとなるサービスで役立つことがあります。
各ユーザーデータディレクトリには、犠牲者ユーザーの完全なキーログが記録された keylog.txt もあります。管理ポータルの一般的なキーログはバックスペースなどを考慮しようとしますが、この keylog.txt には記録されたすべてのキーストロークが含まれます。
pm.json の例：
{
"tacking_id": "id",
"logging_endpoint": "https://www.phishmongerserver.com/create_event",
"admin_cookie": "admin_cookie=s3cret",
"post_url_search": "ppsecure"
}
このツールは、フィッシングサイトの訪問者を、フィッシングサーバー上で動作する自動化されたChromeブラウザとペアリングすることで機能します。攻撃者が制御するChromeインスタンスのビデオフィードがWebRTC経由でフィッシング被害者にストリーミングされ、ユーザーが行ったすべてのマウス操作とキーボード入力が、被害者のブラウザから関連するChromeインスタンスに転送されます。サーバーはWebSocketを使用して被害者を追跡し、ブラウザとペアリングし、WebRTCビデオフィードを仲介し、ユーザー入力をマン・イン・ザ・ミドルします。新しい訪問者ごとに、サーバーは新しいChromeインスタンスを生成します。各Chromeインスタンスを駆動するためにChrome Devtools Protocol（CDP）を使用しているため、「Storage.getCookie」などのAPIを使用して、ユーザーがログインした後に対象サイトのセッションCookieを抽出できます。また、いつでも介入して各Chromeインスタンスを直接駆動でき、被害者にリモートコントロールを提供するのと同じ方法を利用できます。
Nodeサーバーは以下のことを行います：
私の理解では、この手法は理論化され、数年も前から武器化されてきたものです（Shoutoutsの項を参照）。したがって、脅威アクターはこの手法を利用でき、おそらくしばらくの間利用してきたでしょうが、攻撃的なセキュリティ専門家はこの手法を簡単に再現する方法を持っておらず、その存在に気づいていない可能性もあります。このツールをリリースする意図は、ペネトレーションテスターやレッドチームがBitMを実際の作戦で使用し、その潜在的な影響を示し、ネットワーク防御者が実際の脅威に備えるのを助けることです。
まず、この攻撃はユーザーを悪意のあるウェブサイトに訪問させるソーシャルエンジニアリングに依存していることを理解してください。ドメインホワイトリスト化は、これや他の種類のソーシャルエンジニアリングを防ぐのに大いに役立ちます。ウェブサービスのすべての認証情報データ（パスワード、OTP、SMS、PhoneFactor、プッシュ通知など）をユーザーに任せている場合、この攻撃に対して脆弱になる可能性があります。したがって、この攻撃を阻止するためには、ユーザーが管理しない認証情報データを活用する必要があります。例えば、クライアントTLS証明書はクライアントデバイスに発行でき、実際のウェブサービスでのみ有効です。証明書はブラウザとオペレーティングシステムによって管理され、攻撃者のサーバーが犠牲者のTLS証明書のコピーを入手する方法はありません。別の方法として、U2FやFIDO2をYubiKeyなどのハードウェアと併用して、必要な認証情報データの一部を管理することもできます。ハッカーのウェブサイトが犠牲者のコンピューターに接続されたYubiKeyとやり取りする方法はありません。
私はまだDockerの達人ではありません（まだ）。シンプルなDocker化されたセットアップを思いついたら、プルリクエストを送ってください。
Cuttlefish（コウイカ）をもじったもので、周囲に溶け込むことができる凄い海の生き物です。Phishing（フィッシング）もかかっていて、攻撃を実行するのにソーシャルエンジニアリングが必要だからです。さらに、ユニークで遊び心があり馬鹿げているように意図的にスペルミスされています。この面白いツール名が、ペンテストレポートで重大リスクの所見と一緒に言及されることを考えると、私は嬉しくなります。
私はこの手法と実装を独自に考案しましたが、後に他の研究者が先に発見していたことを知りました。彼らはそれぞれ、ウェブベースのVNCクライアントを使用して同様の結果を達成するアプローチをとっていました。これは直感的なアプローチであり、ブラウザだけでなく他のソフトウェアに対するMitM攻撃を実行するのにも適用できるかもしれません（VPN-in-the-browser?）。ぜひチェックしてみてください：
Franco Tommasi, Christian Catalano & Ivan Taurino https://link.springer.com/article/10.1007/s10207-021-00548-5
@mrd0x https://mrd0x.com/bypass-2fa-using-novnc/
また：
Daniel Aaron @majordmg には、WebRTCのプロトタイプの初期段階を手伝っていただき感謝します。
RJ Stallkamp @Z3rO-C00L には、管理インターフェースの修正とスタイリング、そして素晴らしい新しいロゴに対して多大な感謝を捧げます。