NPM・PyPi上のPaysafe、Skrill偽SDKが認証情報を窃取

Node Package Manager(npm)およびPython Package Index(PyPI)上の悪意あるパッケージが、Paysafe、Skrill、Netellerの決済アプリケーション開発者・利用者にスティーラー型マルウェアを配布していたことが分かりました。

脅威アクターは少なくとも17個の悪意あるパッケージを同時に公開しており、それぞれがAmazon Web Services(AWS)上でホストされているコマンド&コントロールサーバーに認証情報とアクセストークンを流出させる役割を担っていました。

これら3つの決済プラットフォームはいずれも広く利用されており、なかでもPaysafeはEコマースサイトやオンラインマーケットプレイス、ゲームプラットフォーム、旅行関連事業、金融サービスやSaaS(Software-as-a-Service)事業者を中心に使われています。

SkrillとNetellerはデジタルウォレット・送金サービスで、オンラインベッティングや仮想通貨取引所、FX取引プラットフォームで利用されています。

こうしたプラットフォーム向けにソフトウェアを開発するエンジニアは、安全な決済・資金管理システムを実装するため、アプリやウェブサイトにPaysafeのSDKを組み込んでいます。

アプリケーションセキュリティ企業のSocketによると、今回のキャンペーンではこうした開発者が標的となっており、以下のパッケージが使用されていました。

研究者らによると、13個のnpmパッケージは1.0.0から1.0.3まで4つの悪意あるバージョンを公開していた一方、PyPIパッケージは1.0.0のみ、1つの悪意あるバージョンしか公開していませんでした。

17個すべてのパッケージは正規の決済SDKを装っており、想定されるAPIまで公開していますが、実際にはPaysafeのバックエンドサービスと通信する代わりに、偽の成功レスポンスを返す仕組みになっています。

真の狙いは認証情報の窃取であり、組み込まれた悪意あるコードは侵害された環境内でトークンやパスワード、APIキーといった機密情報を探索します。

Socketによれば、流出したデータにはPaysafe APIキー、AWSキー、GitHubトークン、npmトークン、ホスト名、ユーザー名、API利用状況に関するメタデータが含まれていました。

npmパッケージ内のデータ窃取モジュールは、Paysafe APIキーが存在する場合にのみ情報流出を試み、偽のSDKが呼び出された際に起動します。

一方PyPIパッケージは、初期化時にデータ窃取ルーチンを自動的に起動する仕組みで、Paysafe APIキーの有無はまったく関係ありません。

Socketがこのマルウェアを分析した結果、比較的単純な解析回避機能も備えていることが判明しました。CPUコア数が2未満と検知した場合や、ホスト名・ユーザー名に仮想化環境を示唆する痕跡が含まれる場合には、実行を停止するようになっています。

今回のキャンペーンの背後にいる人物は不明ですが、Socketのレポートでは、脅威アクターが十分な技術力を持ち、今後より組織的な形で再び活動する可能性を示唆する特徴が指摘されています。

研究者らは、攻撃者が複数のエコシステムを横断的に行き来できる能力を持っているため、単一のエコシステムのみを監視していたのでは防御が難しくなる可能性があると警告しています。

上記に挙げたパッケージのいずれかをインストールしてしまった場合、開発者は「このパッケージをインポートあるいは実行したすべてのマシン上のシークレットを直ちにローテーションする」ことが推奨されています。

研究者らはまた、依存関係ツリーの中から今回のキャンペーンで使用されたパッケージ名を検索し、レジストリプロキシのレベルでそれらへのリクエストを拒否するよう助言しています。

さらに、継続的インテグレーション(CI)システムのログにおいて、PAYSAFE_API_KEYと今回挙げたパッケージ名の組み合わせがないか確認することも推奨されています。

攻撃者より先にあらゆる階層をテストする

セキュリティチームが検知できているのは、成功した攻撃のうち54%に過ぎず、アラートが発報されるのはわずか14%です。残りは環境内を気付かれずに移動しています。

Picusのホワイトペーパーでは、breach and attack simulation(侵害・攻撃シミュレーション)によってSIEMやEDRのルールをテストし、検知をすり抜ける脅威を防ぐ方法を紹介しています。