本記事は4月10日9:00（JST)時点で判明している事実をまとめたものです。誤りがあればコメントでお知らせください。
本記事には誤りが含まれている可能性があります。
新しい情報があれば随時更新します。

4/10 9:15 キルスイッチの動作について追記しました。
4/2 18:30 Q&Aを追加しました。
4/2 11:30 実際にバックドアが存在する環境を作成し、攻撃可能なこと、出力されるログ等について追記しました。また、攻撃可能な人物は秘密鍵を持っている必要があることを追記しました。

ところどころに考察を記載しています。
事実は～です。～であると断定し、考察、推測、未確定情報は考えられる、可能性があるなどの表現としています。

またpiyokango氏のまとめ、JPCERT/CCの注意喚起もご覧ください。

なお、各国のCSIRTまたは関連組織による注意喚起の状況は以下のとおりで、アドバイザリを出している国は少ない状況です。

概要

問題の概要

xz-utilsというOSSのコードにバックドアが仕込まれ、複数のLinuxディストリビューションに対して配布されるというインシデントが発生しました。
このバックドアにより、リモートからroot権限で任意のコマンドが実行される可能性があります。ただし実行には攻撃者が持つ秘密鍵が必要となり、攻撃できる人物は非常に限られます。

影響を受けるバージョンはxz 5.6.0 および 5.6.1です。このバージョンを使っている場合は直ちに5.6.1+really5.4.5-1にアップデートしてください。
（対策済みバージョンの名称はディストリビューションによって異なる可能性があります。）
なお、該当するバージョンをインストールした時点で悪意のあるコードがすでに実行されてしまっているようで、万全を期す場合はOSの再インストールを行った方が良い可能性があります。
アップデートのみで安全な状態になるかどうかは検体を完全に解析する必要があり、まだ数日はかかることが予想されます。特にセキュリティに配慮する必要があるシステムにおいてこの問題が発生している場合は、OSの再インストールを検討した方が良いかもしれません。

なお、影響があるディストリビューションおよびバージョンはかなり限定的であり、ごく最近にOSを新規にインストールしているか、xzまたは関連するパッケージのアップデートを特定のディストリビューションで行っていない限りは影響はないと考えられる。

何らかの理由でアップデートが困難な場合は、以下の緩和策を実施してください。
以下のコマンドを実行することでバックドアが動作しなくなることを確認しています。

sudo systemctl set-environment yolAbejyiejuvnup=Evjtgvsh5okmkAvj
sudo systemctl restart ssh

影響を受けるバージョン

Debian unstable (Sid)
https://lists.debian.org/debian-security-announce/2024/msg00057.html

Kali
https://www.kali.org/blog/about-the-xz-backdoor/

Arch Linux
https://archlinux.org/news/the-xz-package-has-been-backdoored/

上記3点は以下から引用
https://www.cyberkendra.com/2024/03/major-linux-distributions-impacted-by.html

上記以外でも影響を受ける可能性があります。
また、macOSのbrewでもインストールされたという報告があります。ただし後述する「liblzma_la-crc64-fast.o」がLinux向けに書かれていると思われるため、macOSでは動作しないと推測されます。

また後述するバックドアの確認方法によると、ホストがLinuxであることが条件であるため、macOSでは動作しないと考えられます。

影響を受けないバージョン

Amazon Linux（AWS）
https://aws.amazon.com/jp/security/security-bulletins/AWS-2024-002/

影響を受けるバージョンor受けないバージョンについては以下も参照することを推奨
https://nvd.nist.gov/vuln/detail/CVE-2024-3094

Q&A

X（Twitter）上で見かけた疑問点をまとめました。
なお、断定してないもの（～と考えられる等）は筆者による考察であり、事実とは異なる可能性があります。

macOSは影響を受けるか？

筆者は検証環境を持っていないため確認できていない。ただし、検体解析の結果を見る限りLinuxでのみ動作すると考えられる。また、現時点では外部から攻撃するためにはsshdが動作している必要があると考えられ、通常のmacOSの使い方であれば影響はないと考えられる。

xz 5.6.0または5.6.1を使っておりアップデートしたが、これでバックドアは削除できているか？

