知らないうちにマルウェアをインストール マリシャスパッケージとは？
マリシャスパッケージとは、攻撃者によって作成された悪意のあるコードを含むパッケージのことです。
（悪意のあるパッケージ、悪意のあるライブラリなどの表現をされることもありますが、英語では malicious package と表現されているため、ここではマリシャスパッケージと表現します。）
このパッケージをインストールすると環境変数に含まれる機微情報が抜き取られるなどの情報漏えい、クリプトマイニングのようなコンピュータリソースが悪用されるなど深刻な影響につながります。
次世代のソフトウェアサプライチェーンへの攻撃として登場し、近年攻撃が急増しています。
今回は、マリシャスパッケージとはどのような攻撃なのか、概要の説明と具体的にどのような攻撃手法があるのか、その対策方法について紹介します。
マリシャスパッケージとは？
マリシャスパッケージとは、攻撃者によって作成された悪意のあるコードを含むパッケージのことです。
マリシャスパッケージ (malicious package) は、悪意のあるパッケージや悪意のあるライブラリと表現されることもあります。
マリシャスパッケージをインストールすることで以下のような影響を受けます。
- 環境変数やAWSクレデンシャルなどの機微情報が抜き取られる
- 暗号資産のマイニングが行われリソースが悪用される
- サービスが正常に利用できなくなる
マリシャスパッケージによる影響は、パッケージを作成した攻撃者の達成したい目的によって異なるため、上記に以外にも特定の地域のユーザーにだけ影響が出るようにしているものやビットコインのウォレットを狙ったものなど多岐に渡ります。
マリシャスパッケージを含む次世代のソフトウェアサプライチェーンによる攻撃は2019年から2022年まで平均742%増加と指数関数的に増加しています。
次世代のソフトウェアサプライチェーンへの攻撃 (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といった高い値に設定して公開します。
その後、プライベートパッケージの利用者が、最新パッケージのインストールを行なったとします。
プライベートとパブリックの両方のパッケージを確認し、より高いバージョンのパッケージを優先してインストールする場合に、バージョンの高いパブリックのマリシャスパッケージをインストールしてしまうことで悪用に繋がります。
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（npmより引用）
しかし、よく確認してみるとjqueryではなく、jqeuryとなっているため、uとeの順序が反転していることがわかります。
（現在こちらのパッケージは既にnpmが保持するようになっています。）
とても単純な手法ではありますが、目視で判断・対処することは難しいものでもあります。
加えて、Checkmarxが StarJackingと名付けた攻撃を組み合わせることでより判断が困難になります。
PythonのパッケージレジストリPyPIで、以下のようなマリシャスパッケージが公開されていました。
正規の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 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（ソフトウェア部品表）の重要性と効率的な対応方法～オンラインセミナー開催レポート～
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ではマリシャスパッケージへの対応開始しました。
ご興味がある方はこちらより資料請求を行うことができます。
セミナーも定期的に開催していますのでこちらのページよりご確認ください。
