yamory Blog

知らないうちにマルウェアをインストール マリシャスパッケージとは?

マリシャスパッケージとは、攻撃者によって作成された悪意のあるコードを含むパッケージのことです

(悪意のあるパッケージ、悪意のあるライブラリなどの表現をされることもありますが、英語では malicious package と表現されているため、ここではマリシャスパッケージと表現します。)

このパッケージをインストールすると環境変数に含まれる機微情報が抜き取られるなどの情報漏えい、クリプトマイニングのようなコンピュータリソースが悪用されるなど深刻な影響につながります。

次世代のソフトウェアサプライチェーンへの攻撃として登場し、近年攻撃が急増しています。

今回は、マリシャスパッケージとはどのような攻撃なのか、概要の説明と具体的にどのような攻撃手法があるのか、その対策方法について紹介します。

マリシャスパッケージとは?

マリシャスパッケージとは、攻撃者によって作成された悪意のあるコードを含むパッケージのことです。

マリシャスパッケージ(malicious package)は、悪意のあるパッケージや悪意のあるライブラリと表現されることもあります。

マリシャスパッケージをインストールすることで以下のような影響を受けます。

  • 環境変数やAWSクレデンシャルなどの機微情報が抜き取られる
  • 暗号資産のマイニングが行われリソースが悪用される
  • サービスが正常に利用できなくなる

マリシャスパッケージによる影響は、パッケージを作成した攻撃者の達成したい目的によって異なるため、上記に以外にも特定の地域のユーザーにだけ影響が出るようにしているものやビットコインのウォレットを狙ったものなど多岐に渡ります。

マリシャスパッケージを含む次世代のソフトウェアサプライチェーンによる攻撃は 2019 年から 2022 年まで平均 742% 増加と指数関数的に増加しています。

次世代のソフトウェアサプライチェーンへの攻撃(2019 - 2022)
次世代のソフトウェアサプライチェーンへの攻撃(2019 - 2022)(sonatype 8th Annual State of the Software Supply Chain より引用)

マリシャスパッケージをなぜインストールしてしまうのか

マリシャスパッケージは、正規のパッケージを利用しようとしている利用者にマリシャスパッケージをインストールさせることで目的を達成します。

ではなぜ利用者はマリシャスパッケージをインストールするのでしょうか。

攻撃者は、マリシャスパッケージをインストールさせるために以下の 3 つの攻撃手法を使って利用者にインストールさせます。

  • Dependency Confusion(依存関係かく乱攻撃)
  • タイポスクワッティング
  • 既存パッケージへのコード挿入

Dependency Confusion(依存関係かく乱攻撃)

Dependency Confusion(依存関係かく乱攻撃)は、2021 年 2 月にセキュリティ研究者より公開された新しいタイプのソフトウェアサプライチェーンへの攻撃です。

Dependency Confusion によって悪用が可能な状態だった企業へ報告した結果、Apple から 30,000 ドル、Microsoft から 40,000 ドルもの報奨金を得たということでも話題になりました。

Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies

ソフトウェアの開発時に、OSS などの世の中で広く公開されているパブリックパッケージと、社内などに限定して公開されているプライベートパッケージを組み合わせて作られていることがあります。

その場合に、本来プライベートパッケージからインストールすべきものを攻撃者によって作成された同じ名称のパブリックパッケージからインストールしてしまう、というものが Dependency Confusion の攻撃手法の概要になります。

具体的には、攻撃者はまず、プライベートパッケージと同じ名称のパッケージをパブリックパッケージとして公開し、バージョンを 9.9.9 といった高い値に設定して公開します。

その後、プライベートパッケージの利用者が、最新パッケージのインストールを行なったとします。

プライベートとパブリックの両方のパッケージを確認し、より高いバージョンのパッケージを優先してインストールする場合に、バージョンの高いパブリックのマリシャスパッケージをインストールしてしまうことで悪用に繋がります。

次世代のソフトウェアサプライチェーンへの攻撃(2019-2022)
Dependency Confusion(依存関係かく乱攻撃)の概要図

セキュリティ研究者よりこの攻撃手法が公開されてから模倣した攻撃が 3 日以内に 300 以上、1 ヶ月以内に 1 万を超えたと言われています。

Dependency Confusion Attacks Are Not Going Away - Why? | Sonatype

また、Dependency Confusion がレッドチーム演習の中で利用されたとの報告もあります。

Update: NPM dependency confusion hacks target German firms

タイポスクワッティング

