SSHのバックドア
悪意のある、または不正に操作されたメンテナーが、ライブラリに悪意のある動作を挿入しました。 liblzmaこれは、xz圧縮ツールおよびライブラリの一部であり、SSHにバックドアを仕込む結果となった。ライブラリはバックドアのために意図的に改変されており、攻撃ペイロードをレビュー担当者から隠蔽するための難読化およびステルス技術が用いられているため、高度なソフトウェアサプライチェーン攻撃である。
これは最近（3月29日過ぎ）発見され、公表されました。攻撃への対応は現在も進行中です。しかし、限られた環境（x86_64アーキテクチャのDEBおよびRPMパッケージ、GCCでビルドされたもの）のプレリリース版のみに影響すると思われるため、迅速に封じ込められました。いずれにせよ、 CVE 与えられた CVSS基本スコア 10段階中10段階目は、最も重大なサイバーセキュリティの脆弱性に対してのみ使用される。これが安定版の配布に組み込まれた場合、その影響は計り知れないものとなるだろう。
攻撃の技術的分析には、 xzバックドアの詳細解説この件については、他の場所で分析されています。この記事では、攻撃のタイムライン、どのように検知できたか、現在までの対応状況、そしてこの攻撃から得られる教訓に焦点を当てます。
バックドアの長い影響は、最初のパッチ適用後も長く続いている。2025年8月、CVE-2024-3094が公開されてから1年以上経った時点で、Binarlyのセキュリティ研究者は、Docker Hubに公開されている12個のDebian Dockerイメージにバックドアがまだ存在していることを発見した。Debianチームは、これらをアクティブなリスクではなく、過去の開発の遺物として扱い、削除を拒否した。また、 OpenSSF また、OpenJSはXZ事件の直後に共同で警告を発し、同様のソーシャルエンジニアリングによる乗っ取り未遂がすでにJavaScriptプロジェクトを標的にしていることを指摘し、ここで使用されたメンテナー信頼攻撃のパターンが他の場所でも再利用されている可能性を示唆した。
XZバックドアがどのように注入されたか
注: Gitリポジトリは git.tukaani.org。 しかし、 また、 GitHubでホストされているリポジトリ （現在ブロックされています）GitHubアカウントが変更内容を投稿し、それが後にGitリポジトリに統合されました。
バックドアの一部は、5.6.0 および 5.6.1 バージョンの配布 tarball にのみ含まれており、git リポジトリには含まれておらず、 build-to-host.m4 の単一行 autoconfで使用されるマクロファイル。残りの部分は、2つのテストファイルと思われるファイルの中にありました。 bad-3-corrupt_lzma2.xz (NAIST) と good-large_compressed.lzma
それは commitテッド GitHubアカウント「Jia Tan」による（JiaT75） の中に xzリポジトリ 2月23日に、テストファイル（おそらく.lzmaと.xz圧縮ブロック）を追加するという無害な変更が行われました。興味深いことに、テストファイルはテストで使用されませんでした。.m4ファイルの行は、いくつかの条件が一致する場合にconfigureの最後に実行される難読化されたスクリプト（tarballに含まれています）を挿入します。これはMakefileを変更します。 liblzma ライブラリには、難読化解除後に.xzファイルからデータを抽出するコードが含まれます。 このスクリプトではは、configure の最後に呼び出されます。ビルドプロセスを変更してコードを挿入するかどうかを決定します。GCC と GCC リンカーの場合のみ、Debian または rpm の場合のみ、x86_64 Linux の場合のみ有効です。一致すると、挿入されたコードは 2 つのコードを置き換えることで実行をインターセプトします。 ifunc リゾルバーによって特定の呼び出しが置き換えられます。これにより、メモリ内でシンボルテーブルが解析されます（これには時間がかかり、後述するように検出につながりました）。
ここからが興味深いところです。バックドアは動的リンカーに監査フックをインストールし、RSA_public_decrypt関数シンボルが到着するのを待ちます。このシンボルはバックドアコード内の特定の箇所にリダイレクトされ、そこからコールバックが実行されます。 libcryptoおそらく通常の認証を実行するためでしょう。そして、実行中のプログラムがプロセス名を持っている場合にペイロードがアクティブになります。 /usr/sbin/sshdSSHサーバーが標的であることは明らかだった。従来、 sshd OpenSSHのようなサーバーはリンクされていません liblzmaしかし、sshdは よくパッチを当てる systemd-notifyをサポートして、sshdが実行されているときに他のサービスを開始できるようにします。そして、liblzmaは間接的にロードされます。 systemdこうして円環が閉じる。
バックドアはまだ完全に分析されていませんが、 リモートコマンドの実行を許可する （RCE） sshdデーモンの権限で事前認証コンテキストで実行されます。リモート証明書からの情報は、バックドアによって一致すると、ChaCha20で復号化され、復号化が成功すると、 システム（）つまりこれは実質的にゲート付きリモートコード実行（RCE）であり、単なる公開鍵バイパスよりもはるかに悪質です。
後の5.6.1 tarballでは、痕跡を隠すための追加的な取り組みが見られ、シンボル名にさらに難読化が施され、見つかったエラーの修正が試みられた。 伸縮機構 バックドアに追加するための特定の署名を探すための追加のテストファイルも設置された。
このかなり高度な攻撃は、安定したLinuxディストリビューションが登場するまで気づかれずに済む可能性がある。幸いなことに、異常事態が発生した理由を突き止めようとする人々は存在する。
XZバックドア攻撃の発見
多くの場合、注入された悪意のある動作は偶然または事故によって発見されます。良い例は、 非推奨警告 （「警告なんて誰が気にするんだ？」）が発見につながった イベントストリーム攻撃 2018年10月。もう1人は、警告したユーザーです。 コードコフ 2021年4月、彼らのbashアップローダースクリプトがチェックサムに合格しなかった（「誰がチェックサムで成果物の整合性を検証するのか」） SSH接続時の異常と奇妙な症状 loginS（logins は多くの CPU を消費し、経過時間が増加し、valgrind エラーが発生し、 アンドレス・フロイントPostgreSQLの開発者としては用心深いが、セキュリティアナリストではない（本人はそう述べている）。Debian Sid 上の OpenSSH で調査を行った結果、応答時間の問題がライブラリに依存していると結論付けました。 liblzmaの一部 xz-ユーティリティ 圧縮ライブラリ。理由：「上流のxzリポジトリとxz tarballにはバックドアが仕掛けられています。この診断は非常に正確でした！ 2024年3月29日、アンドレスはOpenwallに最初の分析を投稿した。「アップストリームのxz/liblzmaに存在するバックドアにより、SSHサーバーが侵害される可能性がある。事実：XZ Utils 5.6.0および5.6.1のtarballにはバックドアが含まれています。これらのtarballは、前述のJia Tanアカウントによって作成および署名されました。 He Mastodonに投稿されました その日の後半、この発見は偶然の産物であり、多くの偶然が重なった結果であると認識した。他のユーザーからのコメントは一読の価値がある。 GitHub ユーザー thesamesam （別名サム・ジェームズ）が素敵なGistを公開しました xz-utilsバックドアに関するFAQ 攻撃の概要がまとめられ、さらに詳しい情報へのリンクが掲載されている。 詳細な分析 攻撃ペイロードの。 これらの分析は技術的に非常に興味深く、高度に精緻化された注射についてより深く理解するのに役立った。- xz/liblzma: Bashステージ難読化の説明インジェクションスクリプトによる難読化解除に関する、4つの「段階」に分けた素晴らしい分析です。
- フィリッポ・ヴァルソルダの青空スレッド RSA_public_decrypt のバックドア自体を分析した結果、その性質が明らかになった。それは RCE であり、認証バイパスではなく、ゲート付き（作者の秘密鍵を受け入れ、そうでなければ通常の動作に戻る）で、返済不可能である。作者は検出を避けるために目立たないように行動しようとしていたのだ。
- @smx-smxによるXZバックドア分析（作業中） – バックドアに関する追加分析（最初の方でほとんど分からなくなってしまいました😀）
- xzバックドアのドキュメントwiki5.6.1インジェクションスクリプトの別の分析。
事件への対応方法
アンドレアス・フロイントによる情報開示は慎重なものであった。彼自身の言葉によれば、その理由は以下の通りである。「上流の関与が明らかであるため、上流のバグを報告していません。当初は Debian 固有の問題だと思っていたため、より予備的なレポートを security@...ian.org に送信しました。その後、distros@ に問題を報告しました。」 CISAは配布元から通知を受けた。
誰が攻撃を受けているのか？
GitHubのJiaT75アカウントが侵害されたか（GitHubは最近2段階認証を義務付けたばかりである）、あるいはアカウント所有者がサイバー攻撃に手を染めたかのどちらかだろう。しかし、攻撃の技術的な高度さから、国家支援を受けた可能性のある高度な持続的脅威（APT）攻撃を疑うに足る説得力のある理由がある。サイバーセキュリティ機関や法執行機関によるさらなる調査で真相が明らかになるだろう。 このエントリー Y Combinator Hacker News の Jia Tan に関する記事 犯人とその活動について、ある程度の情報を提供してくれます。おすすめです！悪者がソーシャルエンジニアリングを使って他のユーザーを騙そうとする手口について、多くの情報が得られます。「非常に迷惑な話です。バックドアの作成者と思われる人物が、数週間にわたり私（rwmj）と連絡を取り合い、『素晴らしい新機能』があるという理由で、xz 5.6.xをFedora 40と41に追加してもらおうとしていました。私たちは彼と協力してvalgrindの問題を修正しましたが（後に判明したところによると、これは彼が追加したバックドアが原因だったようです）、昨晩はうっかり情報公開禁止を破ってしまったため、急いで修正しなければなりませんでした。彼は2年間xzプロジェクトに参加し、あらゆる種類のバイナリテストファイルを追加してきました。正直なところ、これほど高度な技術を持っている人物には、他に証明されるまでは、古いバージョンのxzでさえ疑わしいと感じます。」
Jia Tanは追跡されないように対策を講じており、VPN（vpn.singapore.witopia.net）を使用して接続しているようです。これはそれ自体は問題ありません。また、多くの変更は、変更のマージを促す一時的な使い捨てメール（この場合はProtonMailから）によって裏付けられているようです。
その俳優は、Linuxカーネルにまでさらに深く入り込むつもりかもしれない。 xy埋め込み プロジェクト。本日現在、初期分析では流産の兆候は認められませんでした。
注：別の 目立たないXZ寄稿者「ハンス・ヤンセン」 （GitHubユーザー「hansjans162」）は 精査の下でDebian のアカウントは現在 ブロックされた彼は、debian/xz-utils に望むものを隠すために Debian Games に多くの更新を行い、バックドアの配布を急ぐために上流の 5.6.1 を更新した。 debian/unstable.
現時点で言えることは、これは（まだ特定されていない）APT攻撃であり、複数のアカウントを使用し、少なくとも2年間この攻撃キャンペーンに取り組み、SSHにリモートコード実行（RCE）を仕込むために根気強く作業しているということだけです。
本稿執筆時点では、「賈丹」の正体は未だ確認されていない。特定の個人、組織、あるいは国家主体への帰属を示す信頼できる証拠は公には確認されておらず、この人物像の活動規律がいかに効果的であったかを改めて示している。
XZのバックドア攻撃は防ぐことができたのだろうか？
かなり難しい。
まず、注入されたバックドアの一部が、テストで使用されていない圧縮テストファイルに紛れ込んでいました。後から考えると、これは（過剰な）警告を発するかもしれませんが、実際のテストで全てのテストファイルが使用されているかどうかを確認することなど、現実世界では誰も気にしません。次に、注入されたバックドアの一部が、リリース用tarball内のマクロファイルに紛れ込んでおり、期待されるtarballとの違いを手動で確認するのは困難です。自動化も複雑で、（automake/autoconfの仕組みを知っている人ならわかるように）ビルド自体から期待される結果をモデル化して、実際のtarballが期待値と一致するかどうかを分析するのは困難です。 それを問いかける人もいた as 「gitツリーとtarballが一致しないのは仕様であり、バグではありません」ソースコードからバイナリtarballの出所を特定することは、未解決の問題である。
ユーザーの評判は？まあ、過去の記録を見る限り、JiaTan75のGitHubアカウントは不正行為をしていなかったようだ。 commit証拠が集まった後に停止されたが、3月29日までは、通常の業務を行う常連ユーザーだった。まあ、それほど普通ではなかったが。 commitS（この, この, この, この （エクスプロイトコードを調整した）は、バックドアが想定するスタックレイアウトとの違いにより、一部の構成で発生するvalgrindのエラーやクラッシュを修正しようと試みました。 Commit レビューでこれを検出することは可能だが、バイナリテストファイルの変更点や、Cソースコード内のGCC属性の変更の真の動機を分析する忍耐力のある人はどれくらいいるだろうか？
SSHが login 300 ms ではなく 800 ms かかる？おそらく超慎重な人だけが気づくでしょう。キケロはこう言いました。 「無鉄砲さは若者のもの、慎重さは老人のもの。」
ifuncインフラストラクチャは、2023年6月に「Hans Jansen」と「Jia Tan」によって追加されました。これは最初の commit crc64_fast.cにifuncサポートを追加（後にバックドアの注入に使用）。テストファイルにバックドアバイナリを注入する数ヶ月前のこと！
注：著者と commitここで意見が分かれるかもしれないが、これは普通のことだ。ラッセ・コリンはプロジェクトのメンテナーであり、変更をマージした。彼は「ハンス・ヤンセン」に感謝の意を表している…
アンドレス・フロイント氏の投稿とRed Hatが作成したCVEが発表されるまで、誰も懸念を表明していませんでした。この問題を検出できるツール群があれば、影響を受けるコンポーネントを現在検出できます。 事後.
おそらく最も効果的な予防策は、Linuxディストリビューションの性質、つまり不安定な最新バージョンが、段階的なプロセスを経て安定版ディストリビューションへと移行していく仕組みにあるだろう。
XZバックドア攻撃から得られた教訓
検出がいかに難しいか、私たちは指摘しました 意図的 バックドア。バックドアは内部の脅威とみなすべきです。なぜなら、内部スタッフによって、あるいは侵害された内部アカウントを介して仕掛けられるからです。そして、そうしたスタッフは概して信頼されている存在です。さらに、バックドアが分散型成果物に組み込まれると、検出がより困難になります。
ケビン・ボーモントのような作家もいる を指さした これにより、サードパーティサービスのバックドアへの攻撃対象領域が大幅に拡大します。悪意のある攻撃者はこれを悪用しました。Systemdは多くの注目を集めていますが、XZはチェーンの上流にあるあまり知られていないライブラリです。「上流が汚染されると、下流の誰もが毒された水を飲むことになる」のです。
システム内の無関係な変更要求 圧縮ライブラリを動的にロードします。バックドアを削除する修正プログラムは既にシステムに組み込まれているが、まだ配信されていない。 libsystemdによって導入される追加の依存関係が脆弱性の原因となる可能性がある。、そして昨日 このリクエストが開始されました.
A コメント 「xz: 問題を解決するために ifunc を無効にする」 commit このような活動を阻止したいのであれば、どこに重点を置くべきかについて鋭い洞察を与えてくれた（強調は筆者による）：
「コミュニティとして学ぶべき教訓は、 software supply chain security 包括的に監査するには、ソースコードだけでなく、ビルドシステム全体を監査する必要があります。例えば、SolarWindsの侵害事件では、攻撃者がSolarWindsのクローズドソース監視ソフトウェアのソフトウェアアップデートを改ざんしました。
FAQ
XZのバックドアは、今日でも依然としてリスクとなるのでしょうか？
ほぼ封じ込められているものの、完全には排除されていない。2025年8月、研究者らは、Debianが非アクティブな過去の遺物として扱っている複数のDebian Docker Hubイメージに、依然としてバックドアが存在することを発見した。チームは、2024年のパッチで完全にバックドアが閉じられたと安易に考えるのではなく、古いパッチ未適用のベースイメージをベースに構築していないことを確認する必要がある。
