大規模なTor出口ノード攻撃
正体不明の攻撃者が、Torの出口ノード333台を乗っ取りました。これにより、攻撃者はSSH接続や暗号化されていない通信を傍受できる状態になりました。乗っ取られたリレーは、ネットワーク全体の出口リレーの約10%を占めていました。防御側が攻撃を止めるまでには、数日を要しました。
スイスのセキュリティエンジニアで、KABAの名で活動する人物が、10月20日に詳細を公表しました。
侵害の経緯
KABAによると、組織的な攻撃は10月2日の09:35に始まりました。この時刻に、感染した333台のノードがトラフィックの処理方法を一斉に変更しました。
ただし、攻撃者がサーバーに侵入したのはそれよりはるか前の8月でした。攻撃者はそこで、マルウェア「Ebury」1.8.3をインストールしていました。
攻撃者の狙い
インフラの構成からは、SSHパスワードと、暗号化されていないメール通信の内容という2つの狙いがうかがえます。
SSHの傍受
侵害されたサーバーは、SSHトラフィックを攻撃者が管理する12台のシステムへ迂回させていました。これらのシステムは接続先のサーバーになりすまし、認証情報の窃取を試みました。
KABAは、自身の接続でこの仕組みを発見しました。本来のサーバーではなく、リモートホストキーが変更されたという警告がクライアントに表示されたのです。ユーザーがこの警告を無視してパスワードを入力すれば、偽サーバーはそれを奪えます。その後、本物のシステムに接続し、ユーザーが入力したコマンドを監視することもできます。研究者によると、攻撃者は彼のサーバーにもEburyをインストールしようとしたといいます。
これは中間者攻撃です。第三者が、2者間の通信経路に気づかれないよう割り込みます。今回はSSHのホストキー確認が重要な役割を果たしました。予期せぬキー変更の警告が表示された際にユーザーが接続を続けなければ、攻撃を阻止できた可能性があります。KABAは、盗まれたパスワードの件数について確認できた数字を示していません。
メールを平文通信に誘導
メールについては、攻撃者は別の手口を使いました。暗号を破るのではなく、出口ノードの接続ルールを変更したのです。安全なメール接続に使われるポート465、587、993、995を遮断する一方、TLSを使わないメール用のポートは開いたままにしていました。
その結果、設定によっては、一部のメールクライアントが安全でない接続に切り替わった可能性があります。
出口ノードが重要な理由
ユーザーのトラフィックは複数のリレーを経由し、最後のサーバーがリクエストをオープンなインターネットへ送り出します。中間のホップでは、Torが独自の暗号化で通信を保護しています。しかし出口ノードは、アプリケーションが追加の保護なしに送信したデータを見られる可能性があります。
HTTPSや適切に設定されたTLSを使えば、クライアントと最終的なサーバー間の通信は暗号化されたままです。
乗っ取られたサーバーの設定変更
攻撃者は支配範囲を広げるため、すでに掌握したサーバーのtorrc設定ファイルを書き換えました。これまで中間ノードとしてのみ機能していた一部のリレーが、変更後は出口トラフィックを処理し始めました。
Torのセキュリティチームは、不正な設定変更とSSHの傍受を確認しました。ただし、影響を受けたすべてのサーバーで最初の侵入経路が正確にどこだったのかは、今も分かっていません。
攻撃者の主要ツール「Ebury」
Eburyは、LinuxなどUnix系サーバーを狙う、以前から知られたマルウェアファミリーです。SSH認証にフックして認証情報を盗み、隠れたアクセス経路を開きます。2024年5月のESETの調査では、攻撃者がこれまでに約40万台のサーバーを侵害したと報告されました。2023年末の時点でも、10万台超が感染したままでした。
Quetzalcoatlの事例
被害を受けたTor運営者の1人が、Quetzalcoatlインフラの詳細なタイムラインを公開しました。8月28日、攻撃者は管理サーバーに一度で正しいパスワードを入力してログインしました。管理者権限を得た攻撃者は、Ebury 1.8.3をインストールしました。続いて、出口リレー2台をホストする別のサーバーにも到達しました。運営者は、攻撃者が最初にどこでパスワードを入手したのかを突き止められませんでした。
Eburyの隠蔽手口
感染したマシンでは、Eburyはシステムライブラリ「libkeyutils」になりすましていました。元のSSHバイナリには手を加えていません。そのため、インストール済みパッケージに対する通常の整合性チェックでは検出できませんでした。
このマルウェアは標準的なログインログも回避し、SSHプロセス内部でパスワードを取得していました。研究者らは、バージョン1.8.3が、これまでに公開されたEburyの検出ツールの一部をすり抜けることを確認しました。
被害の規模
インシデント後、Quetzalcoatlの運営者は、57個のIPアドレス上にある168台のリレーが停止していることを発見しました。これらはすべて、同じ不審な出口ポリシーを公開していました。
それでも、フォレンジック調査の対象となったのは2台のサーバーだけです。ほかのサーバーすべてでEburyを独立に確認した例はありません。運営者はこのインフラを廃止し、旧リレーのIDも破棄しました。
攻撃が止まるまで
キャンペーンが発覚したきっかけは、KABAが偶然SSH接続したことでした。10月2日の夜、彼は調査結果をネットワークの安全を守るTor Network Healthチームに伝えました。
10月4日、同チームは不審なサーバーに、ノードが出口として機能することを禁じる「BadExit」フラグを付与し始めました。運営者にも警告が送られ、侵害されたマシンは自主的に停止されました。
翌日、攻撃者は一部のリレーを再起動しようとしました。しかし、BadExitフラグにより、従来の傍受は阻止されました。10月5日までに、特定された333台のノードはすべて停止しました。一部は運営者が停止させたものですが、KABAは、残りは攻撃者の判断で停止した可能性があるとみています。Torのメトリクスでは、10月4日以降、利用可能な出口リレーが急減しています。
リレー運営者への指針
Torチームは、Linuxサーバーの運営者に次の項目の確認を呼びかけています。
- torrcの設定
- SSHトラフィックのリダイレクトルール
- 不明なプロセス
- システムサービスへの不審な変更
侵害の兆候があるサーバーでは、マルウェアのファイルを削除するだけでは不十分です。サーバーを再インストールし、すべての鍵とパスワードを交換したうえで、新しいリレーIDを作成してください。古い鍵は侵害されたものとして扱う必要があります。
今回の件が意味しないこと
今回は、Torの出口ノードをめぐる既知のインシデントの中でも最大級の一つです。ただし、感染したリレーが333台あったからといって、攻撃者がネットワーク全体の通信を見ていたことにはなりません。ユーザーの匿名性が自動的に破られるわけでもありません。
主なリスクは、攻撃者が支配する出口ノードを経由し、アプリケーションレベルで傍受が可能だった通信にありました。実際にどれだけのデータが盗まれたのかは、分かっていません。
2023年とは異なる種類の脅威
Torではこれまでも、大量のリレーが排除されたことがあります。2023年11月には、開発者らが商業的な暗号資産スキームに関連する多数のノードを排除しました。このスキームは、ユーザーとネットワークの独立性にリスクをもたらすものでした。
この事例で問題となったのは安全でないサーバー管理モデルであり、SSH傍受が確認されたわけではありません。2026年10月のインシデントは、別の問題を示しています。ボランティアが運営するリレーであっても、攻撃者に運営者のハードウェアを握られれば、監視ツールになり得るということです。
翻訳元: https://meterpreter.org/tor-exit-node-attack/