筆者が検証した限り、バックドアは機能しなくなっている。sshdの再起動も不要だった。
ただし、悪意のあるコードがメモリ上に残っている可能性はあり、sshdもしくはOSの再起動を行うことが望ましいと考えられる。

xz 5.6.0または5.6.1ではないバージョンを使用している。これは攻撃されていないと言って良いか？

高い確率で攻撃されていないと考えられる。ただし、攻撃者はroot権限で任意のコマンドが実行可能であり、xzのバージョン偽装することができるため、100%安全とは言い切れない。高い安全性が求められる環境であり、万全を期す必要があるならOSの再インストールを行った方が良いと考えられる。

攻撃の有無を確認することは可能か？

極めて難しいと考えられる。筆者が検証した限り、攻撃が成功してもデフォルトの設定でログが残ることはなく、SSHが暗号通信を行う性質上、途中経路上のIPS/IDSなどで検知することも難しいと考えられる。
なお、攻撃者がコマンドを実行している間にのみ、通常とは異なるプロセスツリーでプロセスが実行されることを確認したため、EDRのようなホスト上のプロセスを監視できるソフトウェアがあれば、確認できる可能性がある。
また、メモリフォレンジックにより確認できる可能性はあるが、終了したプロセスがどの程度残っているか不明であることと、メモリフォレンジックを行うためにはカーネルバージョンごとにシンボルテーブルを作成する必要があり、容易ではない。なお、構築した検証環境を用いてシンボルテーブルの作成を試みているが、現状では成功していない。

xz -Vのような方法でバージョン確認をしない方が良いか？

xzが悪意のあるコードによって侵害されていることから、一般的にはやめた方が良いと考える。ただし、今回に関しては、以下の2点からxz -Vでも問題ないと考える。

問題があるバージョンであっても正しいバージョンが表示されること
理論上、攻撃者はバージョンの偽装も可能だが、攻撃できる人物は秘密鍵を持っている必要があり、事実上バックドアの作成者のみである。世界中のサーバの中からバックドアのあるサーバを見つけ出し、バージョンを偽装するのは容易ではないこと

該当するバージョンのxzを使用しているが、サーバをインターネットに公開していなければ安全か？

少なくとも現時点で判明している攻撃経路はSSHのみであるため、インターネットからSSHのサービスにアクセスできない状態であればかなり安全であると考えられる。仮に攻撃者が何らかの方法で内部ネットワークに侵入していたとしても、本攻撃手法を悪用可能なのは秘密鍵を持つ人物のみであり、実際に悪用される可能性は低いと考えられる。

この脆弱性はどの程度ヤバイか？

現時点で判明している情報からは、実際に影響があるシステムは極めて少ない上に、攻撃には対応する秘密鍵を持っている必要があるため、実際に攻撃される恐れはほぼないと考えられる。ただし、実際に攻撃されたとしても攻撃痕跡を確認することはほぼ不可能であることから、早急にxz-utilsのアップデートを行うべきである。

これは脆弱性なのか？

攻撃可能なセキュリティ上の問題個所であり、リモートから任意のコマンドが実行可能であることから、脆弱性と言えると考えます。しかし、悪意のあるコードが意図的に挿入されていることからセキュリティインシデントともいえると思います。
なお、CVSS値は10.0とされていますが、個人的にはこの評価には疑問があります。（次項で解説）

アップデートによる影響が未知数のためどうしてもアップデートできない。どうしたら良いか？

アップデートによる影響以上にバックドアが混入しているバージョンを動作させる方が遥かに危険だと思いますが、どうしてもという場合は本記事のキルスイッチによる無効化の手順を実施してください。

CVSS値について

CVSS値は、「CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H」とされていますが、個人的にこれには疑問があるため本項で考察します。疑問がある点はS:Cです。この脆弱性（脆弱性と言ってよいかは微妙な部分もありますが、ここでは脆弱性であると仮定します）はスコープが変わるとは考えにくいです。スコープが変わる脆弱性の典型例はXSSです。これは問題個所がウェブアプリケーションなのに対し、攻撃による影響がブラウザに及ぶため、スコープが変わります。一般的なRCEは通常スコープが変わることはありません。

