カテゴリー

Uncategorized

サプライチェーンの侵害につながる可能性のある暗黙的に信頼されたインフラストラクチャの3つの領域

  1. HOME >
  2. Uncategorized >

サプライチェーンの侵害につながる可能性のある暗黙的に信頼されたインフラストラクチャの3つの領域

SolarWindsは2020年12月に妥協し、その後のビルドサービスの調査により、サプライチェーン攻撃にスポットライトが当てられました。これにより、組織が次のSolarWindsにならないように、サプライチェーンのセキュリティ体制を再評価するという新たな関心が生まれました。しかし、SolarWindsは、最近の多くのサプライチェーン攻撃の1つにすぎません。

サプライチェーンの妥協

組織が直面していることをより広く理解するために、2021年の第1四半期に発生した3つの主要なサプライチェーンの侵害を見てみましょう。これらのサプライチェーン攻撃はそれぞれ、暗黙的に信頼されているインフラストラクチャの異なる部分を標的にしました。組織の潜在的なターゲットとして注意を払っていない。

1.ソフトウェアパッケージリポジトリを介したパッケージスクワット

2021年2月、研究者のAlex Birsanは、開発者がソフトウェアパッケージリポジトリに対して持っている暗黙の信頼を悪用しました。プライベートパッケージの名前を含むパブリックソフトウェアリポジトリを調べることで、Birsanは、AppleやMicrosoftなどの企業がプライベートリポジトリでホストされている特定のチームの内部パッケージを持っていることを確認できました。同じ名前でバージョン番号の高いパッケージを公開リポジトリにアップロードすることで(「パッケージスクワット」と呼ばれる攻撃)、Birsanはこれらの企業内でコードを実行することができました。

ソフトウェア開発は、その性質上、外部パッケージを使用する必要があります。システムレベルでは、これはMicrosoft WindowsCreateProcessAなどのAPIとして表示されます。

システムプログラミングからスクリプト言語(NodeJS、Python、Rubyなど)への抽象化をさらに進めると、それぞれのパッケージリポジトリ(NPMPyPI、およびRubyGems)。

ほとんどの開発者は、これらのソースからのパッケージを本質的に信頼し、自動ビルドプロセスやソフトウェア開発時にそれらを使用します。これは、攻撃者が悪意のあるコードの配信メカニズムとしてわずかに誤った名前のパッケージを使用する機会を提供します。

パッケージ署名でパッケージのしゃがみを防ぐ

適切な人から適切なパッケージを確実に受け取るための最良の方法は、暗号で署名されたパッケージであり、パッケージメンテナの公開鍵によって検証されます。

残念ながら、ほとんどの主要な言語リポジトリは、そのようなものを何も実装していません。リポジトリレベルの署名(リポジトリ自体がパッケージに署名する)を持っているものはごくわずかであり、作成者レベルの署名(作成者が署名を行う)を提供しているものもあれば、基本的なチェックサム(コードがはハッシュアルゴリズムを介して実行され、ダウンロードはハッシュによって正確に検証されます)。

パッケージに署名しない場合、これらのパッケージの問題を攻撃する次善の方法は、ローカル環境です。内部パッケージミラーを操作してコードを検証し、ソフトウェア開発サイクルで使用されるパッケージのバージョンを固定することができます。これにより、間違った名前のパッケージがローカルミラーに存在しないため、タイプミスの可能性がなくなり、Birsanによって発見された新しいバージョンが自動的にプルされるバージョンの問題がなくなります。

残念ながら、パッケージが適切なソースからのものであることを確認するという問題は依然としてありますが、少なくともこれにより、攻撃者にとって手に負えない成果が排除されます。うまくいけば、将来的には、より多くの言語のパッケージマネージャーに作成者レベルの署名が含まれるようになり、パッケージビルドを検証できるようになります。

2.バージョン管理システムを介した悪意のあるコミット