タイポスクワッティングは、入力時のタイプミス(タイポ)によって想定していたものとは異なるものを取得してしまうことを利用した攻撃です。

例えば、URLを入力時に本来であれば apple.com と入力すべきところを、aple.com と入力してしまい不正なドメインへアクセスしてしまう、という攻撃がこれまでのタイポスクワッティングでは多かったと思います。

マリシャスパッケージにおいても、同様の攻撃が成り立ちます。

JavaScriptの有名なライブラリに jquery があり、npmのパッケージとしても提供されています。

以下のnpm レジストリで公開されているパッケージを見てみると、正規のパッケージのように思われます。

jquery とよく似た名称のマリシャスパッケージ jqeury
jquery とよく似た名称のマリシャスパッケージ jqeury(npm より引用)

しかし、よく確認してみると jquery ではなく、jqeury となっているため、ue の順序が反転していることがわかります。

(現在こちらのパッケージは既にnpmが保持するようになっています。)

とても単純な手法ではありますが、目視で判断・対処することは難しいものでもあります。

加えて、Checkmarx が StarJacking と名付けた攻撃を組み合わせることでより判断が困難になります。

Python のパッケージレジストリ PyPI で、以下のようなマリシャスパッケージが公開されていました。

jquery とよく似た名称のマリシャスパッケージ jqeury
正規の pampy ページ(右)とマリシャスパッケージ pampyio のページ(左)(StarJacking - Making Your New Open Source Package Popular in a Snap | Checkmarx.com より引用)

右側が正規の pampy と呼ばれるパッケージの PyPI でのページ、左側が攻撃者によって作成された pampyio のページになります。

プロジェクトの概要に関しても同様に作成され、また Statistics の部分にある GitHub のスター数、フォーク数までも同じ値を表示しています。

これは、パッケージレジストリ側で GitHub のリポジトリの所有権の検証を行なっていないため、マリシャスパッケージと正規の GitHub のリポジトリを紐付けて公開できてしまうことによって発生しています。

このように、StarJacking は、パッケージのメタデータである GitHub のスター数などを偽装し、信頼できるパッケージのように偽装するため、正規なパッケージなのかどうかの判断がより困難になります。

既存パッケージへのコード挿入

既存パッケージへのコード挿入は、既に広く使われているパッケージを改ざんし、情報露えい等を引き起こすコードを挿入しパッケージを公開する攻撃になります。

過去に起こった例として、2018 年に起こったnpmのパッケージ event-stream のインシデントが有名です。

npm Blog Archive: Details about the event-stream incident

改ざんされたパッケージには、ビットコインのウォレットを狙ったコードが挿入され、秘密鍵を収集するような挙動が追加されていました。

なぜパッケージが改ざんされたのでしょうか。

このインシデントでは、攻撃者が event-stream のメンテナとして権限を得て、改ざんを行いました。

このようにソーシャルエンジニアリング攻撃によって、OSS のメンテナの権限が攻撃者の手に譲渡されることもありますが、それ以外に場合もあります。

PyPI の ctx と呼ばれるパッケージが改ざんされ、AWS のシークレットキーなどが収集されるコードが挿入されたこともあります。

この事件では、パッケージのメンテナのメールアドレスのドメインが失効していたため、そのドメインを取得しパッケージへの改ざんを可能にしました。

上記以外にも、OSS のメンテナ自身が抗議のためなど、自身の意志の表明のためにコードを改変することもあり、そのようなソフトウェアを Protestware と呼ぶこともあります。

npm の node-ipc パッケージにロシアとベラルーシの IP を標的としたシステム上のすべてのファイルをハート文字に置き換えるコードが追加されたこともありました。

node-ipcのように、正規のパッケージであったとしても、新しく公開されたパッケージに悪意のあるコードが挿入され、特定のバージョンのみマリシャスパッケージとして公開されることもあります

従来の対策では困難な理由

マリシャスパッケージの問題は、従来の脆弱性対策では防げていない可能性があります

マリシャスパッケージは、セキュリティ上のミスによって生まれる脆弱性とは異なり、マルウェアに近いため脆弱性の識別子である CVE ID が割り当てられないことも多くあります

そのため、CVE ID をベースとして脆弱性対策を行なっている、NVD などの CVE ID が割り振られた脆弱性情報源のみから情報収集を行なっている場合にはマリシャスパッケージの問題に気づきにくいという問題があります。