例えば以下の脆弱性はリモートからコマンド実行ができる典型的なRCEです。スコープの変化はありません。

なお、CVSS3.1のドキュメントのスコープに関する個所には以下のような記述があります。

An exploited vulnerability can affect resources beyond the security scope managed by the security authority of the vulnerable component. In this case, the vulnerable component and the impacted component are different and managed by different security authorities.

Google翻訳

脆弱性が悪用されると、脆弱なコンポーネントのセキュリティ権限によって管理されるセキュリティの範囲を超えてリソースに影響を与える可能性があります。

以上により、この問題は当該システム以外への影響を与えないことから、S:Uが正しい評価であり、CVSS値は9.8が正しいのではないかと考えています。

タイムライン

本件は約2年半前から準備が行われていた攻撃であると考えられる。詳細なタイムラインが以下に記載されている。

上記から特に重要なイベントを抜粋する。
本項では悪意のあるコードを挿入したJia Tanのアカウントは攻撃者と記載する。ただしJia Tan自身が攻撃者であるとは限らず、アカウントの売買や乗っ取りなどの可能性があることに注意。

タイムラインはかなり長く複雑であるため、特に重要なものだけを抜粋したため、途中大幅にカットしている箇所がある。以下で流れを把握した上で原文を参照することをお勧めする。

日時	イベント
2021年10月29日	攻撃者が最初の無害なパッチをxz-develメーリングリストに投稿した。これ以降複数回にわたって無害なパッチを提供している。
2022年4月22日	Jigar Kumarが攻撃者の無害なパッチが配信されないことについてクレームをメーリングリストに投稿した。以降、Jigar Kumarが複数回類似のメールを送信している。なお、メンテナーであるLasse Collinはこのころから精神健康上の問題でプロジェクトの作業を進めることが難しい状況だったもよう。
2022年6月29日～9月27日の間	攻撃者がメンテナーに就任した。
2022年12月30日～	攻撃者は複数回にわたってxzの改良（無害）を行った。
2023年6月22日以降	Hans Jansenはバックドアにも利用できる変更を行った。これ単体では高速化に見えるが、のちにバックドアを挿入する際に重要な役割を果たす。これ以降も無害だがバックドアで利用するための機能を追加している
2024年2月23日	バックドアのコードをマージした。バックドアのコードはファイル処理のテストをするためのファイルにバイナリデータとして挿入されており、発見が困難であったと考えられる。
2024年2月24日	5.6.0としてビルドされる。（この時点ではバグがあり、のちに5.6.1がビルドされる）
2024年2月26日	Debianがxz-utils 5.6.0-0.1を不安定版に追加する。
2024年3月末	5.6.1に更新するためのバグ報告をDebianおよびUbuntuに行う。この時Debianに報告したのはHans Jansen、Ubuntuに行ったのは攻撃者だった。
2024年3月28日	バックドアが発見される。Debianは5.6.1をロールバック、翌日にOpenwallから告知される

上記流れから以下の点が考察できる。

Jia Tanは悪意のあるコードを挿入した攻撃者であるが、Jigar KumarやHans Jansenもまた攻撃者あるいは協力者であると考えられる。同一人物によるなりすましの可能性もある。
バックドア本体ははバイナリデータとして挿入されており、今回は運良く発見できたものの、コードレビューで発見することは困難であったことが予想される。

技術的な詳細

xzのバージョンを確認する際の注意点について

xz --versionでバージョンを確認できるが、侵害されたバイナリを動作させるのは危険であるため例えば以下のような確認方法が推奨されている。

他にもxzのバイナリをstringsで処理し、バージョンをgrepするなど複数の方法が提示されている。

しかし、以下のポストによると該当するバージョンをインストールした時点ですでに侵害されたコードが実行されてしまっているとのこと。このため該当するバージョンがインストールされている場合はOS再インストールを検討した方が良いかもしれない。

