Hetzner・LinodeでJabber.ruの暗号化トラフィック傍受の兆候を発見
(notes.valdikss.org.ru)- ロシアのXMPPサービス jabber.ru/xmpp.ru のHetzner専用サーバーとLinode VPSで、ポート5222のXMPP STARTTLS接続が透過的なMiTMプロキシに傍受されていた兆候が確認された
- 攻撃者はLet’s Encryptで複数の TLS証明書 を発行し、暗号化接続を中間で終端していた。Hetzner上のjabber.ruのポート5222が期限切れ証明書を返したことで問題が発覚した
- サーバー侵害や同一ネットワーク区間でのARPスプーフィングの痕跡はなく、Linodeインスタンスは通常のVMとは異なる経路・ゲートウェイMACを示しており、ホスティングネットワークの再構成 の可能性が高まった
- MiTMは少なくとも2023年7月21日から10月19日まで確認され、2023年4月18日からだった可能性も残る。ポート5222接続の100%が影響を受け、ポート5223は対象外だった
- 当該期間のjabber.ru/xmpp.ru通信は侵害されたものとみなすべきであり、OMEMO・OTR・PGPのようなエンドツーエンド暗号化も、双方が鍵を検証していた場合にのみ保護される
期限切れ証明書で明らかになった傍受
jabber.ruは2000年に始まったロシアのXMPPサービスで、xmpp.ruとしても知られている- 2023年10月16日にサービスへ接続した際、「Certificate has expired」というメッセージが表示されたが、サーバーにインストールされていた証明書はいずれも最新だった
- 異常はXMPP STARTTLS用の ポート5222 でのみ現れ、XMPP TLS用のポート5223など他のポートでは観測されなかった
- 影響を受けたサーバーは、ドイツのHetzner専用サーバー1台とLinode仮想サーバー2台
- ポート5222のトラフィックでは、サーバーがクライアント本来のClientHelloではなく、差し替えられたClientHello を受け取る形が観測された
サーバー内部侵害の調査結果
- 調査対象は、サーバーのハッキング可能性とローカルネットワークのスプーフィング可能性だった
- サーバー側では次の項目を確認したが、特異点は見つからなかった
- ログ全般
- 実行ファイルとライブラリの更新時刻
- 実行中のプロセス、メモリマップ、dangling file descriptor
- 静的コンパイルした
busyboxを用いたユーザー空間のLD_PRELOADハイジャックライブラリの有無 - LiMEでカーネルメモリをダンプし、volatilityで分析したカーネルレベルのハイジャックモジュールの有無
- Hetzner専用サーバーのカーネルログでは、2023年7月18日に物理ネットワークリンクが 19秒間切断された記録 だけが例外的に見つかった
- Linodeサーバーは、Hetznerサーバーへ向かう代替経路用トンネルとしてのみ使われ、SSH、NTPなどの基本サービスだけが稼働していた
- Hetzner↔Linodeトンネル内部ではHetznerサーバーの正常なServerHelloが見えていたが、Linodeネットワークインターフェイスからクライアントへ送る際に変更されていた
- 同じ種類の暗号化接続傍受がHetznerとLinodeの双方で発生していたことになる
Linodeネットワークで見られた異常の兆候
- ネットワーク観点では次の項目を点検したが、サーバー周辺ネットワークでハイジャックの痕跡は見つからなかった
- ゲートウェイMACアドレスのARPスプーフィングの有無
- L2区間で1つのIPがARP要求に複数回応答するかどうか
- ICMP redirectなどで注入された異常なルーティング規則
- Netfilter規則
- IPsecのような発見しにくいトンネルの有無
- 影響を受けたLinodeマシンは、同じネットワーク区間の隣接IPをARPで見つけたりpingしたりできなかったが、外部ネットワークからはそれらの隣接IPが正常に動作していた
- 影響を受けていない第三者のLinode VMは隣接ホストへpingでき、Cisco Systemsルーターに接続されていた
- 一方、影響を受けたVPSはメーカーを識別できないMACアドレスのゲートウェイに接続されていた
- この違いにより、影響を受けたLinode VMが通常のLinodeインスタンスとは異なるネットワーク設定、または別VLANに隔離されていた可能性が高まった
偽造証明書とCertificate Transparencyの痕跡
- crt.sh certificate transparency databaseで、jabber.ruサーバー側が発行していない rogue certificates が見つかった
- 正常なXMPPサービスには2種類の証明書が使われていた
xmpp.ru, *.xmpp.rujabber.ru, *.jabber.ru
- 悪意を持って発行された証明書は、正常な証明書と構成がやや異なっていた
- ワイルドカードのSubject Alternative Nameが欠けている、または
jabber.ru, xmpp.ruを1つの証明書にまとめて発行していた
xmpp.ruドメインを指すLinode側のMiTM設定には、一部誤りがあった- 元のサーバーは、要求されたXMPPドメインに応じて
jabber.ruとxmpp.ruの両方の証明書を提供するよう設定されていた - MiTM側は
xmpp.ru証明書だけを提供していた
- 元のサーバーは、要求されたXMPPドメインに応じて
- 2023年7月18日の証明書発行時刻は、Hetznerサーバーのネットワークリンクが数秒間切断された時刻とほぼ同じだった
- 外部ネットワークスキャナーは、Linodeサーバーが少なくとも2023年7月21日からポート5222で
04:b7:85…証明書を提供していたことを確認した - このスキャナーはHetznerのレンジは処理していなかった
ポート5222前段の機器と経路差
- 外部からLinode VPSを対象に追加のネットワークテストを実施した
- 同じLinode区間の隣接ホストは、ノートPCのインターネット接続からhop 13で到達できた
dawn.jabber.ruLinodeサーバーの 傍受されたポート5222 もhop 13で到達できた- しかし同じサーバーのSSHポート22のように傍受されていないポートは、追加の非公開hopを経由し、hop 14でのみ到達できた
- この結果は、Linode VMのIPアドレスが追加機器の背後に置かれ、その機器がTCPポート5222を直接処理し、他のポートは実際の宛先へルーティングしていたことを意味する
- VPS内部ではsource port 5222で新しい接続を作成できなかった
- ルーターはそのsource portから出たパケットに応答しなかった
- TTL=0またはTTL=1のoutgoing packetに対して、ICMP errorやTime-to-Live Exceededも送信しなかった
STARTTLS終端方式と検出フィンガープリント
- testssl.shで検査した結果、傍受プロキシはLinodeの
xmpp.ruとHetznerのjabber.ruの双方で anonymous ciphers を許可していた - これはまれな設定ミスであり、XMPP MiTM検出用のフィンガープリントとして使える
- 一般的なSSL/TLSライブラリはたいていanonymous cipherのサポートなしでコンパイルされており、設定ファイルで明示的に許可しても、サービスがそれを使うよう構成するのが難しい場合が多い
- 元のサーバーにはanonymous cipherは設定されていない
- 同じ
testssl.shコマンドで人気のXMPPサービス約20件を検査したが、Anonymous NULL Ciphers対応のような異常の兆候は見つからなかった
確認された結論とユーザーへの影響
- 攻撃者は2023年4月18日から、jabber.ruとxmpp.ruドメインに対してLet’s Encryptで複数のSSL/TLS証明書を発行した
- jabber.ru/xmpp.ruクライアントのXMPPトラフィック復号を目的とする Man-in-the-Middle 攻撃は、少なくとも2023年7月21日から10月19日まで確認された
- 2023年4月18日からだった可能性はあるが、確認はされていない
- 影響範囲はXMPP STARTTLSポート5222接続の100%であり、ポート5223は含まれない
- 攻撃者はTLS証明書の再発行に失敗し、Hetzner上のjabber.ruポート5222でMiTMプロキシが期限切れ証明書を提供し始めた
- MiTM攻撃は、2023年10月18日の調査とネットワークテスト、Hetzner・Linodeへのサポートチケット提出直後に停止した
- ただし少なくとも1台のLinodeサーバーでは、追加のルーティングhopという形の 受動的盗聴 が引き続き残っていた
- サーバーがハッキングされた痕跡はなく、HetznerとLinodeのネットワークがXMPPサービスのIPアドレスを対象に、この攻撃に合わせて再構成されたものと見られる
- 当該期間のjabber.ru/xmpp.ru通信は侵害されたものとみなすべきである
- 攻撃者はアカウントのパスワードを知らなくても、認証済みアカウントから実行されたかのように振る舞うことができた
- アカウントrosterのダウンロード、暗号化されていないサーバー側の全メッセージ履歴へのアクセス、新規メッセージ送信、リアルタイムでのメッセージ変更が可能だった
- OMEMO、OTR、PGPのようなエンドツーエンド暗号化通信は、双方が暗号鍵を検証していた場合にのみ傍受から保護される
- ユーザーはPEPストアに新しい未承認のOMEMO・PGP鍵がないか確認し、パスワードを変更する必要がある
運用者ができる予防と監視
- 新しい証明書の発行はCertificate Transparencyに記録されるため、Certificate Transparency監視 を設定できる
- RFC 8657のCAA Record Extensions for Account URI and ACME Method Bindingを使うと、証明書発行方法と発行可能なアカウント識別子を制限できる
- すべてのサービスのSSL/TLS証明書変更を外部サービスで監視できる
- デフォルトゲートウェイのMACアドレス変更を監視できる
- XMPPの channel binding は、傍受側が有効な証明書を提示してもMiTMを検出できる
- クライアントとサーバーの両方がSCRAM PLUS認証メカニズムをサポートしている必要がある
- 攻撃当時、jabber.ruでは有効化されていなかった
- ACME開発者Hugo Landauによる追加の推奨事項は、More recommendations from ACME developer Hugo Landauにまとめられている
HetznerとLinodeの回答
- 2023年10月20日時点で、HetznerとLinodeから十分な回答は得られていなかった
- 2023年11月3日の更新でも、両社ともこの事件について適切な回答をしなかった
- Hetznerは、専用rootサーバーとCloudサーバーについてはハードウェア、ネットワークアクセス、必要なインフラのみを提供しているとして、追加の解決策は提示できないと回答した
- Linodeはログの提供を受けたが、サービスに影響する違法活動は観察できなかったとしてチケットを終了した
- 運営側は、ドイツ警察の要請に基づく合法的傍受として、HetznerとLinodeが設定を強制されたという見方に重きを置いている
- 別の可能性として、HetznerとLinode双方の内部ネットワークへの侵入がjabber.ruを狙って発生した可能性もあるが、これははるかに信じがたく、完全に不可能ではないシナリオとして残る
1件のコメント
Hacker News のコメント
ロシアのサイバー犯罪捜査に関連していた可能性が非常に高そう。Krebs を読んでいたり、もっとアンダーグラウンドなロシア系フォーラムを見たことがあれば、xmpp.ru には見覚えがあるはずで、実際そういう文脈がある。
運営者に何かをなすりつけようとしているわけではなく、匿名サービスを運営するとこういう性格を帯びるという意味。
https://ddanchev.blogspot.com/2021/03/exposing-currently-act...
https://ddanchev.blogspot.com/2019/07/profiling-currently-ac...
https://blog.talosintelligence.com/picking-apart-remcos/
https://flashpoint.io/wp-content/uploads/Plea-Agreement-USA-...
記事自体は本当に興味深く、誰もが証明書透明性モニタリングサービスを使うべきだという実践例に見える。
緩和策の提案の大半には同意する。高リスク対象なら、信頼された認証局に依存しない認証レイヤーを追加で重ねることも検討に値する。Tor onion services、SSH、WireGuard などだ。
発行されたすべての SSL/TLS 証明書が証明書透明性の対象だという点には同意するし、crt.sh には RSS フィードもある。
CAA を使うのは一般には良い考えだが、このケースでも役に立つかは疑問。攻撃者は CAA で許可された正確な証明書構成を要求すればよいからで、特定の検証方式をより強く制限できるなら役立つかもしれない。
すべてのサービスの SSL/TLS 証明書変更を外部サービスで監視すべきだという点にも同意する。高リスク対象は、どの証明書が有効なのかを常に把握し、点検しておくべきだ。
デフォルトゲートウェイの MAC アドレス変更を監視する方法については、より洗練された攻撃なら MAC アドレスをそのまま維持できる。
XMPP の「チャネルバインディング」が、有効な証明書を提示する中間者攻撃も検出できるというのは初めて知った。
もちろん、ネームサーバーが DNSSEC で保護されていることが前提です。そうでなければ、認証局が照会する際の DNS リクエストも傍受され得ます。
セキュリティ上の注意点全体は RFC 8657 を見れば分かります。この RFC は通常の RFC より読みやすいように設計されています。
背景説明を載せた私のブログ記事: https://www.devever.net/~hl/acme-caa-live
実際の中間者攻撃を完璧にやり遂げておきながら、証明書の更新を忘れたのだとしたら、それはかなりドイツらしいことだ :-)
あるいは、誰かが命令を非常に忠実に守っただけかもしれない。証明書を設定せよという命令はあったが、自動更新しなければならないという要件はなかった、ということ :)
アーカイブ: https://archive.ph/C0jYJ
いくつかの説が興味深く、事実なら証明書をどう取得したのかを説明してくれる。ここから得られる教訓は、複数のプロバイダーに複数のプローブを置き、すべての TLS フィンガープリントを確認し、未知のフィンガープリントが現れたら通知を受け、証明書透明性ログの有無まで確認することかもしれない。
openssl s_client -servername news.ycombinator.com -connect news.ycombinator.com:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdinSHA1 Fingerprint=7E:49:BA:40:86:87:B3:39:66:93:94:9E:9C:45:71:85:3C:8D:95:16発行されたすべての SSL/TLS 証明書は証明書透明性の対象なので、Cert Spotter のような証明書透明性モニタリングを設定し、ドメインに新しい証明書が発行されたらメール通知を受けるのがよい。
RFC 8657 の CAA レコード拡張、つまり Account URI と ACME Method Binding で検証方法を制限し、新しい証明書を発行できる正確なアカウント識別子を指定すれば、他の認証局・ACME アカウント・検証方法によるドメイン証明書の発行を防げる。
外部サービスですべてのサービスの SSL/TLS 証明書変更を監視し、デフォルトゲートウェイの MAC アドレス変更も監視すべきだ。
MACアドレスがローカル管理アドレスではなかったので、少し気になった。誰かがこのアドレス範囲を意図的に選んだ可能性がありそうだった
https://www.google.com/search?q=%2290%253Ade%253A01%22+linod...
"90:de:01" linodeと"90:de:00" linodeで検索してみると、最近このブロックのアドレスがほかの Linode VM にも割り当てられていたように見える。今すぐ直接比較できる Linode VM はないが、トラフィックが Linode インフラ上の別の VM にルーティングされたように見える根拠のない推測だが、Jabber が標的になったのは、ダークネット市場で麻薬取引やその他の違法活動に有名に使われているからだと思う
「暗号化されているから大丈夫」とだけ信じてはいけないことを示している。少なくともメッセージは PGP で暗号化すべきだ
PGP が量子コンピュータで破られ得るのか、今後そうした攻撃への強化が出てくるのかも気になる。暗号化された形でメッセージが大量収集されていたなら、最終的に解読は時間の問題になり得る
そして、入手できるほぼすべての Web トラフィックでこういうことが起きているように見える。https://en.wikipedia.org/wiki/Utah_Data_Center を参照
もちろん、インターネット上の匿名の麻薬売人と安全に鍵交換するのはミスしやすい
https://therecord.media/genesis-market-takedown-cybercrime
PGP には多くの問題があり、避けるよう勧める人も多い。例: https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ / https://news.ycombinator.com/item?id=20455780
OMEMO、OTR、PGP のようなエンドツーエンド暗号化通信は、双方が暗号鍵を検証した場合にのみ傍受から保護される。攻撃者は使われた エンドツーエンド暗号化方式 ごとに別個の中間者攻撃を構成する必要がある
私が見た一部の XMPP クライアントは、特定の暗号化アイデンティティを明示的に検証済みだと表示しない限り、使えないようにしていた
それでも良い注意喚起だ。途方もなく長い数字やそれに準ずる値を見て処理したことがないなら、エンドツーエンド暗号化が実際に成立しているとは考えにくい
この話で理解できない部分が1つある。合法的傍受だとしたら、Hetzner と Linode はなぜ別の LE 証明書と鍵で 中間者傍受 を設定したのだろうか
VPS の RAM やストレージから TLS 秘密鍵を直接抽出すればよかったはずだ。物理専用サーバーでも、予告なしの再起動後に RAM ダンプを取って秘密鍵を抜き出せる
秘密鍵の抽出は CT ログに現れないので、はるかに秘匿性が高く、実質的に検出が難しい
もう1つの可能性は、一方は「捜索」で、もう一方は「傍受」なので、承認レベルが違ったのかもしれないということだ。ただし現在のドイツの法的状況はよく知らない
法執行機関にとってはあまりに標準的な手法に聞こえるので、そういう機器が既製品として存在していそうだ
あるユーザーが3日前に Reddit にすでに投稿していた: https://www.reddit.com/r/hetzner/comments/17ankoh/does_hetzn...
Hetzner/Linode にこの状況についてコメントを法的に要求する方法があるのか気になる。傍受の背後には、何らかの政府機関や警察がいる可能性が高そうだ
逆に合法的傍受でないなら、Hetzner が許可したとは思えない。それも法律違反だからだ