2021年3月、PHPプロジェクトへの2人の認められた貢献者であるNikitaPopovとRasmusLerdofから来たと偽って、2つの悪意のあるコミットがPHPgitリポジトリにプッシュされました。両方の開発者は、SSHクレデンシャルが危険にさらされていないことを確認しました。
他の唯一の答えは、PHPプロジェクトによって実行されている自己ホスト型gitサーバーが侵害されたこと、および攻撃者が既知のメンバーになりすまして悪意のあるコードをコードベースに挿入したことである可能性があります。その後、攻撃者がサーバーのデータベースをダンプし、HTTPSベースのgitアクセス用のユーザー名とパスワードを取得した可能性が高いことが判明しました。

バージョン管理システムは、最新のソフトウェア開発のもう1つの重要な部分です。つまり、すべてのコードとそのコードへの変更がチェックインされて保存される場所です。最も一般的なのはGitですが、mercurialsvnなどの他のものもあります。これらは現在、継続的インテグレーションパイプラインで自動ビルドシステムと結合されており、場合によっては自動展開にも組み込まれています。

SolarWindsの場合、攻撃者が悪意のあるDLLをコードベースに挿入できるように、Orionビルドパイプラインが攻撃者の標的になりました。自動化されたパイプラインは、作成された後、たまにしか変更されないため、攻撃者がソフトウェア開発ライフサイクルに自分自身を注入するための優れた場所を提供します。

さらに、バージョン管理システムは、悪意のあるコードをチェックインする必要がある場所であるため、企業のソフトウェアパイプラインを危険にさらし、その企業のユーザーの暗黙の信頼を利用しようとしている攻撃者にとって不可欠な依存関係です。

署名されたコミットで悪意のあるコミットを停止する

ソフトウェアリポジトリがホストされているサーバーが侵害されると、リポジトリのユーザーが署名されたgit commitを使用ていない場合、攻撃者はそのマシン上のリポジトリでほぼすべてのことを実行できます。

コミットの署名は、パッケージリポジトリからの作成者が署名したパッケージの場合とほとんど同じように機能しますが、その認証を個々のコード変更レベルにもたらします。これを効果的に行うには、リポジトリのすべてのユーザーがコミットに署名する必要がありますが、これはユーザーの観点からは重要です。PGPは最も直感的なツールではなく、実装するにはユーザートレーニングが必要になる可能性がありますが、セキュリティにとって必要なトレードオフです。

署名されたコミットは、コミットが元の開発者からのものであることを確認する唯一の方法です。悪意のあるコミッターが開発者になりすますのを防ぎたい場合、そのような実装のユーザートレーニングと不便は必要な不便です。これにより、PHPプロジェクトのリポジトリのHTTPSベースのコミットがすぐに疑わしくなります。

監査とコードレビューを定期的に実行する

ただし、署名されたコミットはすべての問題を軽減するわけではありません。リポジトリが存在する侵害されたサーバーでは、攻撃者がコミットプロセス中に複数の場所に自分自身を挿入できる可能性があるためです。Gitには、受信前および受信後のコミットを使用してコードコミットのあらゆる種類の変更を可能にするサーバー側フックの概念があります

SolarWinds Orionサーバーのように、サーバーに自動ビルドプロセスがある場合、これは攻撃者が変更を実装するのに最適な場所でもあります。ビルドサーバーがチェックインされたコードを受け取り、テストを実行し、リリースアーティファクトを自動的にビルドすると、悪意のあるコードが挿入される可能性のある多くのエクストラが生成されます。

さらに、バージョン管理システムには、手元のプロジェクトの開発者ツールが保存されていることがよくあります。これは攻撃者によって悪用される可能性があります(今年の1月にセキュリティ研究者を標的にした北朝鮮のグループで見たように)。彼らの攻撃では、Microsoft Visual Studioビルドファイルと、研究者が悪意のあるコードを実行するように仕向けるためにそれらに置いた信頼を使用しました。この種の攻撃は、攻撃者が制御するライブラリをプルダウンする悪意のあるRustカーゴファイルなど、リポジトリに保存されている開発者ツールに簡単に変換される可能性があります。