※理論上攻撃者は任意のコードを実行可能であるため、バージョンを偽装することも可能である。そのため影響がないことを確実に確認する方法は事実上ないかもしれない。ただし検体解析が完全に終わっていないため、攻撃者がどこまでの操作が可能か、どういった意図があるコードかはまだ不明である。

バックドアが仕込まれた経緯

xzのメンテナはLarhzuとJia Tanの2名で、このうちJia Tanが署名、リリースしたバージョンが5.6.0 および 5.6.1で影響を受けるバージョンであった。
つまり、Jia Tanが攻撃者であり悪意を持ってバックドアを仕込み、署名してリリースしていると考えられる。

以下はLarhzuによって公開されているページ
https://tukaani.org/xz-backdoor/

Jia Tanは3年ほど前からいくつかのOSSプロジェクトで貢献を行っており、信頼を得た上で悪意のあるコードを仕込んでいた。

なお、Jia Tanという名前のアカウントが攻撃者であるが、Jia Tanという人物が攻撃者かどうかは不明である。アカウントの売買が行われた可能性、アカウントが侵害された可能性などがあるため、本記事ではJia Tanおよび攻撃者に関する調査は基本的に最低限にとどめている。

バックドアに関するコードの一部が以下で紹介されていた。

続くポストで解説されているとおり、「#include 」の次の行に「.」が書かれている。
これによりコンパイルに失敗させることで、サンドボックス環境を無効化するという巧妙な手口である。
これを人間が目視レビューで発見することは不可能に近いと考えられ、何らかの機械的な手法を用いたレビューを併用する必要があると考える。

なお該当箇所は以下にある。

バックドアの確認方法

以下の条件を満たす場合、バックドアが動作していると判断できるとのこと。

またこのバックドアが動作する際にはCPUが高負荷になる仕様（シンボルテーブルの解析を行う）であるとのこと。

仕込まれたバックドアの詳細

執筆時点で解析中の部分があるが、わかっている範囲を記載する。

大まかな動作の流れは以下で説明されている

より詳細な解析結果は以下に記載されている

上記によれば最終的に「liblzma_la-crc64-fast.o」が生成されるとのこと。

「liblzma_la-crc64-fast.o」で検索したところ、生成されたと思われる検体を複数確認した。なおファイル名については記事によって若干の表記ゆれがあるため、環境によってはファイル名が異なる可能性がある。

検体「212ffa0b24bb7d749532425a46764433」の解析結果
https://any.run/report/cbeef92e67bf41ca9c015557d81f39adaba67ca9fb3574139754999030b83537/993573f4-6ad9-4d90-b35f-a6209f1c80e6
https://tria.ge/240331-bnr8pabf78
VT：https://www.virustotal.com/gui/file/cbeef92e67bf41ca9c015557d81f39adaba67ca9fb3574139754999030b83537

検体「4ec47410372386d02c432ba10e5d7fda」の解析結果
https://tria.ge/240331-asw7rsac7t
VT：https://www.virustotal.com/gui/file/5448850cdc3a7ae41ff53b433c2adbd0ff492515012412ee63a40d2685db3049

上記検体はダウンロード可能だが取り扱いについては十分注意し、自己責任で。
本記事執筆時点ではVTでもそれほど検知できていない。
なお、上記2検体はいずれも筆者がファイル名を検索しただけで、一連の攻撃と関係があるかは不明である点に注意

現時点の予備的な解析結果では、認証バイパスではなくRCE（リモートからのコード実行であるとのこと）

検体についてステップバイステップで解析した結果（おそらく途中経過、プレビューさせると長いのでURLのみとしている）
https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504

検体解析の結果、ペイロードのフォーマットが解析できたとのこと。

上記ポストのリンク先によると、攻撃者の公開鍵を置き換えることで実現しているとのこと。
このため、攻撃可能なのは攻撃者の公開鍵に対応する秘密鍵を持っている人物（通常は攻撃者）のみであり、誰でも悪用できるバックドアではないと考えられる。
また、デモ画面では、RCEの実行権限はrootになっており、本件はリモートからroot権限で任意のコマンドが実行可能であると考えられる（実際の環境とは異なる可能性があるので、間違っていればご指摘ください）

