GitHubで10万件超の感染済みリポジトリが発見される

GitHubで100,000件を超える感染済みリポジトリが発見

• セキュリティ研究・データサイエンスチームが、昨年半ばに始まった悪意あるリポジトリ混同キャンペーンが大規模に再浮上していることを検知した。
• この攻撃は、開発者が既知の信頼できるリポジトリに似せて作られた、実際には悪性コードを含むリポジトリを使用した際に、10万件を超えるGitHubリポジトリ（推定では数百万件）に影響を与える。

リポジトリ混同攻撃はどのように起こるのか？

• リポジトリ混同攻撃は依存関係混同攻撃に似ており、悪意ある攻撃者が対象に本物のバージョンではなく悪性バージョンをダウンロードさせる。
• 依存関係混同攻撃がパッケージマネージャーの動作の仕組みを悪用する一方で、リポジトリ混同攻撃は、人が誤って本物の代わりに悪性のバージョンを選んでしまうことに依存しており、ときにはソーシャルエンジニアリングの手法も使われる。

悪性リポジトリが使われると何が起こるのか

• 開発者が疑いなく悪性リポジトリを使うと、隠されたペイロードが7段階の難読化を解除し、悪性のPythonコード、さらにその後にバイナリ実行ファイルを取得する。
• 悪性コードは、さまざまなアプリのログイン認証情報、ブラウザのパスワードやCookie、そのほかの機密データを収集し、攻撃者のC&Cサーバーへ送信して追加の悪性活動を実行する。

GitHubにおける自動化の影響

• フォークされたリポジトリの大半はGitHubによってすぐに削除されるが、自動検知では多くのリポジトリを見逃し、手動でアップロードされたリポジトリは生き残る。
• 攻撃チェーン全体のほとんどが大規模に自動化されているため、生き残る1%でもなお数千件の悪性リポジトリを意味する。

キャンペーンが始まった時期

• 2023年5月: Phylumが最初に報告したところによると、現在のペイロードの初期部分を含む複数の悪性パッケージがPyPIにアップロードされた。
• 2023年7月 - 8月: PyPIが悪性パッケージを削除し、セキュリティコミュニティがそちらにいっそう注目するようになると、今度はPyPIパッケージを取得する代わりに直接ペイロードを配布する複数の悪性リポジトリがGitHubにアップロードされた。
• 2023年11月 - 現在: 類似の悪性ペイロードを含む10万件を超えるリポジトリが検知されており、その数は増え続けている。

パッケージマネージャーからソースコード管理(SCM)へのマルウェアの移行

• パッケージマネージャーとSCMプラットフォームで観測された多くの事例から、このキャンペーンがPyPI上の悪性パッケージからGitHub上の悪性リポジトリへ移行したことは、一般的な傾向を反映しているように見える。

リポジトリ混同から身を守る方法

• GitHubには通知済みであり、大半の悪性リポジトリは削除されたが、キャンペーンは継続しており、サプライチェーンに悪性コードを注入しようとする攻撃はますます一般的になっている。
• Apiiroは、接続されたコードベースを監視するマルウェア検知システムを構築している。
• さまざまな高度な技術を用いて攻撃を検知しており、これにはLLMベースのコード解析、コードを完全な実行フローグラフへ分解すること、高度なヒューリスティックエンジン、動的デコード、復号、難読化解除などが含まれる。

GN⁺の見解

• この記事は、GitHubリポジトリを利用する際に注意すべきセキュリティ脅威について、開発者に重要な情報を提供している。
• 悪性コードがソフトウェアサプライチェーンに侵入する仕組みを理解することで、開発者やセキュリティ専門家はより強固な防御メカニズムを構築できる。
• この種の攻撃は、開発者が信頼できるリポジトリを選択する能力だけでなく、CI/CD構成の正確性やサードパーティコードの安全性への依存も浮き彫りにしている。
• 批判的な視点で見れば、こうした攻撃は、GitHubのようなプラットフォームの自動化システムと大規模リポジトリの存在が諸刃の剣になり得ることを示している。
• 類似機能を提供するセキュリティツールとしては、SonarQube、Snyk、WhiteSourceなどがあり、コードの脆弱性を検出してセキュリティ強化に役立てられる。
• この技術を導入する前には、組織のセキュリティポリシーとの互換性、実装コスト、そしてチームメンバーの技術力を考慮する必要がある。
• この技術を選択することで得られる利点はセキュリティ強化とリスク低減だが、潜在的な欠点としては新しいシステムに対する学習コストと運用の複雑さがある。

[GN⁺]

Hacker Newsのコメント

• 公開リポジトリからコードを取得する際は注意が必要であり、依存関係ツリーを検証することが重要だとしている。これは、公開リポジトリ上のマルウェアが Large Language Models（LLMs）のような自動化ツールにどのような影響を与えるかという疑問を提起している。たとえば、GitHub Copilot のようなツールが、コーディングに関する質問への応答として誤ってマルウェアを含めてしまう可能性がある。
• GitHub は Usenet が失敗したのと同じような形で失敗しつつあると指摘している。誰でも GitHub にリポジトリを作成できる一方で、公式リポジトリとスパマーのリポジトリを見分ける方法がない。Amazon が「何でも売っている店」を目指したとき、商品の大半が粗悪品だという問題に直面した。GitHub は「誰にでも開かれたリポジトリ」なのか、それとも「このコードは信頼できるのか」という観点でのアイデンティティを確立すべきだとしている。
• サプライチェーンの問題は深刻だと訴えている。npm リリース自体を対象にはしていないが、プロジェクト監視のために socket.dev を使っているという。BrowserBox プロジェクトでは約 800 個の依存関係を利用しており、そのうち 19 個がトップレベル依存関係だという。すべての依存関係を npm の @browserbox ネームスペースにスナップショットし、脆弱性を追跡してパッチを当てる方法を検討している。
• 開発者は仕事用、趣味用、個人用として少なくとも 3 つの環境を分離すべきだと強調している。信頼できるリポジトリや所有者であっても、サンドボックス化された仮想マシンでコードを実行するのが賢明だとしている。
• 小規模チームで、週次ダウンロード数の多い SDK を開発している場合、snyk、aikido.dev、renovate ベースのソリューションなどを評価中だという。これらのツールが問題解決に役立つかは明確ではなく、snyk で経験したように大量の誤検知に対処するのは難しいとしている。
• curl と sudo を使ったシェルスクリプトによるインストール方式は、まもなく終わるのだろうかという疑問を示している。この方式は記事で言及された感染済みソフトウェアと密接に関係している。
• npm では --ignore-scripts オプションを使うことで、マルウェアの実行を防ぐことができる。
• 1 年も経たないうちに、トロイの木馬ウイルスを含むリポジトリが存在していたことに言及している。
• セキュリティ問題に関する最新の投稿が、LLM スタートアップに資金提供せよという広告につながっていることを批判している。こうしたスタートアップはセキュリティ上のギャップの一部しか埋められず、多数のスタートアップと契約することはコストや統合の問題を引き起こしかねないとしている。
• 継続的なセキュリティ報告を受けて、開発環境のセキュリティを段階的に改善しているという。VSCode 開発コンテナ、GitHub Codespaces、OWASP ガイドラインの読解、socket.dev を用いた npm / Python パッケージのレビューなどを試している。