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」という偽名の攻撃者による、数年にわたる複雑で忍耐強く継続されたソーシャルエンジニアリングの成果に相当する。この人物は他のメンテナーの信頼を得るために膨大な時間を費やし、XZ Utilsプロジェクトとコミュニティに対して2年以上にわたり正当な貢献を行った。複数の偽装アカウントを通じてボランティアプロジェクト所有者であるLasse Collinへの信頼を徐々に損なった後、最終的に「信頼できるメンテナー」の地位を獲得した：

‍

‍

この異常な事例は典型的な例であり、高度な技術を持つ人材が、通常はそれほど賢明でない人々を対象とした戦略の犠牲者となった。これは、精密で役割ベースのセキュリティ意識トレーニングの必要性を示している。マイクロソフトのソフトウェアエンジニアとPostgreSQLメンテナーの好奇心と思考の敏捷さによってのみ、 アンドレアス・フロイントによってバックドアが発見され、バージョンがロールバックされたことで、現代においておそらく最も破壊的なサプライチェーン攻撃が阻止されたのである。

バックドアプログラム自体は、NISTの脆弱性データベースにおいて最高レベルの深刻度として正式に追跡されています。当初はSSH認証のバイパスを可能にするものと見なされていましたが、さらなる調査により、Fedora Rawhide、Fedora 41、Kali Linux、openSUSE MicroOS、openSUSE Tumbleweed、および特定のバージョンのDebianを含む脆弱なLinuxシステム上で、認証不要のリモートコード実行を可能にすることが判明しました。

Jia Tan はマルウェアパッケージの難読化に余念がなく、構築プロセス中にパッケージ自身の構築をトリガーすると、systemd 経由での SSHD 認証を妨害する。Red Hatが詳細に説明しているように、適切な状況下ではこの妨害により、攻撃者が SSHD 認証を破りシステム全体への不正なリモートアクセス権を取得する可能性が生じる。

マイクロソフトは包括的なガイダンスを公開し、システム上で脆弱性の悪用事例を確認し影響を軽減する方法、および直ちに行うべき措置を推奨しています。CISAは影響を受ける開発者とユーザーに対し、XZ Utilsを割引版ではないバージョン（例：XZ Utils 5.4.6安定版）にダウングレードするよう勧告しています。

この種の攻撃を防ぐことは非常に困難です。特にソフトウェアにオープンソースコンポーネントを使用する場合、サプライチェーンのセキュリティはほとんど保証も透明性もありません。ソフトウェアサプライチェーンにおける予期せぬ脆弱性には対処してきましたが、このリスクは意図的に悪意を埋め込みオープンソースの安全性を損なうセキュリティ脆弱性まで拡大しています。

強いセキュリティ意識、十分なセキュリティ知識、そして多少の偏執的な警戒心がない限り、ほとんどの開発者はこの種の攻撃を阻止できません。これは脅威行為者の思考様式を必要とする事例と言えるでしょう。しかし、主要な考慮事項は常にソースコードリポジトリを中心とした内部統制（非公開）であるべきです。検証済みの関連セキュリティスキルを持つ者のみがこれらにアクセスできる必要があります。AppSec専門家は、ブランチレベルのセキュリティ制御などの設定を検討し、セキュリティスキルを持つ開発者だけが最終的なメインブランチに変更を加えられるようにするかもしれません。

ボランティアの保守担当者は英雄だが、（本来は）安全なソフトウェアを維持するには村全体が必要だ

ソフトウェア工学分野以外の人々にとって、活気あるボランティアコミュニティが自らの時代において重要なシステムを懸命に維持するという考えは理解しがたい概念だが、これがオープンソース開発の本質であり、サプライチェーンの安全を守る専門家にとって依然として重大なリスクに直面する領域である。

オープンソースソフトウェアはほぼ全ての企業のデジタルエコシステムにおいて重要な構成要素であり、信頼できるメンテナ（その大半は誠実な意図で活動している）は、技術的進歩と完全性を無私無欲に追求する過程において確かに英雄的である。しかし彼らを孤立させて成果を出させるのは滑稽だ。DevSecOpsが中心となるこの時代において、セキュリティは共有責任であり、各開発者は業務中に遭遇する可能性のあるセキュリティ問題に対処するための知識と適切なツールを習得しなければならない。ソフトウェア開発プロセスにおいて、セキュリティ意識と実践的スキルは譲れない要素であり、セキュリティリーダーは企業レベルでの変革を推進する責任を負っている。
‍

現代の組織において、深く根付いた方法で安全文化を育む コース セキュリティコードの戦士たちより