なお不確定情報ではあるもののキルスイッチらしき文字列が発見されている。

他の検体のハッシュ値として以下が確認されている。

検知方法

yaraのシグネチャが公開されている
https://github.com/Neo23x0/signature-base/blob/master/yara/bkdr_xz_util_cve_2024_3094.yar

また前述したとおりおそらく本件に関連しているであろう検体がVTやサンドボックスにアップロードされており、ウイルス対策ソフトによっては検知できる可能性がある。

CrowdStrikeが自社製品を用いて検知する方法を公開している

攻撃者に関する情報

本記事は攻撃者の特定や追跡を目的としていないため、本項についてはリンクの記載に留め、明らかな誤りや重要なアップデートがない限りは更新しません。

以下のスクリーンショットから攻撃者が使っていた可能性があるGmailアドレスが判明している。

なお3月31日夜（JST)時点でこのGmailアドレスを使って作成された可能性があるXアカウントが特定されていた。（当該ツイートは執筆時点で削除されている）
当該アカウント名は「jiat75107」であるが、これが攻撃者のアカウントかどうかは不明。当該アカウントはほとんど活動していないが、攻撃者と関連がある可能性があるため不要にアクセスしないことを推奨する。

実際にバックドアを動作させて検証

検証方法

Kali Linuxのブログで、実際にバックドアを動作させるための環境構築の手順が公開されています。
なお、環境構築にあたっては仮想マシンを使用し、外部からアクセスできない隔離環境で調査することを強く推奨します。

検証にあたり、以下のパッチ(攻撃者の公開鍵を置き換えるパッチ)、POCを使用しました。

実際に検証した結果

検証結果の概要は以下のとおりです。

POCを実行することでリモートからroot権限で任意のコマンドを実行できる。ただし実行には攻撃者の秘密鍵を持っている必要がある。
少なくともデフォルトの設定では各種ログに出力されない。コマンドの実行履歴も残らない。したがって侵害されているかどうかを後から確認することは困難と考えられる。
コマンドの実行中に限り、通常のSSHによるコマンド実行とは異なるプロセスツリーが作成される。このプロセスツリーを検知できれば、現在攻撃が行われているかどうかの確認は可能と考えられる。
メモリフォレンジックで過去のプロセスツリーを抽出できれば過去に侵害されたかどうかを調査することは可能と思われるが、Linuxのメモリフォレンジック自体が難しく、プロセスツリーが長期間残る保証がないので極めて難しいと推測される。

バックドアによる処理時間増加の確認

悪意のあるコード挿入されたバージョン5.6.1を使用し、sshdを起動、存在しないユーザ名でログイン試行した際の実行時間を計測しました。realの値は概ね1秒程度です。

次に悪意のあるコードが除外されたバージョンを使用し、同様に計測しました。概ね0.3秒程度で明らかに悪意のあるコードが動作している場合は時間がかかっています。

次に攻撃者の公開鍵を置き換える以下のパッチを適用しました。

パッチを適用しても悪意のあるコードが動作してる場合と同じ時間がかかっているため、バックドアが動作していると判断できます。

この状態で以下のPOCをビルドし、実行しました。

実行権限について

POCでidコマンドを実行し、root権限でコマンド実行できていることを確認しました。
したがって、悪用すればリモートからroot権限で任意のコマンドが実行できます。ただし、攻撃には攻撃者の持つ秘密鍵が必要です。

POCでcatコマンドを実行し、shadowファイルが見えることを確認しました。root権限であるため当然shadowを含めてすべてのファイルを閲覧、変更、削除できます。

プロセスツリーの違いを利用した検知

POCでsleepコマンドを実行し、プロセスツリーを確認しました。いずれもsshdをハイライトしています
（見づらいですがどちらも右下にあります）

以下はPOCを使用した場合のプロセスツリーです。sshd-sshd-sh-sleepの順でツリーが並んでいます。

以下は通常のsshコマンドを使用してコマンドを実行した結果です。先ほどとは若干異なり、sshd-sshd-sshd-sleepの順です。

上記の違いは検知に役に立つ可能性があります。

メモリフォレンジックによるコマンド実行の特定