これを防ぐ最善の方法は、リポジトリ内のすべての変更の監査とコードレビューを実行し、開発者ツールへの変更に関するアラートを設定するか、コードの実行を自動化するインフラストラクチャを構築することです。開発者が変更をチームに伝えていない場合は、それらの変更を精査する時が来ました。

3.TLS証明書を介したman-in-the-middle攻撃

2021年1月、Mimecastは、SolarWindsイベントの一環として、 TLS証明書の1つの秘密鍵が侵害されたとMicrosoftから通知されました。Mimecastによると、この侵害された証明書は、36,000人の顧客の10%が、Microsoft 365Exchangeとの暗号化された接続を確立するために使用していました。

口語的にSSL証明書と呼ばれるTLS証明書は、インターネット上の暗号化のバックボーンを提供します。多くの人が知らないのは、TLSハンドシェイクの一部として認証に使用されることが多いということです。サーバーは、ユーザーが認証に使用できる認証局(CA)に言及することで、クライアントにその信頼性を証明する証明書を提供します。信憑性。

ほとんどのユーザーが毎日シームレスにTLSを使用するブラウザーの場合、これらのCAからの証明書はローカルに保存され、サーバーから証明書が送信されるたびにチェックされます。安全な接続を確立するために、クライアントは証明書を検証した後、サーバーの公開鍵を使用して暗号化された乱数を送信します。この公開鍵は、サーバーのみが秘密鍵を使用して復号化できます。これらの秘密鍵は、接続を保護するために安全である必要があります。そうしないと、クライアントとサーバー間の接続をだれでも盗聴する可能性があります。

TLS証明書の侵害は目新しいものではなく、大きな問題を提起します。おそらく、暗号化サプライチェーンで最大の問題の1つです。CAは単一障害点であり、セキュリティ侵害の履歴があります。残念ながら、DigiNotarの違反や、CACertinomisによるtest [。] comの証明書の不正発行(Mozillaによって信頼が失われることになった)などの大規模な攻撃は、毎年発生しています。

証明書の侵害からの保護

信頼できる認証局を選択し、秘密鍵が自分だけで生成されるようにしてください。TLS 1.3は、すべてのTLSセッションにPerfect ForwardSecrecyを提供します。これは、攻撃者が証明書を侵害した場合でも、その証明書を使用して暗号化された過去のセッションのデータにアクセスできないことを意味します。これは、以前の通信を保護するための主要な機能です。

残念ながら、証明書が侵害された場合に、一度に何年にもわたって中間者攻撃に使用されないようにするために、より頻繁な証明書ローテーション以外で実行できることは他にありません。そのため、2020年に、Apple、Google、Mozillaはすべて、サーバー管理者に証明書のローテーションをより迅速に行わせるために、信頼できる証明書の最大証明書有効期間を1年と発表しました。これと同じ理由で、Let'sEncryptは90日間の証明書の有効期間しか提供しません。

内部プロジェクトと認証に自己署名証明書を実装する場合でも、これらの短い証明書ライフサイクルガイドラインに従う必要があります。証明書ストアと証明書のライフサイクルを管理するためのHashicorpのVaultなどのツールが役立ちます。

結論

サプライチェーンは広大であり、これは潜在的な問題の包括的なリストではありません。組織内での脅威モデリングの演習により、見過ごされがちな脆弱なインフラストラクチャのより堅牢なビューを得ることができます。ビルドまたは製造プロセスで使用されるベンダーやオープンソースソフトウェアとの暗黙の信頼関係を集中的に見てください。信頼がセキュリティに取って代わる多くの領域が見つかる可能性があります。

-Uncategorized