ソフトの中核に潜伏するサイバー攻撃 再発防止はできるのか
ソフトウェアのコードを改変してサイバー攻撃を仕掛けるサプライチェーン攻撃は珍しくない。信頼されているソフトの開発プロセスに潜り込んで長い時間をかけて準備した事例が見つかった。
オープンソースソフトウェア(OSS)は少人数で開発される場合もあれば、100人以上が参加する場合もある。いずれも透明性やコラボレーション、コミュニティーによるレビューがしっかりしていればコードの品質を保ちやすい。だが、危険な例外が見つかった。
OSSの開発者に「偽装」した攻撃者が出現
それがデータの圧縮と解凍機能を備えるOSSの一つ「XZ Utils」だ。XZ Utilsに対するサプライチェーン攻撃が見つかったことで、事件の背後にいる攻撃者と思われる人物の動機や、より大きな問題となるOSSエコシステム全体のセキュリティに関する懸念が明らかになった。きっかけはMicrosoftのアンドレス・フロインド氏(プリンシパル・ソフトウェアエンジニア)の発見にあった。
その技術者は難読化された悪質なコードがXZ Utilsのxzライブラリに含まれており、サプライチェーンの大規模な侵害につながる可能性があることを偶然見つけた。
そもそも「サプライチェーン攻撃」とは何だろうか。
サプライチェーン攻撃という用語には2つの意味がある。情報処理推進機構(IPA)は「情報セキュリティ10大脅威 2024」でその意味を説明した。IPAによれば第一の意味は「『ビジネス上のつながり』を悪用した攻撃であり、自組織の対策のみでは防ぐことが難しいため、関係組織も含めたセキュリティ対策が必要な脅威」だという。第二の意味は「ソフトウェア開発のライフサイクルに関与する全てのモノ(ライブラリ、各種ツールなど)や人のつながりをいう」。IPAは第二の意味をソフトサプライチェーンとして区別している。
今回のXZ Utilsは第二の意味でのサプライチェーン攻撃だ。攻撃者はソフトウェアの供給チェーンの弱点や脆弱(ぜいじゃく)性を悪用して、悪意のあるコードを注入したり、不正なコンポーネントを挿入したりした。
第二の意味でのサプライチェーン攻撃にも幾つかの種類がある。2017年に発見されたCCleanerのマルウェア事件では「ソフトウェアのトロイの木馬」を利用して、正規のソフトウェアに悪意のあるコードを注入した。これは今回のXZ Utilsと似ている。
ソフトウェアの供給チェーンを侵害する攻撃もある。2017年に発生した「Petya」ランサムウェア攻撃では、ウクライナの会計ソフトウェア会社が侵害されて、悪意のあるバージョンのソフトウェアが正規の更新プログラムとして配布された。
この他、サードパーティーのコンポーネントの脆弱性を利用したり、証明書を偽造したり、ハードウェアを不正に改変したりするようなサプライチェーン攻撃も存在する。(キーマンズネット編集部)
セキュリティ研究者や業界の専門家はxzライブラリに悪質なコードをインストール目的で、開発の内部関係者としての立場を築くために攻撃者が数年にわたる努力をしていた可能性があると推測している。
研究者によると、XZ UtilsはほとんどのLinuxディストリビューションに含まれており、長い間、高い信頼を得ていた。
ソフトウェアのサプライチェーンプラットフォームを提供するJFrogのジョナサン・サル・シャローム氏(脅威リサーチディレクター)は(注1)、次のように述べた。
「この攻撃の最もユニークで不穏な側面は、攻撃者が長い年月をかけて、信頼できるOSSの貢献者としての地位を確立し、その上で広く使用されているパッケージに悪質なコード(バックドア)を追加した点だ。このような機会を手に入れるまでに、攻撃者は膨大な努力と投資を費やしたと考えられる」
研究者は2年前から参加していた「@JiaT75」というジア・タン氏の「GitHub」アカウントが、バックドア設置に関係しているのではないかと疑った。このアカウントは後に凍結された(注2)。XZ Utilsの開発に当初から参加し管理していたラッシー・コリン氏のアカウント「@Larhzu」も凍結された(注3)。
GitHubは利用規約に従ってユーザーアカウントを停止し、コンテンツを削除したことを公開したが、調査の結果、@Larhzuのアカウントは復活した。
攻撃者はコミュニティーの信頼を得るために数年にわたる努力を続けつつ、同時に、すぐには気付かないような微妙な変更を加える形で水面下のテストを進めていたようだ。
Open Source Security Foundationのオムカール・アラサラトナム氏(ゼネラルマネジャー)は(注4)、次のように語った。
「過去の出来事を振り返ると、ジア・タン氏が時間をかけて小さな変更を加えていったことが分かる。どれも致命的なものではなく、目立つものでもなかった。なぜそのようなことをしたかといえば、人々がそのような変更を見付けるかどうかを確認するためだった」
オープンソースコミュニティーでは、以前にもメンテナンス担当者が感情的に行動したり、より大きな問題に抗議したりするための足掛かりとしてコミュニティーを利用する事例があった。しかし、今回の攻撃の忍耐強さと巧妙さから、専門家は国家による支援があったのではないかという疑念を抱いている。
サプライチェーン管理プラットフォームを提供するSonatypeのブライアン・フォックス氏(設立者兼最高技術責任者)は次のように述べた。
「私たちの分析によると、この事件で観察された巧妙な手法はもちろん、運用セキュリティや電子メールアドレス、IPアドレスの戦略的な利用は高度に訓練された攻撃者の存在を示唆する。限られた範囲での的確な関与に加え、脅威の存在を示す具体的な証拠がないことから、この事件は単なるOSSの貢献者による不正な行動とは一線を画している」
どのように対応すればよいのか
企業向けにOSSを提供するRed Hatは2024年3月29日(現地時間、以下同)、xzツールとライブラリの最新バージョンに悪質なコードが存在すると警告した(注5)。この脆弱性には「CVE-2024-3094」という識別番号が割り当てられており(注6)、共通脆弱性評価システム(CVSS)のスコアは最高値の10.0だ。
Linuxディストリビューション「Fedora」の断続的なリリースモデル「Fedora Rawhide」を仕事や個人で使用することを直ちに中止するよう求めた。サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)は(注7)、開発者とユーザーに対し、問題のないバージョンにダウングレードするよう警告した。
Microsoftは今回の攻撃を発見した同社の役割を確認し、影響を受けるLinuxディストリビューションのリストとともに、対応方法に関するガイダンスを発表した(注8)。
そもそもフロインド氏はどうやってXZ Utilsの異変に気が付いたのだろうか。同氏は2024年3月25日の週にXZ Utilsについて幾つかの異常な動作に遭遇したことを公表した。同氏はsshdプロセスが異常な量のCPU時間を使用したことを確認し、誤ったユーザー名が適用されていることを発見した。
フロインド氏は「Mastodon」への投稿で「数週間前に実施したパッケージのアップデート後に、postgresの自動テストで奇妙なvalgrindのエラーを見たことを思い出した」と述べた(注9)。つまりサイバー攻撃を発見したのではなく、サイバー攻撃のために追加されたコードによってXZ Utilsが「重く」なったことに気が付いた。
調査企業IANS Researchのジェイク・ウィリアムス氏はユーザー企業がどのように備えるべきなのかをまとめた。
「今回の事件は適切な人員を配置した脆弱性情報チームの必要性や、ツールへの適切な投資の必要性をはじめとする防衛の深層化の必要性を強調している。SSHサーバへのアクセスを防ぐ厳格なファイアウォールルールを持つ組織では、脆弱な実装であっても悪用の機会を制限できていた。幾つかのクラウドセキュリティ向けの態勢管理システムは、この攻撃が検出された日に脆弱なインスタンスのスキャンを実行した」
出典:Motivations behind XZ Utils backdoor may extend beyond rogue maintainer(Cybersecurity Dive)
注1:CVE-2024-3094 XZ Backdoor: All you need to know(JFrog)
注2:Remove JiaT75 as a contact, determine correct contacts(GitHub)
注3:XZ Utils backdoor(tukaani.org)
注4:xz Backdoor CVE-2024-3094(Open Source Security Foundation)
注5:Red Hat warns of backoor in widely used Linux utility(Cybersecurity Dive)
注6:CVE-2024-3094 Detail(NIST)
注7:Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094(CISA)
注8:Microsoft FAQ and guidance for XZ Utils backdoor(Microsoft)
注9:@AndresFreundTec(Mastodon)
© Industry Dive. All rights reserved.
関連記事
- 「Log4jはもうこりごり……」Googleが示す3つの解決策は?
ソフトウェアサプライチェーンのセキュリティについて、Googleが調査報告書を発表した。同社が示す3つの解決策とは。 - オープンソースソフトが使えなくなる? 米国政府がセキュリティ規則を厳格化
サプライチェーン攻撃のリスクを下げるため、米国政府は新しい規制を打ち出した。オープンソースソフトの採用を進めてきた米国政府がいったん立ち止まる形だ。政府が規制のさじ加減を誤ると、政府にとどまらず企業もオープンソースソフトを利用できなくなる可能性がある。この動きは日本にも波及するのだろうか。