Hetzner/Linode XMPP.ru MitM傍受事件の緩和策
(devever.net)- jabber.ru と xmpp.ru は、ホスティング事業者経路でのトラフィック傍受と Domain Validation 証明書 の不正発行が組み合わさった MitM 攻撃を受け、Web 以外の TLS サービスにおける防御の空白が露呈した
- Certificate Transparency ログ の監視と TLS 公開鍵プロービングは異常兆候の発見に役立つが、CT 未記録証明書や選択的 MitM を前にすると完全な検知は難しい
- ACME-CAA(RFC 8657) を DNSSEC と併用して展開すれば、特定 CA の特定アカウントだけに証明書発行を許可できるため、攻撃者は単に同じ CA を使うだけでは足りなくなる
- Web ブラウザとは異なり、多くの非 Web クライアントは CT 証明(SCT) を強制せず、CA/Browser Forum Baseline Requirements もすべての証明書の CT ロギングを義務化していない
- 運用者は ACME-CAA・DNSSEC・CT モニタリング・Tor onion service・管轄分散を検討し、利用者はエンドツーエンド暗号化とフィンガープリント確認を基本の防御線とすべき
事件の核心構造
- jabber.ru と xmpp.ru の運営者は、サービスが man-in-the-middle 攻撃 を受けたと明らかにした
- 攻撃は 2 つの要素が組み合わさった形だった
- Hetzner と Linode がサービスマシンに向かうトラフィックを傍受した
- 攻撃者が当該サービスに対する Domain Validation 証明書 を不正に発行させた
- ドイツ国家が調整した、またはドイツが 1 つ以上の他国と共同で調整した可能性が高いと評価されている
- 他の可能性も残っている
- Hetzner と Linode が法的強制なしに外国勢力の盗聴要請へ自発的に応じた可能性
- ただしこの場合、両社にとって非常に悪い評価につながり違法である可能性もあるため、可能性は低いとみられる
検知方法と限界
- 1 つ目の方法は Certificate Transparency(CT) ログ を監視し、運営者が要求していない証明書発行を見つけること
- これを代行するサービスが一部ある
- 未承認証明書だけをうまく選別して通知するツールには、さらに改善の余地がある
- 2 つ目の方法は、定期的にサービスへ接続して TLS サーバーの 公開鍵 が期待値と一致するか確認すること
-
CT 監視が見落としうる領域
- 正規の CA が発行した証明書でも、必ず CT ログに記録されるとは限らない
- CA/Browser Forum Baseline Requirements は、まだ CT ロギングを CA の必須要件にしていない
- Web ブラウザは、CT ログ記録の暗号学的証明がない証明書を拒否するため、CT ロギングは事実上強制される
- ほとんどの非 Web クライアントアプリケーションは、証明書に CT 記録証明があるかを確認したり要求したりしない
- 攻撃者は理論上、CT に記録されていない証明書 を調達できる
-
選択的 MitM の回避可能性
- サービスプロービングで MitM を検知しようとしても、攻撃者が検知用接続を識別し、その接続には MitM を適用しない可能性がある
- 少なくとも Tor 経由でプローブを実行しなければ、識別されやすい状況を避けにくい
- TLS スタックは TLV 列挙順のような信号でフィンガープリント取得が可能であり、実際の XMPP クライアントとプローブエージェントを区別できる可能性がある
- 攻撃者は既知のプローブをブラックリストで除外する代わりに、関心のある特定人物のトラフィックだけをホワイトリスト方式で MitM することもできる
- どちらの検知方法も 完全な信頼性 は提供しない
ACME-CAA で減らせるリスク
- TLS 証明書は MitM 攻撃を防ぐための仕組みだが、CA がドメイン支配権を検証する Domain Validation モデル 自体が MitM に脆弱である
- 攻撃者が被害サイト宛ての一部ではなく全トラフィックを傍受できると、リスクはさらに高まる
- ACME-CAA(RFC 8657) は、特定の状況ではこの問題を緩和できる
- 核心となるアイデアは、DNS レコードで 特定 CA の特定アカウント のみにドメイン証明書発行を許可すること
- 単に同じ CA を使うだけでは不十分
- その CA の同じアカウントへのアクセス権が必要になる
- Let's Encrypt では、証明書要求に使う ACME 秘密鍵へのアクセスが必要
- 既知の攻撃手法を前提にすれば、この拡張を導入していれば攻撃を防げた可能性が高いと評価されている
-
導入時の注意点
- ACME-CAA が正しく機能するには DNSSEC の導入が必要
- DNSSEC がなければ、CA の DNS 問い合わせも傍受できる
- DNSSEC 署名鍵を掌握した者はこの障壁を回避できる
- DNSSEC で保護された DNS ゾーンは、署名鍵を第三者に渡さずに運用できる
- この場合、DNS ホスティング事業者にはゾーンを改ざんする権限がない
- この方式が最良の導入戦略と評価されている
- 攻撃者はドメイン登録事業者や TLD レジストリに圧力をかけ、ドメインに登録された DNSSEC 署名鍵を変更しようとするかもしれない
- この作業は目立つ可能性がある
- DNS キャッシュの性質上、反復プローブで鍵変更の検知を妨げ続けるのは難しい可能性がある
- 攻撃者が CA 自体に圧力をかけて誤発行させる可能性もある
- 第三者 CA がルール違反やミスをすると、依然として脆弱である
- CA/Browser Forum Baseline Requirements は、CA に DNSSEC の確認を要求している
- しかし第三者 CA は、CAA レコードで許可されていないにもかかわらず証明書を発行できる
- CT ロギングが必須ではないため、そのような証明書が検知されない可能性もある
より熟練した攻撃者が選びうる流れ
- 今回の事件の攻撃者は不正証明書を期限切れのまま放置しており、完全な攻撃者ではなかった
- 安価で容易な暗号化が広がるにつれ、国家レベルの攻撃はより精巧かつ頻繁になると予想される
- より熟練した国家レベルの攻撃者なら、次の流れを選ぶ可能性がある
- CA が CT ログ記録を義務化していない点を利用して 未記録証明書 を要求する
- ホスティング事業者に圧力をかけ、被害マシンに向かう全トラフィックを MitM する
- TLS スタックのフィンガープリントと送信元 IP で、関心トラフィックと検知用トラフィックをヒューリスティックに区別する
- MitM を使って、CA に攻撃者を被害ドメインの正当な管理者だと信じ込ませる
- ドメインが ACME-CAA と DNSSEC を使っているなら、DNS ホスティング事業者、登録事業者、TLD レジストリ、CA に圧力をかけようとする可能性がある
現在の TLS インフラの穴
-
非 Web TLS クライアントの CT 強制不足
- Web ブラウザは、CA 証明書に CT ログ記録の暗号学的証明が含まれることを要求する
- ほとんどの他の TLS クライアントは CT 証明 を強制しないため、未記録証明書を受け入れうる
- 多くの XMPP クライアントもこれに含まれる可能性が高い
- CT 検証は OpenSSL にリンクすれば自動で有効になる機能ではなく、別途実装が必要
- 機密通信に使うソフトウェアは CT 強制サポートを検討すべき
-
証明書 CT ロギング義務の不在
- CA が従うべき業界ルールである CA/Browser Forum Baseline Requirements は、証明書を CT ログへ記録することを要求していない
- すべての証明書を CT ログへ記録するよう求める方向が必要だと考えられる
- CT 強制が広く導入されれば、この問題は技術的に無意味になる可能性がある
-
CT モニタリングサービス不足
- さらに多くの CT モニタリングサービス が必要
- 現在の主要な CT 通知サービスとして SSLMate's Cert Spotter がある
- 価格は、ボランティアベースのサービスなどには負担になりうる
- CT モニタリングは誤検知を減らし、異常または無断と見える証明書発行だけを通知するよう設計すべき
-
DNSSEC 透明性の不在
- 現在、ドメインに設定された DNSSEC 鍵変更を検知する展開済みの暗号学的インフラはない
- ドメイン登録事業者や TLD レジストリが圧力や侵害を受けてドメインの DNSSEC 鍵を変更すると、ACME-CAA 保護が弱まる可能性がある
- DNSSEC ゾーン鍵変更が公開的に見えるようにする 透明性ソリューション が望ましい
- このソリューションは、ゾーンの全レコードではなく DS レコードのようなゾーン鍵変更だけを記録すればよい
サービス運営者への推奨
- 国家レベル攻撃の標的になりうるサービスなら、費用対効果の高い順に防御策を適用するアプローチが推奨される
-
ACME-CAA と DNSSEC
- ACME-CAA を導入すれば、攻撃者が CA を欺いてドメイン証明書を発行させるのが難しくなる可能性がある
- 導入ガイドは ACME-CAA 導入記事 を参照できる
- RFC の Security Considerations にも重要な注意点が含まれている
- ACME-CAA を導入するなら DNSSEC も併せて導入 すべき
- 可能なら、署名鍵を事業者に預けなくてもよい DNSSEC 事業者を選ぶべき
-
プロキシサービスと CT 監視
- Cloudflare のようなサービスを使うと、自分で自分をすでに MitM しているのに近い状態になると評価されている
- CT ログ監視サービスに登録するか、ログを定期的に自分で確認すべき
- SSLMate's Cert Spotter は有料の自動モニタリングを提供する
- Cert Spotter はオープンソース なので自前ホスティングも可能
- crt.sh は CT ログの手動検索を提供する
-
管轄分散と Tor onion service
- ドメイン登録事業者、TLD レジストリ、DNS ホスティング、CA、ホスティング事業者をそれぞれ別の国に置く 管轄分散 を検討できる
- 相互に協力する可能性が低い国や地政学的ブロックを考慮して選べる
- Tor onion service を提供すれば、TLS や CA のような中央集権的インフラを回避できる
- Tor onion service では、サービス公開鍵がアドレスそのものである
- 利用者は正しい onion アドレスを信頼できるチャネルで受け取る必要がある
- 第三者が誤った onion アドレスへ誘導する可能性がある
-
Tor ベースの自動プロービング
- Tor 経由の自動プロービングは完全な解決策ではないが、現実に起きる未熟なミスを捉えられる
- Tor を使えば、プローブとして容易に識別される事態を減らせる
- TLS フィンガープリントの可能性を下げるには、クライアントソフトウェアが一般的な TLS ライブラリを使うほうがよい
- 可能なら実際のクライアントを使うほうが望ましい
- XMPP サービスなら、実際の XMPP クライアントを使える
- 成功しても侵害後の検知にとどまり、その時点では利用者がすでに被害を受けている可能性がある
-
他の攻撃ベクトルと最悪想定
- MitM を困難にすると、攻撃者はマシン自体の侵害、秘密鍵窃取、機密情報窃取など別経路を使う可能性が高まる
- 国家レベル攻撃者は VM 事業者に圧力をかけ、ハイパーバイザレベルでメモリダンプを実行させることがありうる
- 専用サーバーでも、攻撃者の物理アクセスにより侵害されうる
- 運営者は利用者に エンドツーエンド暗号化 を勧め、サービスは最善を尽くしても侵害されうると想定すべき
- Web アプリケーション経由で提供される「エンドツーエンド」暗号化は、有意な保護ではないと評価されている
CA、クライアント開発者、利用者に必要な対応
-
CA/Browser Forum
- すべての証明書を CT ログへ記録するよう要求するか、その提案を出すべき
-
アプリケーションクライアント開発者
- TLS 証明書に Signed Certificate Timestamps(SCTs) があることを強制する機能を追加し、デフォルトで有効化すべき
- 利用者がこの保護を受けていると分かるようにすべき
- CT 証明強制には一定の変動要素があるため、関連する議論も考慮すべき
- ソフトウェアは公開監査可能なようにオープンソースで提供すべき
- サプライチェーンリスクと、開発元自身が法的にソフトウェア改変を強制される可能性も考慮すべき
- Linux ディストリビューションのパッケージリポジトリのように、開発者が直接統制しない配布チャネルは被害軽減に役立つ可能性がある
-
エンドユーザー
- サービス運営者が善意で運営していても、最善を尽くしてもサービスは侵害されうると想定すべき
- 命がそのサービスの非侵害性に依存するなら、そのサービスを信頼すべきではない
- XMPP では OMEMO または OTR のようなエンドツーエンド暗号化技術を使うべき
- 通信相手のフィンガープリントは常に確認すべき
- Web ベースのソフトウェアでエンドツーエンド暗号化を行わないか、少なくとも侵害済みだと想定すべき
- サービス提供者が Tor onion service を提供しているなら利用を検討しつつ、onion アドレスは信頼できる出所から受け取る必要がある
-
CA と標準策定者
- CA は ACME-CAA(RFC 8657) をサポートしていないなら、実装を検討すべき
- ACME ベースの CA でなくても ACME-CAA を実装できる
- CA/Browser Forum の規則が CT 未記録を許していても、CA はすべての証明書を CT に記録する方針を採用できる
- 標準策定者は、少なくとも DS レコードについて DNSSEC 透明性 の可能性を再検討できる
Confidential computing に対する評価
- ホスティング事業者によるマシン侵害まで懸念する場合、現在の confidential computing 技術は十分な解決策とは評価されていない
- 導入自体は何もしないよりはましかもしれないが、安全だと信じるべきではない
- AMD、Intel などを含む現在の技術は、システムをバックドア化できるベンダーのゴールデンキーに依存していると評価されている
- 国家レベル攻撃者はベンダーに圧力をかけて鍵を渡させることができ、その場合この方式は破綻する
- ゴールデンキーに依存しない confidential computing の方式はありうるが、現在の方式はその基準に達していない
関連資料
- Mitigating the Hetzner/Linode XMPP.ru MitM interception incident, part 2: XMPP-specific mitigations: XMPP 向けの緩和アドバイス
- Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service: 元の事件報告
- ACME-CAA (RFC 8657)
- Let's Encrypt now supports ACME-CAA: closing the DV loophole
- Web-based cryptography is always snake oil
- Cloudflare considered harmful
1件のコメント
Hacker Newsのコメント
https://notes.valdikss.org.ru/jabber.ru-mitm/ の攻撃概要が興味深い
攻撃者は2023年4月18日から Let’s Encrypt で jabber.ru と xmpp.ru の SSL/TLS 証明書を複数発行しており、7月21日から10月19日までは、少なくとも XMPP STARTTLS の5222番ポートにおけるクライアントトラフィックの100%に中間者攻撃が適用されていたことが確認された
その後、証明書の再発行に失敗したことで jabber.ru の5222番ポートで期限切れの証明書を提示するようになり、調査と Hetzner/Linode への問い合わせが始まった直後に攻撃は止まったが、一部の Linode サーバーには追加のルーティングホップを介した受動的な盗聴が残っていた
サーバー自体はハッキングされていないようで、Hetzner と Linode のネットワークが XMPP サービスの IP を狙って再構成されたように見える
当該ページでも、ここでリンクされているページでも証明書ピンニングには触れていないが、XMPP が対応していないからなのかは分からない。ただ、対応していればこの種の攻撃を防げたのではないかと思う
残念ながら jabber.ru は2016年のサーバーソフトウェアを使っているため、その古いバージョンでは対応していない
最近の証明書ピンニングは、証明書の有効期間が短く頻繁に更新されるため問題が多い。毎月新しい証明書を許可するようユーザーに求めれば、攻撃者の証明書にも深く考えずに「Accept」を押してしまう
チャネルバインディングは証明書とは独立して動作し、TLS ストリームが期待した主体で終端していることを保証する
XMPP クライアントの CT/SCT 対応不足に焦点を当てるのは不思議だ。この攻撃では Let’s Encrypt が発行し、CT ログにも掲載された有効な証明書が使われていたため、CT/SCT では検出できなかったはずだ
厳格な CAA レコードがあれば、別の認証局から発行されるという理論上の状況を SCT 検証で検出できるかもしれないが、実際には CAA もなく、チャネルバインディングのほうがプライバシーに配慮しており、第三者への依存も少ない
つまり、ホストされている HTTP で ACME プロトコルに応答できたか、DNS TXT レコードを書き込めたということで、被害者はすでにプロセスサーバーまたはネームサーバーの制御権を失っていたことを意味するように見える
証明書ピンニングはクライアントを制御できる場合にのみ可能で、許可する証明書をクライアントに直接入れて、Web 公開鍵基盤全体を迂回する方式だと理解している
汎用クライアントが接続する状況では、どの証明書が許可されるべきかを知る方法がなく、まさにその用途のために Web 公開鍵基盤を使っている
もちろん独自クライアントを提供したとしても、問題が一段上に移るだけで、顧客がカスタムクライアントをダウンロードする場所が侵害され、悪意あるクライアントが配布される可能性がある
この一覧には最も obvious な防御策が抜けている。認証方式として SCRAM-xxxxx-PLUS を有効化し、可能なら強制すべきだ
PLUS 変種の発想は単純だが効果的だ。ソルトだけで検証する代わりに特定の TLS 接続に結び付けて検証するため、認証が単一の TLS 接続でのみ有効になる
これはチャネルバインディングとも呼ばれる
xmpp.ru と jabber.ru のエンドユーザーが誰なのか気になる。ロシア軍人やスパイ同士のトラフィックを捕まえようとしているのだろうか？ 大量監視は嫌いだが、なぜよりによってロシアのドメインを狙ったのか分からない
もっとありそうなのは、カーダーやボットネット運営者を捕まえようとするシナリオ。Jabber/XMPP はロシア方面のその界隈では今でもかなり人気があり、Krebs on Security のような記事でも @exploit.in、@jabber.ru など複数のサーバーが写ったスクリーンショットやログをよく見かける
それでも意図が何であれ、大量監視はおおむね嫌悪すべきものだ
2つのサーバーで犯罪的利用と非犯罪的利用の比率が正確にどうなっているかは分からないが、Tor のように明らかに違法な内容と合法的な利用が混在しているのと同じく、ここにもまったく普通の会話がかなりあるはずだ
だからそもそも、引き渡しも難しい管轄外の国にいる任意のサイバー犯罪者を監視するためにプライバシーを侵害することには、あまり賛成できない
Hetzner が Lavabit のようにならないためには協力せざるを得なかったという点は理解するが、よく推薦していた立場としては、Hetzner が中間者攻撃を知りながら許可した、あるいは手助けしたのだとしたらかなり失望する。それ以外では最高のホスティング会社の1つだと思っている
透明性が高く、ほとんどのクラウド事業者より稼働率・信頼性・サポートが良く、費用も過大ではない。環境配慮型の設計を経済的にも賢い選択にしようとする取り組みも称賛に値する
「削減 > 再利用 > リサイクル」における削減は、KISS 設計に表れている。例えば、自然な排熱を助ける高く傾斜した屋根[2]、実際のシャーシというより最小限の構造支持とエアフロー用カバーに近いサーバーシャーシ、VRM・CPU・メモリを1つのファンで冷やすためにソケットを90度回転させた標準的なマザーボード設計[3]などだ
「再利用」はサーバーオークションに表れている。旧世代のハードウェアを廃棄せず、ダッチオークション方式で貸し出すことで、新しいハードウェアの費用と、世代ごとに新規製造する環境コストの両方を避けている
欧州外にも専用サーバーがあれば、もっと使いたい
[1]: 「合法」そのものも定義が難しい。ある国の記者は別の国では「外国の代理人」であり、ある国の「自由の闘士」は別の国では「テロリスト」だ
[2]: Der8auer: Over 200,000 Servers in One Place! Visiting Hetzner in Falkenstein - https://youtu.be/5eo8nz_niiM?t=259
[3]: Der8auer: Hetzner shows Special AM5 Board with 90° Rotated Socket - https://youtu.be/V2P8mjWRqpk
記事では「CT は任意」としているが、結局は XMPP クライアントが決める問題ではないのか？ ブラウザが事実上要求している現在、XMPP クライアントが CT を要求できない理由が何なのか気になる
ブラウザで動作しない証明書を発行するような、どのトラストストアに依存しているのかも分からない
問題は、CT を要求する挙動がほとんどの TLS ライブラリでデフォルトでは有効になっていない点だ。だから XMPP クライアント開発者が意図的に有効化する必要があり、現状では大半、あるいは全てがそうしていないと思う。もちろん変わる可能性はある
この記事は XMPP で OTR を使うことを提案しているが、残念ながら OTRv3 は古い暗号を使っており、OTRv4 はまだ確定していない
https://dustri.org/b/time-to-sunset-otr.html
「完璧な攻撃者なら何をするか？」という問いに対しては、コンピュータに物理的にアクセスできるなら、何らかのバス傍受でデバイスからデータを抜き出す方法がありそうだ
ダイヤルアップや低速・高遅延のブロードバンドの時代には理にかなっていたが、今では高速な光ファイバーとピアリング地点まで低遅延な場所が多い
データセンターやクラウドから離れるほど、インターネット基盤は本来設計された方式で動作するはずで、現在のように深刻な障害点であり大きなセキュリティリスクでもある集中集約ポイントを通過する必要は減る
CAA について調べたが、今使っている DNS プロバイダーはそのレコードをサポートしていない。なぜもっと一般的な TXT レコードではなく、新しいタイプである必要があったのか理由はある？
それが無理なら、サポートを依頼する必要がある。CAA レコードはますます多く使われるタイプなので、今どきサポートしていないのはあまり良いサービスとは言えない
CAA の設計議論はよく知らないが、関連する IETF メーリングリストで議論された可能性が高い
DNS プロバイダーは多様な RR タイプをサポートすべきで、ドメイン所有者は NS レコードで投票すべきだ
CAA をサポートする DNS プロバイダーの一覧は https://github.com/StackExchange/dnscontrol/blob/master/docu... にある
隠れたプライマリサーバーを立てて、プロバイダーをセカンダリサーバーとしてだけ置けるか試してみる価値はある。Linode ではその制限をこの方法で回避した
自前の認証局を運用し、ルート証明書を慎重に選ぶという選択肢が抜けている
プロバイダーはホストにアクセスできるため、外部から作業を検査でき、ユーザーは気づけない
たとえばカーネルのアップグレード後も生き残り、自身を高度に隠蔽するカーネルモジュールを仕込む必要がある。記事でも生メモリダンプの分析を扱っている
国家、またはそれに準じる強力な主体によるこのような攻撃に対する根本的な技術的解決策は何だろうか？ 自由に配布できる一方で、作者以外の誰にも検閲・介入・改ざんできないソフトウェアという、ギーク的な夢を満たす方法はあるのだろうか？
現在のインターネット基盤の上にきちんと作られた P2P システムがあれば十分な答えなのか、それとも無線で動作する低帯域のグローバルなメッシュインターネットをもう一つ敷くべきなのか？
Freenet 2023 が、P2P アプリケーションに対して摩擦のない開発者体験へと進化することを願っている