LinuxにおけるXZ Utilsのバックドアは、より広範なサプライチェーンセキュリティの問題を浮き彫りにしており、これを封じ込めるにはコミュニティ精神だけでは不十分だ

サイバーセキュリティ業界は、ソフトウェアのサプライチェーンにおける悪質な侵害が発見されたことを受け、再び最高警戒態勢に入った。 この脆弱性は、主要なLinuxディストリビューションに同梱されているデータ圧縮ライブラリ「XZ Utils」に影響を及ぼし、CVE-2024-3094として登録されている。これは、かつてこのシステムを信頼していたボランティアのシステムメンテナによって意図的に挿入されたバックドアに起因する。 適切に悪用されれば、場合によってはリモートコード実行（RCE）を可能にするこの脆弱性は、確立されたソフトウェア構築プロセスに深刻な損害を与える可能性があるため、非常に重大な問題である。

幸いにも、別のメンテナがLinuxの安定版に悪意のあるコードが組み込まれる前にこの脅威を発見しましたが、Fedora Rawhideの一部としてXZ Utilsバージョン5.6.0および5.6.1の実行を開始したユーザーにとっては依然として問題であり、組織は緊急レベルの優先度でパッチ適用を強く推奨されています。 この発見が間に合わなければ、そのリスクプロファイルは史上最も壊滅的なサプライチェーン攻撃の一つとなり、おそらくSolarWinds事件さえも凌駕していたでしょう。

コミュニティのボランティアに依存して重要システムを維持していることは広く知られていますが、この事件のような重大な問題が明るみに出るまでは、ほとんど議論されることはありません。 オープンソースソフトウェアの維持に彼らの尽きることのない労力が不可欠である一方で、これは開発者がセキュリティスキルと意識に特に注意を払う必要性を浮き彫りにしている。ソフトウェアリポジトリへのアクセス制御の強化は言うまでもない。

XZ Utilsのバックドアとは何か、そしてどのように緩和するのか？

3月29日、レッドハットは緊急セキュリティアラートを発表し、Fedora Linux 40およびFedora Rawhideユーザーに対し、最新版の「XZ」圧縮ライブラリとツールに悪意のあるコードが含まれていることを通知した。このコードは、第三者による不正アクセスを容易にするために特別に設計されたものと見られる。 この悪意あるコードが注入された手法は今後詳細に分析される見込みだが、これは「Jia Tan」という偽名の攻撃者による、洗練され忍耐強い数年にわたるソーシャルエンジニアリング工作であった。 この人物は2年以上にわたり、他のメンテナの信頼を勝ち取るため膨大な時間を費やし、XZ Utilsプロジェクトおよびコミュニティへ正当な貢献を続けた結果、複数の偽装アカウントがプロジェクトのボランティア所有者であるLasse Collinへの信頼を損なった後、ついに「信頼できるメンテナ」の地位を獲得した。

‍

‍

この異例の事例は、高度な技術を持つ人物でさえ、通常は知識の乏しい者を対象とした戦術の被害者となり得ることを示す好例であり、セキュリティ意識向上のための職務に基づいた正確な教育の必要性を証明している。 マイクロソフトのソフトウェアエンジニアでありPostgreSQLのメンテナンス責任者であるアンドレス・フロイントの好奇心と機転によってのみ、このバックドアが発見され、バージョンが無効化され、近年で最も壊滅的なサプライチェーン攻撃となり得た事態が阻止されたのである。

このバックドア自体は、NISTの登録において最も深刻な脆弱性として公式に追跡されている。 当初はSSHによる認証を回避できると考えられていたが、その後の調査により、Fedora Rawhide、Fedora 41、Kali Linux、openSUSE microOS、openSUSE Tumbleweed、およびDebianの一部のバージョンを含む脆弱なLinuxシステムにおいて、認証なしのリモートコード実行を可能にすることが判明した。

Jia Tanは悪意のあるパッケージを隠蔽するためにあらゆる手段を講じたようであり、ビルドプロセス中に自動構築されるよう設定されると、systemd経由でのSSHd認証を妨害する。Red Hatの詳細な説明によれば、適切な条件下ではこの干渉により攻撃者がSSHd認証を突破し、システム全体への不正なリモートアクセスを取得する可能性があるとされている。

Microsoftをはじめとする各社は、システムにおける脆弱性の悪用事例の分析と影響緩和に関する包括的なガイダンスを公開しています。CISAが推奨する緊急措置として、影響を受ける開発者およびユーザーは、XZ Utilsを脆弱性のないバージョン（例：XZ Utils 5.4.6 Stable）に更新すべきです。

この種の攻撃を防ぐことは非常に困難です。特にソフトウェアでオープンソースコンポーネントを使用する場合、サプライチェーンのセキュリティに関して保証や透明性がほとんどないためです。私たちはこれまでソフトウェアサプライチェーンにおける偶発的な欠陥と戦ってきましたが、このリスクは増大し、悪意を持ってオープンソースのセキュリティを侵害するために意図的に作成されたセキュリティ上の欠陥も含まれるようになりました。

ほとんどの開発者は、強いセキュリティ意識、確固たるセキュリティ知識、そして少しの偏執的な警戒心を持たない限り、この種の攻撃を阻止できません。脅威アクターの思考様式が求められるケースに近いのです。ただし、主要な考慮事項は常に、内部で管理されているソースコードリポジトリ（つまり非オープンソース）に集中すべきです。 アクセス権限は、関連するセキュリティスキルを有し、かつそのスキルが検証済みの者にのみ付与されるべきです。アプリケーションセキュリティの専門家は、ブランチレベルでのセキュリティ制御と同様の設定を検討できるでしょう。つまり、セキュリティに精通した開発者だけが、最終的なマスターブランチに変更を加えられるようにするのです。

ボランティアのメンテナは英雄だが、ソフトウェアを安全に維持するには（おそらく）コミュニティ全体が必要だ

ソフトウェアエンジニアリングの分野外にいる人々にとって、活発なボランティアコミュニティが余暇を利用して重要なシステムを入念に維持しているという考えは理解しがたい概念だが、これがオープンソース開発の本質であり、サプライチェーンを保護するセキュリティ専門家にとって依然として重大なリスク領域である。

オープンソースソフトウェアは、ほぼ全ての企業のデジタルエコシステムにおいて不可欠な要素であり、その維持管理を担う者たち（その大半は善意で活動している）は、技術的進歩と完全性を無償で追求する真の英雄である。しかし、彼らを孤立した状態で機能させ続けるのは非現実的だ。 DevSecOpsが重視される現代において、セキュリティは共有責任であり、すべての開発者は業務中に直面する可能性のあるセキュリティ問題を解決するための適切な知識とツールを備えるべきです。セキュリティに関する知識と実践的なスキルは、ソフトウェア開発プロセスにおいて妥協すべきではありません。そして、企業レベルでの変化を促すのはセキュリティリーダーの役割です。
‍

今すぐ、包括的な情報で組織内に健全な安全文化を築きましょう コース Secure Code Warriorのコースで。