目的は、パッケージのダウンロード数を水増ししてTeaトークンを盗むこと。システムが収益化されれば利益を得る可能性も。
協調的なトークンファーミングキャンペーンが、オープンソースのnpmレジストリを引き続き氾濫させており、Tea Protocolを使ってコーディング作業に報酬を与える開発者からトークンを盗むために、ほぼ毎日数万件の感染パッケージが作成されています。
木曜日、Amazonの研究者によると、このキャンペーンで15万件以上のパッケージが確認されました。しかし、2024年4月にこのキャンペーンについて記事を書いたソフトウェアサプライチェーン管理プロバイダーSonatypeの幹部は金曜日、CSOの取材で、その数が現在15万3千件に増えていると語りました。
「残念ながら、このワームはいまだに制御下にありません」とSonatype CTOのBrian Fox氏は述べています。
そして、このペイロードが単にトークンを盗むだけであっても、他の脅威アクターも注目していると彼は予測しています。
「世界のどこかで、この大量に複製されるワームを見て、Teaトークンを得るだけでなく、実際のマルウェアを仕込めるのではと考えている人がいるはずです。これほど速く複製されるなら、やらない理由がありません」
Sonatypeがちょうど1年前にこのキャンペーンについて書いた際、1人の人物から発信されたと思われるパッケージはわずか1万5千件でした。
今週報告された膨れ上がった数について、Amazonの研究者は「これはオープンソースレジストリ史上最大級のパッケージ氾濫事件の一つであり、サプライチェーンセキュリティの転換点を示している」と記しています。
このキャンペーンは、脅威アクターが複数のオープンソースリポジトリのセキュリティホールを悪用する最新の手口に過ぎず、npmやPyPIなどのサイトの評判を損なうリスクがあります。
「オープンソースリポジトリにおけるマルウェアの蔓延は、完全に制御不能な危機であり、オープンソース上流サプライチェーンへの信頼を危険なほど損なっています」と、ソフトウェア部品表ソリューションを提供するCybeatsのCTO、Dmitry Raidman氏は述べています。
その証拠として、彼はShai‑Huludワームによるnpmエコシステムの急速な悪用を挙げ、攻撃者が開発者トークンをハイジャックし、パッケージを改ざんし、依存関係全体に横展開できる速度を示しています。「単一の侵害から始まったものが数時間で爆発的に広がり、オープンソースか商用かを問わず、数日で業界全体のエコシステムとすべての下流プロジェクトが危険にさらされます。」
昨年9月、Raidman氏はNxビルドシステムの侵害について執筆しました。脅威アクターがnpmに悪意あるバージョンを投入した後、数時間以内に世界中の開発者が知らずにSSHキー、認証トークン、暗号通貨ウォレットを盗むコードを取り込んでいたと記しています。
これらや最近の大規模な悪意あるパッケージのオープンソースリポジトリへのアップロードは「ほんの始まり」に過ぎないと、彼は警告します。開発者やリポジトリ管理者がセキュリティを強化しなければなりません。
AmazonやSonatypeのレポートは、このキャンペーンを最初に検出したものではありません。オーストラリアの研究者Paul McCarty氏（SourceCodeRed）は、今週のブログでこのワームを「IndonesianFoods」と名付けたことを認めています。
Teaプロトコルとは
Teaプロトコルは、オープンソース開発者やパッケージ管理者に、ソフトウェア開発の報酬としてTeaと呼ばれるトークンを与えるブロックチェーンベースのプラットフォームです。これらのトークンは、ソフトウェアサプライチェーンのセキュリティ向上や、ネットワーク全体の分散型ガバナンスにも役立つと公式サイトで説明されています。
開発者は、ブロックチェーンにリンクするTeaコードをアプリに組み込みます。アプリが多くダウンロードされるほど、より多くのTeaトークンを獲得でき、それをファンドを通じて現金化できます。ワームの仕組みは、脅威アクターが作成したアプリが非常に人気があるとブロックチェーンに思わせ、多くのトークンを得ることを狙っています。
現時点では、トークンには価値がありません。しかし、脅威アクターは、Teaプロトコルがメインネットをローンチし、Teaトークンが実際の金銭的価値を持ち取引可能になった際に、本物の暗号通貨トークンを受け取るための準備をしていると疑われています。
今のところ、SonatypeのFox氏によれば、この仕組みはnpm管理者の時間を浪費させているだけで、彼らは10万件以上のパッケージを排除しようとしています。しかしFox氏やAmazonは、この仕組みが他の報酬型システムを金銭目的やマルウェア配布に悪用しようとする人々を刺激する可能性があると指摘しています。
ITリーダーと開発者が取るべき対策
悪用のリスクを下げるため、オープンソースリポジトリはアクセス制御を強化し、コードをアップロードできるユーザー数を制限すべきだとCybeatsのRaidman氏は述べています。開発者のログイン情報が盗まれた場合に備えて多要素認証を導入し、アップロードされたコードにデジタル署名機能を追加して著者を認証することも含まれます。
ITリーダーは、自社で利用するすべてのコードにソフトウェア部品表（SBOM）があることを求めるべきです。そうすればセキュリティチームが構成要素を把握できます。また、開発者がアプリに含めるオープンソースコードのバージョンを把握し、承認済みで安全なバージョンのみを使用し、新しいバージョンがリポジトリからダウンロードされたからといって自動的に変更されないようにすることも必要です。
SonatypeのFox氏は、ITリーダーはリポジトリからの悪意あるダウンロードを傍受・遮断できるツールを購入する必要があると述べています。ウイルス対策ソフトはここでは役に立たない、と彼は言います。なぜなら、リポジトリにアップロードされた悪意あるコードは、AVツールが検出するはずのシグネチャを含んでいないからです。
Amazonブログの著者である研究者Chi Tran氏とCharlie Bacon氏は、メールでの質問に対し、オープンソースリポジトリは悪意ある設定ファイル、最小限またはクローンコード、予測可能なコード命名規則、循環依存チェーンなどの疑わしいパターンを特定するための高度な検出システムを導入する必要があると述べました。
「同じくらい重要なのは、パッケージ公開速度の監視です。自動化ツールは人間の開発者では到底追いつけないスピードで作成します。加えて、著者の検証強化や責任追及措置も予防に不可欠です。これには新規アカウントの本人確認強化、今回のキャンペーンのように複数の開発者アカウントにまたがる協調的な公開活動の監視、悪意ある活動と関連付けられたアカウントからのパッケージに対する『連座制』の適用などが含まれます。リポジトリは、アカウントの急速な作成と大量パッケージ公開といった自動化悪用の特徴的な行動パターンも追跡すべきです。」
Amazonの著者は、CISOが自社環境でこれらのパッケージを発見した場合、「現在のセキュリティ対策が協調的なサプライチェーン攻撃を検出できなかったという不都合な現実」に直面すると付け加えています。
SourceCodeRedのMcCarty氏は、ITリーダーは開発者のノートPCだけでなく、自動化された継続的インテグレーション／デリバリーパイプライン（CI/CD）も保護する必要があると述べています。従来のセキュリティツールであるEDRやSCAはマルウェアをスキャンしないと警告しています。「Snykを購入すればこれができると思っている人は非常に多い」と彼は言います。
McCarty氏は2つのオープンソースマルウェアスキャンツールを作成しています。1つ目のopensourcemalware.comは、npmパッケージなど悪意あるコンテンツのオープンデータベースです。使用中のパッケージが悪意あるものかどうかを確認できます。2つ目は自動化されたオープンソースのMALOSSツールで、opensourcemalware.comや他の情報源を自動的にチェックするスキャナーです。MALOSSはCI/CDパイプラインやローカルワークステーションで利用できます。
また、商用またはオープンソースのパッケージファイアウォールの利用も推奨しています。これにより、開発者は承認済みパッケージのみをインストールできます。
「企業には自分たちが思っている以上に選択肢があります」と彼はCSOに語りました。「このリスクに対処するためのツールやソリューションが存在することに、気づいていないだけなのです。この分野の成熟度は非常に低いです。」
この記事はもともとInfoWorldに掲載されたものです。
