Package Planting(パッケージプランティング)：知らない内に汚染されたパッケージのメンテナーになっていませんか？ #aqua #セキュリティ #npm #packageplanting #github
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「Aqua Security」社の技術ブログで2022年4月26日に公開された「 Package Planting: Are You [Unknowingly] Maintaining Poisoned Packages? 」の日本語翻訳です。
Package Planting(パッケージプランティング)：知らない内に汚染されたパッケージのメンテナーになっていませんか？
Aqua のセキュリティ研究チームである Team Nautilus は、攻撃者が悪意のあるパッケージを正規のものとして装い、猜疑心のない開発者を騙してそれをインストールさせることを可能にする npm の論理的欠陥を発見しました。最近まで npm は、パッケージのユーザに通知することなく、また同意を得ることなく、誰でもパッケージのメンテナーとして追加できました。どんな人気のあるメンテナーの下にも毒されたパッケージを割り当てることができたので、私たちはこの論理的欠陥とその意味を「Package Planting(パッケージ・プランティング)」と名付けました。私たちは、これらのテクニックを npm チームに報告し、根本的な問題が修正されました。
Package Planting とは
npm のユーザは、これらのユーザの承認を得ることなく、他のユーザをパッケージのメンテナーとして追加できます。
攻撃者は悪意のある npm パッケージを作成し、数人のユーザをメンテナーとして追加できます。攻撃者がこれらの将来のメンテナーを注意深く選ぶと、パッケージの評判や外観に影響を与えることになります。言い換えれば、攻撃者は悪意のあるパッケージを作成し、信頼できる人気のあるメンテナーを追加できます。
例えば、lodash というパッケージは非常に人気があり、信頼できるものです。その所有者である Mathias、jdalton、bnjmnt4n を新しい悪意のあるパッケージのオーナーとして追加すれば、多くの開発者はこのパッケージが正当で魅力的であると騙される可能性があります。
以下は、Package Planting のシナリオの例です。
悪意のあるパッケージのマスカレード化
攻撃者は、Package Planting を利用することで、どんな悪意のあるパッケージでも、それを正当で魅力的なものに見せかけることができます。ここでは、その概念を説明し、どのようにこの欠陥を利用が可能であったかを紹介します。
- fb_npm_package という名前で npm パッケージを作成し、公開します。
- 陥れたいユーザをオーナーとして追加します。今回は、npm と Facebook の npm プロファイルを使用することにしました。
- パッケージのオーナーから自分自身を削除します。
この3つの簡単なステップで、npm と Facebook がこの新しいパッケージの所有者となり、どこから見ても合法的に見えます。強制的に追加されたユーザは、他のパッケージのメンテナーとして誰かに追加されたことに気づいていません。
この問題のポイントは、npm ユーザなら誰でもこれを実行でき、他の npm ユーザを自分のパッケージのメンテナーに追加できることです。適切な招待確認メカニズムがあれば、これを防ぐことができました。現在は、npm でユーザを組織に追加するときや GitHub で共同作業者を招待するときに、このメカニズムが働いています。
デベロッパーの名誉毀損
攻撃者は Package Planting を使って悪意のあるパッケージを作成し、中傷したい開発者を npm に追加し、これらの開発者がプラットフォームを悪用していることを npm に報告できます。これにより、開発者を困らせたり、プラットフォームから追放できます。このようなシナリオはあり得ないという人に向けて、その考えを変えるような興味深い話を紹介しましょう。
WhatsApp は、違法行為や悪意ある行為を示唆するような無神経な名前を持つグループの一員であるユーザを禁止しています。あるグループのメンバーが冗談で、違法行為を示唆するようなグループ名に変更したケースもありました。その結果、そのグループの各メンバーは、WhatsApp 上で即座にブロックされました。
また、悪意のある人間が新しいグループを作成し、他の連絡先を追加(WhatsApp の設定がこれを許可している)した後、グループ名を変更したため、WhatsApp がそのチームメンバー全員をブロックしたケースもありました。
パッチ対応：招待確認メカニズム
npm は私たちがこの問題を報告した後、すべての新しいパッケージメンテナーに対して確認の仕組みを追加することで、速やかにこの欠陥を修正しました。
現時点では、この問題は解決されており、ユーザからの確認なしに新しいメンテナーを追加できなくなりました。
新しいメンテナーを招待すると、その人のメールアドレスに招待リンク付きのメールが送信されるようになりました。
まとめ
このブログで説明されている問題は npm によって修正され、現時点では再現する方法はありません。GitHub/npm セキュリティチームの迅速な対応と専門的な修正プロセスに感謝します。
過去数年間、オープンソースプロジェクトはそのセキュリティを大幅に向上させてきました。しかし、攻撃者はより巧妙になり、それらを悪用する新しい方法を考え出しています。
結局、開発者は、アプリケーションを構築する際に、どのオープンソースパッケージを使用するのかについて責任を負うことになります。リスクを軽減するためには、サードパーティのコンポーネントはすべて信頼できるソースを使用し、Package Planting などのソフトウェアのサプライチェーンの脅威を検出できるソリューションで環境を保護することが重要です。
最後に、npm ユーザは、自分の名前で表示されているすべてのパッケージが本当に自分のものであるか、また、自分の同意なしにプロジェクトへ追加されていないかを確認する必要があります。
発見の時系列
- 10-02-2022：この問題は、HackerOne にある GitHub のバグバウンティプログラムに報告されました。
- 13-02-2022：GitHub から、この問題は内部的に追跡されており、積極的に解決に取り組んでいるとの回答を得ました。
- 26-04-2022：npmjs.com でこの問題が修正されました。
