何が起きたか・対象

Zimbraで、未認証の攻撃者がメールの接続先キャッシュを書き換え、後から接続する利用者のパスワードを受け取れる問題がありました。識別子はCVE-2022-27924です。

Zimbraのプロキシは、利用者名をキーにMemcachedへ接続先を問い合わせます。HTTPリクエストの利用者名に含まれる改行を除かず、行単位の命令へ組み込んだため、攻撃者が改行後の文字列を別のキャッシュ命令として実行させられました。この命令で、対象利用者の接続先を攻撃者のサーバーへ変えられます。 キーはプロトコルとメールアドレスを含むため予測できます。例えばroute:proto=imap;user=victim@example.comというキーの値が接続先です。攻撃者は追加のset命令の対象にこのキーを、保存する値に自分のサーバーのアドレスを指定します。検索に使った元の利用者名と、追加命令が書き換える被害者のキーは同じである必要がありません。

被害者のメールアプリが後からZimbraへ再接続すると、プロキシは変更された宛先へ認証通信を転送し、攻撃者のサーバーが利用者名と平文パスワードを受け取ります。この経路ではIMAPなどの該当する接続が必要で、同じ検索を通らないWebメール利用者全員のパスワードが漏れるという話ではありません。 研究のIMAP経路では、メールアプリが認証のために送った利用者名とパスワードの通信を、プロキシが選んだバックエンドへ転送します。攻撃者がその接続先になれば、受信した認証内容を読めます。「平文の取得」は攻撃者のサーバーで値を読めることを指し、利用者からZimbraまでの全通信が暗号化されていないという意味ではありません。

報告・修正・公開の時系列

2022年に報告・修正され、研究解説は2022-06-14に公開されています。資料が挙げる修正版は8.8.15 P31.1と9.0.0 P24.1です。これは当時の修正情報で、現在の推奨版はサポート状況も含めて確認します。

正常ならどう動くはずだったか

Zimbraのプロキシは、利用者のメールを扱う正しいバックエンドの接続先を調べ、その結果をMemcachedへ保存して再利用します。Memcachedはキーと値を保存するサービスで、この接続先は認証情報を渡す宛先を決めるため、外部から自由に変えられてはいけません。

技術的な原因

Zimbraのプロキシは、外部からのHTTPリクエストに含まれる利用者名をMemcachedの検索キーへ組み込んでいました。改行を除かないまま行単位の通信へ入れると、利用者名の途中で検索命令が終わり、後続の文字列が別のキャッシュ命令になります。攻撃者はその命令で、メール利用者の接続先を記録したキャッシュ値を攻撃者のサーバーのアドレスへ変更できました。 Memcachedへ接続しているのはZimbraのプロキシです。同じテキスト接続で検索も保存・上書きも扱うため、Memcachedは注入された追加命令もプロキシから来た命令として処理してしまいます。

攻撃が成立する条件と流れ

攻撃者はログイン前のHTTPリクエストに、改行と追加のキャッシュ命令を含む利用者名を指定します。既知のメールアドレスのIMAP接続先を書き換える経路では、その後、被害者のメールアプリがZimbraへ再接続して認証することが必要です。プロキシが変更された接続先を採用すると、認証の通信が攻撃者のサーバーへ転送され、攻撃者が利用者名と平文のパスワードを受け取ります。被害者が特別なリンクを押す必要はありませんが、該当するメール接続は必要です。

確認された事実と、想定される影響

研究は、接続経路の変更によって利用者名と平文パスワードを取得する攻撃を実証しています。攻撃者がその資格情報でメールサービスへログインできる構成なら、本人宛てのメールを取得できるおそれがあります。Webメールは同じ経路の検索を通らないため、この経路だけで全てのWebメール利用者のパスワードを取得できるわけではありません。別経路では、同じMemcached接続で処理待ちの検索AとBに対し、攻撃者がA用の応答を余分に生じさせます。プロキシが応答のキーを確認せず順番だけで割り当てると、Bが攻撃者の用意した余分な接続先を採用する場合があります。この共有接続と応答割当ての不備により、事前にBのメールアドレスを知らない経路も報告されています。実験での取得と、実環境での悪用・被害件数は区別します。

実際の修正・対応方針

研究資料は、Memcachedへ送るキーをSHA-256の16進表記へ変える対応を説明しています。その表記には改行が入らないため、利用者名由来の改行で新しい命令を作る経路を断てます。案内された当時の版は8.8.15 P31.1と9.0.0 P24.1です。本番配布差分の全体は直接確認していないため、全変更をこの説明だけで代表させません。

利用者・運用者が確認すること

修正済みのサポート版を確認して更新します。漏えいが疑われる場合は資格情報を失効・変更し、認証やメール接続の履歴を調べます。キャッシュの改ざんを直すだけでは、取得されたパスワードの再利用は止まりません。

開発者への教訓（教材としての考察）

注入はSQLやシェルだけでは起きません。行を区切るプロトコルでも、外部値に含む改行がデータを命令へ変えます。キャッシュの値が後で何の判断に使われるかも追います。

出典・確認範囲

  1. [1] Zimbra Email - Stealing Clear-Text Credentials via Memcache injectionSonar / 確認日 2026-10-29
未確認事項・限界

公的な悪用確認資料との照合を含む追跡は未完了です。被害規模は判断できません。