最近のESLintハック、または悪意のあるnpmパッケージのインストールから自分自身を保護する方法を教えてください。
最近、 eslint-scopeおよびeslint-config-eslintパッケージは興味深い方法でハッキングされました -メンテナのアカウントの1つが攻撃者によって侵害され、悪意のあるコードを含む新しい「パッチ」バージョンがnpmレジストリに公開されました。
この悪意のあるコードは「ポストインストール」スクリプトとして実行され、Pastebinサイトから特定のJSコードを評価し、ローカルのnpmrcファイルからnpm認証トークンを盗んで、histatsヘッダー内のstatcounterおよびRefererエンドポイントに送信しようとしました。攻撃の詳細については here を参照してください。興味深いことに、この問題は、悪意のあるコードの実装に現れる構文エラーが原因で発見されました。
ESLintチームが問題に対処するのに数時間かかったことを考慮に入れると、多くのnpm認証トークンが盗まれました。これは、他のパッケージが将来同じ方法で汚染される可能性があることを意味します。
Npmユーザーとして、npmレジストリから依存関係をインストールするときに、将来の同様のハッキングから自分をどのように保護できますか？
3つの単語：サプライチェーン管理。私たちの場合を除いて、「供給」は依存関係または「サードパーティライブラリ」です。
これはnpmに固有の問題ではありません。これはソフトウェア開発における一般的な問題です。これは、「ねじ」のメーカーのグーグルに相当します。次に、「ねじ」の最初のメーカーを使用します。「ねじ」の仕様について尋ねないで、これらの「ねじ」を使用して、正しく機能し、壊れない、侵食/錆が速すぎてひずみに対処できる...これらのネジがテストされているかどうかを確認することなく、適切な品質管理が行われます。これは、ソフトウェアにバグがある場合や脆弱な場合、通常は死なないためです。ネジがバギーだったために構造が崩壊した場合...それは別の話です。そこには説明責任があります。ソフトウェアにそのような説明責任はありません...ソフトウェアのバグが発生したとき、または制御ソフトウェアにバグがある場合に巨大で高価な機械が故障したとき（および/または生命を危険にさらしたとき）に実際に危機に瀕しているいくつかの業界で働いている場合を除きます。 。そして、それは深刻な死を意味します。リアルタイム通信を維持してプロセスをリアルタイムで制御する必要があり、使用するサードパーティライブラリが生成したものすべてがブームになる場合、危険なマシンを制御する組み込みデバイスを厳密にチェックせずにサードパーティライブラリを使用することはできませんバグがあるため、CPU障害が発生します...マシンが実際に損傷を受けるためです。
ソフトウェア開発の問題は、「一部のライブラリ」の「グーグル」が「一部の機能」を提供し、「npm install」、「go get」、「pip install」を実行するだけです。そこには検証プロセスはありません。パッケージが主張するものを提供していることをどのようにして知っていますか？それがどれほどよくテストされているか知っていますか？それがまだ活発に維持されているかどうか知っていますか？ APIの安定性の保証について知っていますか？一部のパッケージは「取得」でき、パッケージは1週間後に完全に破損します。これは、「公式」に見ているgoコードでもAPIの安定性が保証されていない場合があるためです。
どのバージョンの制約を使用しますか？ _foo >= 1.5_。 _foo >= 1.6_がバックドアを導入するとどうなりますか？最新バージョンでコードをコンパイルしている人には、このバックドアが含まれています。 _foo == 1.5_を使用しているが、さまざまなミラーがあり、同僚がソフトウェアのビルドに使用したミラーに悪意のあるバージョンのパッケージが含まれている場合はどうなりますか？そして、忘れないでください：パッケージ/ライブラリをインストール/使用する場合は？そのパッケージ/ライブラリを確認するだけでなく、依存関係ツリー全体を確認する必要があります。
必要なのは、認定プロセスです。会社/開発者がパッケージの準備ができていると考えたら、それを公開し、独立したコードレビューとセキュリティ会社がパッケージをレビューし、このパッケージが使用するのに「安全」であるという合理的な確信が得られたら、署名します。次に、署名された依存関係のみを使用でき、foo == ("1.5", "abc734defef373f..")などのバージョンに加えてハッシュを使用します。
これをnpmにどのように適用しますか？
レビューなしでnpmパッケージをインストールしないでください。作者は誰ですか？一般的なコード品質はどのくらいですか？最後に更新されたのはいつですか？最後のいくつかのコミットは何でしたか？インストールするとどうなりますか？適切なテストはありますか？コード/テストカバレッジとは何ですか？何人が使っていますか？誰が使用していますか？
ソフトウェア開発は、更新、新しいもの、更新、新しいものを提供することに焦点を当てています。適切なテストと適切な「サードパーティのコード管理」には多くのコストがかかり、ほとんどの場合、企業も消費者もその価格を支払う気はありません。結局のところ、それは常に「リスク対コスト」です。セキュリティの脆弱性の代償として、一部のユーザーが資格情報を盗んだ場合...誰も気にしません。彼らはあなたを訴えることはできません..最悪の場合、それはあなたに「公開イメージ」で少し費用がかかります。最悪の場合、一部のユーザーには機能しないバグのあるソフトウェアです...とにかく無料版を使用していたユーザーに腹を立てることができます...これは、「保証」のようなものがあった場合、おそらく変わるでしょう。ソフトウェアとソフトウェアのバグに対する責任（誰かがあなたに何かを書くためにお金を払うときのために存在します）ですが、多くのソフトウェアはオープンソースであり、保証/保証がまったくありません（これは実際にはこれの1つの大きな欠点です）または無料で使用しているソフトウェアは、そのようなソフトウェアでは発生しません。
この問題は、WebサイトでサードパーティのJavaScriptを使用した場合にも発生します。同じこと。使用する言語、フレームワーク、テクノロジーに関係なく、問題はほぼ完全に同じです。安全を確保するには、サードパーティのコードを検証する必要があります。
もう1つ：
わずかなユーティリティのみを提供するパッケージ/ライブラリがあります... 3時間で自分で書いたもの...多分1日。これ以上の依存関係を気にしない場合は問題ではありません（依存関係が増えると依存関係の管理が複雑になります）。そうすると、このような単純なライブラリを使用せずに機能を自分で作成するほうが、実際にはそれほど手間がかかりません。あなたはそれを完全に制御でき、適切にテストできます。経験則としては、他人のコードを検証するのに、自分で書くよりも時間がかかる場合は、自分で記述します。これは、フレームワーク全体から1つまたは2つの関数のみが必要な場合にも適用されます。フレームワーク自体に依存関係があり、フレームワークも検証する必要があるため、フレームワーク全体を含めて検証するよりも、いくつかの関数の2つのバージョンを適切にチェックする方がはるかに簡単です。
それ以外：...ホワイトリストに登録されていないWebサイトへのトラフィックをインストールプロセス中にブロックできます。つまり、この特定の攻撃は機能しませんが、ランダムファイルを削除したりバックドアを挿入したりする悪意のあるインストールスクリプトに対しては機能しません。既存のファイルなど。インストールスクリプトを注意深く読む必要があります。
理論的にはサプライチェーン管理が正しい答えですが、snykや他の多くの企業の努力にもかかわらず、実際にはノードエコシステムでこの問題を解決する方法はありません。
ノードのサプライチェーンの記録は、それをより良くするために働いている多くの人々に無礼を意図していないので、独特にひどいです。その悪名高い山の王は、以前はwordpress=モジュールでしたが、少なくとも過去数年間は現在ノードでした。セキュリティの失敗は、ビジネスを営むためのコストにすぎません。
理論的には、次のことができます。
- インストールする前に依存関係のすべてのコードを読んでください
- 依存関係のすべてのコードを読む
- サーバーのホワイトリストを使用してサンドボックスにインストールする
- 依存関係をホワイトリストに登録し、数週間以上のベイク期間が必要
- 脆弱性フィード、スキャナー、アナライザーを持ち込む
- ノードエンジニアのワークステーションは常に危険にさらされていると想定し、シークレット管理を使用し、パスワードの閲覧を許可したり、運用システムやデータに直接アクセスしたりしないようにします。
- 修正が発表されたときに特定の依存関係を消費するすべてのアプリケーションを見つけて再デプロイできるCI/CDがある
または、いくつかの作業を完了して、エコシステムが改善するまで（最終的にはそれが改善されるまで）最高の状態を期待できます。
基本的にここでの問題は、サードパーティのソフトウェアが個人情報を盗んでネットワーク経由で送信しようとしたことです。この問題はnpmに固有のものではありません。ユーザーデータの読み取りを妨げるものがないので、コンピューターユーザーとして実行されているソフトウェアは実際に同じことを実行できます。
このような攻撃に対する防御策として、送信ファイアウォールの使用を検討する場合があります。
多くのそのような製品があり、主に商用ですが、Nodeプロセスがホストに接続しようとする場合、かなり有名なLittle Snitch（私はこれとは関係ありません）ファイアウォールがアクセス許可を与えるように構成されていない場合、ユーザーは次のように、その接続の確立を許可するかどうかを決定するよう求められます。
当然、npmモジュールのインストール中にこのような状況が発生した場合は、いくつかの赤旗が発生するはずです。この接続のソースを監査するまで、アクセスを拒否することで、この時点で停止できます。
明らかに、これはソースコードの監査に代わるものではありませんが、システム全体に渡って個人データを盗み出そうとする不正なソフトウェアに対する追加の防御層を提供し、このような攻撃を阻止するのに非常に効果的です（ただし攻撃に過度に寛大な権限を使用するバイナリを与える）。