メモリフォレンジックでプロセスツリーを取得できれば、過去に侵害されていたかどうかを特定できる可能性はある。ただしメモリ内に長期間プロセスツリーが残っているかは環境に依存することや、Linuxのメモリフォレンジックがかなり難しいことからあまり現実的ではないと考えられる。

今回構築した検証環境のメモリダンプを取得し、Volatility3で解析を試みているが、最新版のKaliのカーネルである6.6.9に対応するシンボルテーブルを作成できていない。挑戦したい人のために途中経過を共有する。

Volatility3のドキュメントにあるとおり、Linuxのメモリフォレンジックを行うためにはシンボルテーブルを作成する必要がある。

シンボルテーブルは以下のツールとデバッグオプションが有効になったカーネルが必要である。デバッグオプションが有効になったカーネルはapt install linux-image-6.6.9-amd64-dbgでインストールでき、/usr/lib/debug/boot/vmlinux-6.6.9-amd64に作成される。

以下のコマンドを実行するが、以下のエラーが出る。~~このエラーについて調査しているが、現時点で回避する方法が判明していない。~~

その後の調査により、デバッグオプションが有効になったバージョン6.6.9は処理できず、別のバージョンであれば処理できることがわかったため、このバージョン固有の問題だと考えられる。

# dwarf2json linux --elf /usr/lib/debug/vmlinux-6.6.9-amd64 
Failed linux processing: could not get DWARF from /usr/lib/debug/vmlinux-6.6.9-amd64: decoding dwarf section info at offset 0x0: too short

ログへの記録

各種ログに本攻撃が記録されるかどうかを確認しました。

前述のとおりPOCによるコマンドはroot権限で実行されていますが、rootのhistoryには記録されていないことを確認しました。したがって攻撃者がコマンドを実行していたとしてもその履歴を追うことはできません。

また、SSHからログインしたログが出るか確認しました。少なくともデフォルトの設定ではログに記録されないことを確認しました。

以下はPOC実行前のlastコマンドの結果です。

以下はPOC実行後のlastコマンドの結果です。

以上からlastコマンドには記録されないことを確認しました。

以下はPOC実行前後のsshdのログを比較したものです。実行前後でログに違いはなく、ログには記録されていませんでした。

キルスイッチによる無効化

キルスイッチとされている「yolAbejyiejuvnup=Evjtgvsh5okmkAvj」を/etc/environmentに追記し、sshdを再起動して検証したが、POCを使ったコマンド実行は成功した。これが環境によるものか、パッチを適用したことによるものか、検証環境の何らかの設定不備かは特定できていない。

その後、X（Twitter）で以下の情報をいただいたため、再度検証した。

ご指摘の通り/etc/environmentではsshdに対して環境変数が設定されていなかった。
正しくは以下の設定が必要であった。

sudo systemctl set-environment yolAbejyiejuvnup=Evjtgvsh5okmkAvj
sudo systemctl restart ssh

上記コマンドを実行後にPOCを実行したところ、以下のようになった。
POCを使って実行したdateコマンドの結果はファイルに書き込まれておらず、直前に検証した際のdateコマンドの結果のままである。POC実行直後にシェルから実行したdateの結果と比較して7分の差があることから、明らかにdateコマンドの実行は失敗している。

なお、存在しないユーザを用いてSSH接続を試みた結果も合わせて記載する。
この結果からも明らかに処理時間が短く、バックドアが動作していないことがわかる。

以上の検証結果から、この環境変数がキルスイッチとして動作していると判断できる。
なお、環境変数の値を1文字削除して検証したところ、POCが有効であり、存在しないユーザによるSSH接続にかかる時間も増加したため、環境変数が完全に一致している必要があることも確認済みである。

参考リンク

現時点で最もよくまとまっていると思われるページ
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

Tenableによるまとめ記事
https://www.tenable.com/blog/frequently-asked-questions-cve-2024-3094-supply-chain-backdoor-in-xz-utils

謝辞

本まとめを作成するにあたり、X（Twitter）上の投稿を多数引用させていただいています。ありがとうございます。引用に問題がありましたら削除しますのでお知らせください。