マリシャスパッケージに CVE ID が割り当てられない理由は、CVE ID を割り当てる脆弱性にはルールがあり、そのルールの中にマルウェア(の脆弱性)は除くなどが定められている INC4 に当てはまらないためであると考えられます。

CVE Counting Rule INC4 Exclusions
CVE ID の割り当てルール(CNA Rules 2.0: Counting Rules (pptx) より引用)

CVE ID がないだけでなく、マリシャスパッケージが依存関係の中に組み込まれる可能性があることも対策を困難にしている理由としてあります。

StarJacking の例で取り上げたマリシャスパッケージ pampyio に関しても、pampyio 自身は無害なパッケージですが、pampyio の依存関係に含まれている redapty というパッケージに悪意のあるコードが挿入されているため、pampyio をインストールすると悪用されてしまう、というものでした。

event-stream のインシデントに関しても、event-stream の依存関係に追加された flatmap-stream に悪意のあるコードがあったために問題となりました。

このように、攻撃者はできるだけ気づかれにくくするために依存関係の中にマリシャスパッケージを組み込むことがあります

対策

マリシャスパッケージへの対策として重要なポイントは以下の3つです。

  • 依存関係を含めたソフトウェア管理(SBOM)
  • CVE ID が割り当てられていないものを含めた脆弱性情報の収集
  • 自動化されたソリューション

依存関係を含めたソフトウェア管理(SBOM)

マリシャスパッケージは、攻撃者によって依存関係の中に組み込まれることがあるため、直接利用しているパッケージだけでなく、間接的に利用しているパッケージ含めてソフトウェアの把握・管理することがまずは重要です。

そのための手法として、近年注目を集めている SBOM(Software Bill of Material)というものがあります。

SBOM はソフトウェア部品表のことで、ソフトウェアサプライチェーンのなかで利用されているソフトウェア部品を正確に把握するためのものです。

SBOM を作成し、自分たちが利用しているソフトウェアを依存関係含めて正しく管理することで、マリシャスパッケージ含めて脆弱性管理をより正確に行うことができるようになります。

SBOM に関する詳細に関しては以下の記事をご覧ください。

背景と具体例から学ぶ SBOM

SBOM(ソフトウェア部品表)の重要性と効率的な対応方法~オンラインセミナー開催レポート~

CVE ID が割り当てられていないものを含めた脆弱性情報の収集

マリシャスパッケージは、マルウェアに近いため CVE ID が割り当てられず、NVD などの脆弱性データベースで管理されていないため情報収集が難しいのが現状です。

event-stream のインシデントに関しても CVE ID が割り当てていないため、多くのセキュリティサービスが独自の ID を割り当てて管理しています。

一つの情報源から情報を収集するのではなく、様々な情報源から収集し、マリシャスパッケージに関する情報も取得できる仕組み作りを行うことが大切です。

自動化されたソリューション

SBOM を作成し、収集した情報から判断することは可能ではありますが、近年攻撃の数が急増していることからも手動での対応は困難になってきています。

マリシャスパッケージを含めて脆弱性の検知、対応、管理が可能な自動化されたソリューションを使うことで、手動での管理コストが減り、網羅的に管理でき、結果的にコストの削減にも繋げることができます

Dependency Confusion 対策

上記以外にも、Dependency Confusion の対策として事前にパブリックレジストリにパッケージ名、名前空間を取得するという方法もあります

Dependency Confusion は利用しているパッケージマネージャや利用環境によって実施できる対策も異なります。

以下のサイトが参考になります。

Dependencies, Confusions, and Solutions: What Did Twilio Do to Solve Dependency Confusion

3 Ways to Mitigate Risk When Using Private Package Feeds | Microsoft

おわりに

今回は、次世代のソフトウェアサプライチェーンへの攻撃として登場し、近年攻撃が急増しているマリシャスパッケージについて解説しました。

マリシャスパッケージ(malicious package)は、悪意のあるパッケージや悪意のあるライブラリと表現されることもあります。

マリシャスパッケージは、CVE ID が割り当てられず、従来のセキュリティ対策では防げていない可能性もあります。

まずは、自分たちの環境に影響が出ていないか、対策として何が考えられるのか検討してみることをおすすめします。

yamory ではマリシャスパッケージへの対応開始しました。

ご興味がある方はこちらより資料請求を行うことができます。

セミナーも定期的に開催していますのでこちらのページよりご確認ください。

脆弱性対策なら yamory
IT システムをスキャンし脆弱性リスクを把握しましょう

お気軽にお問い合わせください。担当者よりご連絡いたします。
お問い合わせ