これは、最も一般的なソフトウェアサプライチェーン攻撃、つまり、ソフトウェアコンポーネントの公開レジストリを悪用する攻撃に関する一連の記事の最初のエピソードです。 オープンソースプロジェクト 他のユーザーと共有できる成果物をアップロードするためです。悪意のある攻撃者がレジストリをマルウェア配布の手段として悪質なソフトウェアを公開すると、被害を受けた組織が感染したソフトウェアコンポーネントをインストールまたは実行した際に、サプライチェーン攻撃が発生します。
議論を簡略化するために、 ソフトウェアパッケージ:、サードパーティによって作成されたパッケージ形式のコンポーネント。これには、NPMやPoetryなどのパッケージマネージャーで使用されるコンポーネントだけでなく、 オペレーティングシステムのコンポーネント ライブラリや実行可能バイナリを含む、 コンテナイメージ、 仮想マシン、または ツール拡張機能 開発、ビルド、デプロイ ツール用。悪意のあるパッケージが至る所で見られます。サイバー犯罪者は気にしません。彼らは最新のソフトウェア インフラストラクチャが提供する代替手段を喜んで利用し、自分たちの意図に最も適したレジストリとツールを使用します。したがって、ソフトウェア パッケージは、コンテナ イメージ、バイナリ パッケージ、オープンソース リポジトリ、およびあらゆる種類の拡張機能またはプラグイン (IDE、 CI/CD システム、ビルドツールなど）はすべて日常的に攻撃にさらされている。
このシリーズは全5話構成です。
- オープンソースパッケージの問題点とは？ これが今回の記事のテーマです。なぜあらゆる種類の犯罪者が悪意のあるパッケージを公開するのでしょうか？なぜ私はそれを心配する必要があるのでしょうか？
- 悪意のあるパッケージの構造：その傾向とは？ 今回のエピソードでは、MEWシステムで日々監視している脅威に焦点を当てます。タイポスクワッティングや依存関係の混乱を利用した悪意のあるパケットが大量に発生し、バックグラウンドノイズが大きくなる中、攻撃のごく一部はより巧妙で、より大きなリスクをもたらします。近年、OSに関する攻撃者の行動はどのように変化したのでしょうか？具体的な数字はどうなっているのでしょうか？どのような戦術、技術、手順が用いられ、どのような有害な行為が見られるのでしょうか？
- オープンソースの悪意のあるパッケージから身を守る：何が効果的で何が効果的でないかセキュリティに意識の高い専門家のほとんどは、この脅威への対処方法について考えを持っています。セキュリティマネージャーがためらうことなくこう言っているのを耳にしました。 SCA ツールは既にパッケージのバージョンがマルウェアであるかどうかを教えてくれます。あるいは、よく知られていて評価の高いソフトウェアコンポーネントに依存しているため、マルウェアはすぐに検出され、削除されます。脆弱性修正を自動的に取得するためにオープンなマイナー/パッチバージョンを使用しており、これは「早期にパッチを適用し、頻繁にパッチを適用する」原則に従ってオープンソースの依存関係のリスクを低減するための適切で推奨される方法です。今回のエピソードでは、これらの考え方がなぜ間違っているのか、そしてこのような誤解がどのようにしてこの攻撃メカニズムの人気と、組織が直面している圧倒的なリスクにつながっているのかを検証します。最後に、実際に効果のある方法と、それに必要な労力とリソースについて述べます。
- オープンソースの悪意のあるパッケージ：Xygeniのアプローチ今回のエピソードでは、Xygeniのマルウェア早期警告（MEW）システムで採用している戦略をご紹介します。この多段階システムは、新しいパッケージバージョンが公開された際にリアルタイムでどのように機能するのか、さまざまなソースからどのように証拠を収集するのか、トリアージはどのように行われるのか、どのような分類基準に従っているのか、そして悪意のあるパッケージ候補の性質を確認するために、なぜまだ手動分析が必要なのかについて説明します。また、社内チームとレジストリチームからのフィードバックが、システムが過去に収集した証拠から学習し、誤検知を最小限に抑えるのにどのように役立つのかについても解説します。さらに、NPM、GitHub、PyPI、およびオープンソースエコシステムのその他の主要なインフラストラクチャが滞留時間を短縮できるよう、Xygeniがどのように支援しているかについても説明します。.
- オープンソースの悪用：悪意のある攻撃者が何を企んでいるのかこのシリーズの最後では、攻撃者が攻撃をより巧妙に、検知しにくく、特定の業界を標的にし、この種の攻撃からより多くの利益を得るために採用している最新の行動に焦点を当てます。ランサムウェア攻撃はこの手段を使って配信されるのでしょうか？悪意のある攻撃者は、より高度な悪意のあるパッケージを配信するために、どのようにAIツールを活用しているのでしょうか？人気のあるトッププロジェクトは危険にさらされているのでしょうか？これは、読者にこの軍拡競争の現状と、短期（2024年後半）および中期（2025年）に何が予想されるかを理解してもらうためのものです。最近の攻撃のような攻撃がどのように行われるかを学びます。 XZ-Utilsバックドアまたは、自給自足生活への攻撃 電子ビルダー 2024年3月の状況は、敵対勢力がどのように進化していくかについて警戒を怠ってはならないことを示している。
それでは、第1話から始めましょう。悪意のあるオープンソースパッケージで何が起こっているのでしょうか？
オープンソースパッケージの問題点とは？
近年、あらゆる種類の悪意ある行為者が、オープンソースソフトウェアのレジストリを利用して悪質な行為をばらまいている。こうした行為はオープンソースの歴史と同じくらい古いが、ここ3年間でその頻度が爆発的に増加した。
悪意のあるコンポーネントを公開レジストリに公開する（依存関係に基づく攻撃は、脅威アクターがマルウェアを配布するために使用する非対称ゲリラ戦であり、組織が未知の開発者から提供されるオープンソースコンポーネントに寄せる信頼を利用しています（ 依存に関するxkcdコミック（？）。パッケージを信頼し、パッケージの内容とその依存関係を手動で確認することに抵抗がないため、これらの攻撃は非常に効果的です。また、攻撃の大部分を自動化でき、攻撃者が被害者と直接やり取りする必要がないため、非対称性が生じます。攻撃者はパッケージを公開レジストリにアップロードして、あとは放置するだけです。
悪意のあるパッケージ 2022年に6倍に急増したそして、2023年には2.5倍に成長し続けました。昨年はなんと24万5000もの悪意のあるパッケージが確認され、これは過去数年間の合計数を2倍以上上回る数字です。これは指数関数的な成長です。2021年には数百件、2022年には数千件のマルウェアとして確認されたパッケージ削除がありましたが、2023年にははるかに多くのバックグラウンド「ノイズ」が見られ、今年も同様のペースで推移しています。そして、「抵抗の少ない道」をたどる未熟なサイバー犯罪者によって引き起こされたそのバックグラウンドに隠れて、少数の注目度の高い攻撃が一般メディアでも見出しを飾りました。
なぜこれがこれほど大きな問題なのでしょうか？ 信頼の過剰 チェーン全体で。オープンソースソフトウェアはソースコードとともに配布され、特定のライセンスの下でリリースされます。はい、誰でもソースコードを検査できます。しかし、実際に誰が検査するのでしょうか？ソフトウェアにマルウェアがないことを確認した後、ソースからソフトウェアをビルドするのは誰でしょうか？パッケージ化されたコンポーネント（別名： パッケージパッケージマネージャーやビルドツールに渡る段階で、パッケージにマルウェアが蔓延していないこと、そして本来のソースコードと一致していることを確認しますか？
なぜインフラはこれほど容易な攻撃を許してしまうのか？
パッケージレジストリ 公開されており、多くの場合、発行者の身元確認は最小限で済みます。「誰でもここでソフトウェアを公開できます！」攻撃者にとってのハードルは低く設定されています。使い捨てのメールアドレスと使い捨てのGitHubアカウントを使用して、フィッシングのような短いキャンペーンで何百もの悪意のあるパッケージを作成します。より高度な技術が必要なのは、ターゲットを絞った攻撃の場合のみです。多くのスターが付いた信頼できるGitHubソースリポジトリを作成し、 commit複数の偽の投稿者からの情報や、人気度やメンテナンスに関するその他の指標。 星空観察者と偽の投稿による評判 自動化は難しくありません。マルウェアだけでなく、あらゆる種類のオープンソフトウェアインフラストラクチャで悪用が見られました。 お茶のプロトコル事件.
パッケージマネージャーは使いやすさを重視して設計されており、セキュリティを重視して設計されたものではありません。インストール前およびインストール後のスクリプトを実行できます（ライブラリのネイティブ コードをコンパイルする必要がある場合があります）。また、 パッケージマネージャー パッケージは複数のソースからインストールされ、場合によってはデフォルトで公開レジストリが使用されます。彼らは、公開リクエストのメタデータとパッケージ自体のメタデータの不一致をチェックしていませんでした。
依存関係はネストされ、グラフを形成します。Node (JavaScript) のような特定のエコシステムでは、細粒度の依存関係が数百または数千に蓄積されます。ソフトウェア プロジェクトで宣言された直接的な依存関係を厳密に制御することは重要ですが、 推移的依存関係 制御がより困難です。オープンソースは「友人の友人は友人」に従いました。極東の荒野では兄弟愛が常識です！脅威アクターはこのことを知っており、悪意のある行動を、しばしば知られていない不明瞭な依存関係の中に深く隠します。これは、 イベントストリーム を標的とした事件 Copayウォレット.
オープンソースソフトウェアは誕生以来ずっとこの方式で運営されてきた。今後も大きく変わることはないだろう。一部のパッケージレジストリはせいぜい二要素認証を要求するだけで、しかも多くの場合、最も人気のあるパッケージに限られる。一部のレジストリはスコープ、つまり審査済みの組織が所有する名前空間を提供しているが、 悲劇的に 他のサービス（PyPI）はこれをサポートしていないか、オプションとしている（NPM）。 興味深いことに、 シンプルなスクリーニング方法 (グループIDに一致するDNSまたはGitHubリポジトリ/組織の制御に基づいて) PGP署名は必須です チェックサムを除くすべてのアーティファクトに対して、ほとんどの「ノイズ」、タイプスクワッティングのような悪意のあるパッケージを除去し、 依存関係の混乱高度な攻撃は可能だが、はるかに難しく、 com.github.codingandcoding:maven-compiler-plugin Maven Centralで知られています。しかし、すべてのMavenレジストリが同じ慣習に従っているわけではありません！
パッケージマネージャーのセキュリティ制御は、依存関係攻撃を阻害するものではなく、むしろ負担となる可能性があります。多要素認証の問題点は、自動化の場合、自動化スクリプトから行われる API API 呼び出しで使用されるアカウントに対して、アクセストークンや API API キーなどの派生認証情報が生成され、対話型のユーザーが第 2 要素を提供するという裏付けがないことです。MFA はユーザー アカウントをパスワード漏洩から保護するのに有効ですが、生成されたアクセストークンや API API キーはアクティブな間は保護する必要があり、そうしないと攻撃者によって所有者がなりすまされる可能性があります。パッケージベースのサプライチェーン攻撃の大部分は、漏洩したキー/トークンから始まります。次のような事件を思い出してください。 元帳, 3CXさらに、サプライチェーン攻撃を開始するための予備的な侵入において、非対話型の認証情報が最初に流出した事例も多数存在する。
この脅威に対する対応は十分ではなかった。第3話では、何がうまくいき、何がひどく失敗したかに焦点を当てる。業界は協力して、 standardグローバルサプライチェーンのリスクを軽減するためには、戦略、プロセス、教育、ツールなどが必要です。これは、単一の組織だけで解決できる問題ではありません。
このセクションの最後に、重要な誤解について述べます。 悪意のある パッケージではなく 脆弱な 脆弱性は、悪意なく偶発的に導入された設計ミスやコーディングミスから生じます。脆弱性は悪用される可能性がありますが、多くは悪用されません。悪意のあるパッケージは常に意図的に作成され、実行された場合は100%悪用可能です。比較できるリスクはありません。したがって 脆弱性の検出と軽減に多大な努力が注がれている一方で、悪意のあるコンポーネントに対する同等の対策が欠如しているのは、矛盾していると言えるだろう。.
「私たちはセキュリティを真剣に考えています」
慣習的な Acme CorporationWileCoyote.comの主要プロバイダーであるAcmeは、ソフトウェアの大部分をサードパーティから調達しており、その80%以上がオープンソースプロジェクトからのものです。Acmeは社内利用のためのソフトウェアを開発するだけでなく、パートナー、プロバイダー、顧客/エンドユーザー向けにもソフトウェアを提供しています。AcmeのソフトウェアはGo、JavaScript、Java、C#、Pythonで記述されており、そのほとんどをKubernetesクラスター上でクラウド上で実行しています。AcmeはDocker Hubやその他のレジストリから取得したベースイメージからカスタムイメージを構築しています。また、いくつかのライブラリ、パッケージ、コンテナイメージをパブリックレジストリで共有しています。
Acmeはセキュリティを真剣に考えています。彼らは、 open source securityそして、それがもたらすリスク。すべての開発者、システム管理者、DevOpsエンジニアは、これらの可愛らしい小さな暗号鍵を第二要素認証として使用します。 commitコードリポジトリへの署名、必須コードレビューによるブランチ保護の有効化、 CI/CD ロックされたシステム、秘密情報保管庫に保管された機密情報、そして外部レジストリを部分的にミラーリングした内部レジストリを備え、許可されたホワイトリスト登録済みのコンポーネントのみが格納されています。Acme社が開発するソフトウェアは、このレジストリからサードパーティの依存関係を取得する必要があります。
おそらくほとんどの組織はこの特徴に当てはまるでしょう。読者の皆様、もしあなたがまだこのページをご覧になっているのであれば、あなたの組織も間違いなくこれに当てはまるのではないでしょうか？
そしてある不運な日、重要なフロントエンド開発者が アクメランで npm install acme-cute-lib@acme/cute-lib が正しいスコープの依存関係であることを忘れていました。正確なミスは重要ではありません。ソフトウェアライフサイクルを完全に制御しているつもりでも、多くの問題が発生する可能性があります。開発者は、APTグループがAcmeを標的にしていることを知らず、その名前で悪意のあるコンポーネントを公開しました。巧妙な方法で、ソフトウェアがAcmeコンピュータにインストールされた場合にのみ悪意のある動作がアクティブになるようにしました。パッケージは公開後数週間検出されませんでした。
インストールスクリプトが実行され、認証情報（開発者のラップトップには多数の有効なアクセストークンが保存されていた）を検索し、内部ソフトウェアリポジトリへのアクセスを許可します。前述の内部リポジトリは、もちろんVPN経由でのみアクセス可能です。悪意のあるコードは、既存のVPN接続を利用して、内部レジストリに第2段階の悪意のあるコンポーネントを公開し、Acme社が提供するほとんどのソフトウェアで共有されている共通ユーティリティライブラリに影響を与えました。
数週間後、Acmeが公開したツールを使用している他の組織でも、ネットワーク上で奇妙なトラフィックが発生し始めた。そのトラフィックはAcmeのプロトコルを使用しているものの、Acmeドメインに似たホストに向けられていた。トラフィックは暗号化されていたが、システム監視ツールによって、予期しないファイルへのアクセスや、システムコマンドのように見えるものの、最終的にはダウンロードされた実行ファイルを実行するプロセスの実行が確認された。
その後の経緯は周知の通りだ。Acme社は当初、そのような行為は自社の責任ではないとし、すべてのセキュリティ対策は適切に講じられていたと主張した。しかし、サイバーセキュリティ関連メディアが、検出された異常行為の原因がAcme社の部品にあると疑問を呈し始め、セキュリティ分析によってそれらの部品が巧妙なマルウェアにどれほど深く侵食されていたかが明らかになると、Acme社はようやく事態を認め、インシデント対応会社に依頼せざるを得なくなった。これは、苦労して築き上げてきた信頼を一瞬にして損なう、ネガティブなマーケティングキャンペーンとなった。Acme は npm インストール 1 回で di にsaster「」はよく見かける見出しだった。その後、訴訟や契約解除が相次いだ。
過去の既知の事件との類似点が見られますか？Acmeは、2段階のサプライチェーン事故により、 依存関係の混乱／タイポスクワッティング 開発者のワークステーションを足がかりとして、サードパーティが使用するソフトウェアのコンポーネントにマルウェアを感染させる攻撃が発生しています。このような攻撃を防止または軽減するにはどうすればよいでしょうか？
毒入り小包が人気な理由
この架空の事例は、オープンソースのセキュリティ対策を適切に講じていても、組織はオープンソースコンポーネントに潜むマルウェアの被害に遭わないために、具体的な対策を講じる必要があることを示しています。攻撃者は、概略的に以下のことが可能です。
- 新しいパッケージを作成する（よく知られているタイポスクワッティングや依存関係の混乱といった手法に倣い、これは悪意のある者が最も頻繁に利用する手段である）。
- 既存のものを感染させようと試みる。ソースコードに注入するか、貢献者を装うかのいずれかの方法で行う。 pull requestまたはソーシャルエンジニアリングを使用してメンテナーになる（XZバックドアで「Jao Tan」が行ったように） 右9ctrl GitHub ユーザーが イベントストリーム 2018年秋に発生した事件）、またはオープンソースリポジトリの認証情報を取得してメンテナーになりすますことによって、
- パッケージのビルド中にマルウェアを注入する。悪意のあるビルドスクリプトを実行することによって。あるいは、中間者攻撃による傍受でパッケージのダウンロードを妨害する（幸いなことに、現在ではほとんどのレジストリでTLSが常に必須となっている）。
- パッケージ化されたコンポーネントをレジストリに直接注入します。通常はレジストリ認証情報をキャプチャすることによって行われます（これは、Acme のような高度な攻撃の多くで推奨される代替手段です。最初の段階で侵害されたワークステーションには、通常のレジストリアクセス トークンなど、内部レジストリ アクセス トークンがありました）。 .env or ~/.m2/settings.xml（悪意のある攻撃者は秘密情報を探す場所を知っている）。レジストリの脆弱性も悪用された。
レジストリにマルウェアを仕込むことは、依存性攻撃の基本的な手口だ。目新しいことではないが、その蔓延は爆発的に増加しており、5年前と全く同じ手法が今でも通用する。
出典： 裏切り者のナイフコレクション.
悪意のあるパッケージは、インストール時、ソフトウェアのビルド時、または実行時に動作する可能性があります。その動作は、情報漏洩（例えば、第2段階の攻撃のために機密情報を抽出するなど）から、ソースコードの抽出、追加のマルウェアの投下まで多岐にわたります。次回は、悪意のあるパッケージとその公開方法について詳しく解説します。
参考文献
次のエピソード 悪意のあるパッケージの構造：その傾向とは？ 弊社のマルウェア早期警戒システムで日々監視している実際の事例に焦点を当てます。どのような種類のマルウェアが確認されたのか、そしてどのような戦術、技術、手順が好まれているのかを検証します。難読化とその手法、潜在的な監視者から身を隠す方法、検出を回避するための回避技術、そしてテレメトリと横方向の移動によってどのように進化しているのかについても考察します。どうぞご期待ください！
参考情報
- 裏切り者のナイフコレクション：オープンソースソフトウェアサプライチェーン攻撃のレビューM. Ohm 他、2020年5月。
- オープンソースのマルウェア対策Xygeni社のホワイトペーパー。
- Software Supply Chain Security 回顧：より安全な2024年を形作るXygeniからの報告。
