レジストリの設定ミスで2億5,000万件のアーティファクトが露出 #aqua #セキュリティ #ソフトウェアサプライチェーン #SSCS
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
レジストリの設定ミスで2億5,000万件のアーティファクトが露出
もし、あなたが今、自分の環境で、非常に機密性の高い独自のコードやシークレット情報を含む何億ものソフトウェアアーティファクトがが含まれる公開レジストリに誤った設定をしていると言われたらどうしますか。これは、セキュリティにとって本当に悪い日と呼べるものでしょう。最近、Aqua Nautilus の研究チームは、Fortune 500 企業を含む世界最大の組織のいくつかで、まさにそのような状況を発見しました。
これらの事例の一部では、匿名ユーザによるアクセスによって、潜在的な攻撃者がシークレット情報、キーファイル、パスワードなどの機密情報を得ることができ、深刻なソフトウェアサプライチェーン攻撃やソフトウェア開発ライフサイクル (SDLC) の汚染につながる恐れがありました。合計で、2億5,000万 以上のアーティファクトと 6万5,000 以上のコンテナイメージを含む何千もの露出したレジストリおよびアーティファクトリポジトリを検出しました。
IBM、Cisco、Siemens、Alibaba といった企業のセキュリティチームと協力した経験は、素晴らしいものでした。セキュリティチームは、私たちの発見から学び、直ちに是正措置を講じ、長期的な解決策を模索することに意欲的でした。しかし、一部の大企業が私たちの警告を無視し、事業と顧客の双方を重大なリスクにさらしていたことには驚かされました。
クラウドにおけるソフトウェア開発ライフサイクル
SDLC は、企業がクラウド上でソフトウェアを効率的に作成・展開するためのベストプラクティス、プロセス、ツールの集合体です。ソフトウェアの構築、テスト、デプロイのプロセスを自動化することで、エラーやバグのリスクを低減することを目的としています。SDLC には通常、コードを書いてバージョン管理システムにコミットすること、継続的インテグレーション (CI) ツールを使ってコードの構築とテストを自動化すること、テストと検証のためにステージング環境にコードをデプロイすることが含まれます。これらのステップが正常に完了すると、コードは本番環境にデプロイされるか、将来の使用のためにコンテナイメージやアーティファクトレジストリに保存されることになります。
レジストリ、リポジトリ、アーティファクト管理システム
レジストリ、リポジトリ、アーティファクト管理システムなど、パッケージ管理に用いられる開発・運用ソフトウェアの種類はさまざまです。
- レジストリは、パッケージを保管・管理するための中心的な場所です。
- リポジトリとは、レジストリ内のパッケージのコレクションです。
- アーティファクト管理システムは、JAR ファイルなどのバイナリファイルを管理するツールです。
主な違いは、レジストリはパッケージを保存・管理する場所の総称、リポジトリはレジストリ内の特定のコレクション、アーティファクト管理システムはバイナリファイルを管理するレジストリの一種です。
研究対象スコープ
クラウドは広大な攻撃対象領域を持ち、攻撃者がクラウド環境にアクセスするために使用できる多数の潜在的な侵入口があります。私たちの研究は、ソフトウェアサプライチェーン攻撃、特に攻撃者がレジストリをどのように悪用するかに焦点を当てました。私たちは、レジストリはクラウドにおけるソフトウェアサプライチェーンの重要な部分であるにも関わらず、組織がレジストリに十分な注意を払っていないと考えています。もし攻撃者がレジストリにアクセスすれば、SDLC 全体を悪用する可能性があり、伝播する可能性があります。
多くの場合、アーティファクト管理システムとコンテナレジストリは意図的にインターネットに接続されており、設計上、匿名のユーザがレジストリ内のさまざまな領域、あるいはレジストリ全体に接続できるようになっています。この設計により、グローバルチームや顧客、その他の関係者が、社内や外部のユーザと共有するオープンソースソフトウェアにアクセスすることができます。しかし、制限された環境が誤って匿名ユーザと共有されるケースや、チームが誤って機密情報を公開するケースもあります。
このブログでは、レジストリの設定ミスがもたらす潜在的な危険性と、特定のシナリオにおいて非常に危険であることに焦点を当てています。レジストリを誤ってインターネットに接続する、公開されているレジストリにシークレット情報を公開する、デフォルトのパスワードを使用する、ユーザに高い権限を与える、などの誤った設定について説明します。
また、匿名アクセスについても検討します。プライベートコンテナイメージレジストリにおける匿名アクセスは、あるツールでは設定ミスとみなされますが、他のツールでは組織にとってクラウド SLDC を容易にすることを目的とした組み込み機能とみなします。
私たちは、一部の組織がこれらの非常に重要な環境を適切に保護することができず、インターネットにさらされ、悪用されやすく、深刻で有害な攻撃につながる可能性があることを発見しました。
調査結果の概要
私たちの研究は、攻撃者の視点から行われ、攻撃者がどのように最初のアクセスを獲得し、クラウド開発パイプラインをどこまで横移動できるかを検証しました。
調査の結果、複数のコンテナイメージのレジストリと Quay レジストリを発見しました。さらに、インターネット上で一般にアクセス可能な Sonatype Nexus レジストリや JFrog アーティファクトリも発見しました。インターネット上でアクセス可能なレジストリとは、インターネットに接続され、少なくともログインページまでアクセス可能なレジストリです。匿名ユーザアクセスレジストリとは、匿名の読み取り権限または書き込み権限でアクセスできるものです。
以下、主な調査結果を紹介します。
私たちは、Fortune 500 リストの 10社 を含む、世界中の小規模、中規模、および大規模な組織を発見しました。またそのうち、Fortune 500 の 5社 のレジストリが、非常に機密性の高い情報を含んでいるにも関わらず、公開されていたり、匿名でのアクセスを許可していたのは予想外でした。さらに、サイバーセキュリティの大手企業 2社 のレジストリではシークレット情報が露出しており、その他の相当数の中小企業にも同様の問題があり、危険にさらされていることがわかりました。
当社の調査に参加した全企業の年間売上高を合計すると 1.3兆米ドル で、各企業の平均売上高は 100億米ドル、中央値は 3,000万米ドル となっています。
公開された悪用される可能性のあるレジストリのリスク
ここでは、インターネットに接続されたレジストリが公開され、悪用される可能性がある例をいくつか紹介します。
ケース1：国際的なハイテク企業におけるシャドーITのリスク
調査中、Fortune 100の巨大企業のクラウドで働く開発チームとエンジニアリングチームに属する 2つ の誤った設定のコンテナイメージレジストリが発見されました。コンテナイメージのマニフェストの 1つ には、アーティファクトレジストリからアーティファクトをダウンロードするコマンドが含まれており、その中にはイメージ構築の一部として内部バイナリを取得するためのアクティブ API キーが含まれていました。
この巨大企業のセキュリティチームは、非常にプロフェッショナルで、私たちの調査結果を知りたがっていました。彼らは、私たちの報告書の項目を速やかに調査し、リスクを軽減するための対策をすぐに講じました。後でわかったことですが、これはシャドー IT のケースで、サイドプロジェクトの開発者が、適切な管理なしにポリシーや規制に反する環境を立ち上げていたのです。
同社のセキュリティチームは、このケースから学ぶべき多くの教訓を得ました。シャドー IT は、規模の大小にかかわらず、あらゆる組織に脅威を与える深刻な問題です。しかし、いくつかのステップを踏めば、これらの環境へのアクセスを防ぐことができたはずです。まず、レジストリを匿名ユーザに公開すべきではありません。第二に、マニフェストにはハードコードされたシークレット情報が含まれていてはいけません。第三に、API キーは最小特権の原則に基づいた上で、キーローテーションポリシーを適用すべきであり、第四に、ネットワーク制御によってアーティファクトレジストリの API を保護すべきです。
攻撃者は、アーティファクトリポジトリを侵害することで、開発者の感染からクラウドプラットフォーム環境まで、ソフトウェアのサプライチェーン全体をコントロールすることができ、企業のクラウド環境においてさらなる足がかりを得ることができたかもしれません。
ケース2：国際的なハイテク企業における意図的に開かれたアーティファクトレジストリのリスク
調査の結果、別の巨大テック企業で、意図的に公開されたアーティファクトレジストリを保有していることがわかりました。今日の速いペースで進むソフトウェア開発環境では、ビジネスができるだけ円滑に運営できるようにすることが極めて重要です。しかし、このような環境のセキュリティ確保は困難です。何百ものチームと何千人ものプロフェッショナルが公開環境で作業しているため、ミスが起こることは避けられません。
この企業の場合、私たちは、トークンが公開されている終息間近のプロジェクトを発見しました。私たちの情報公開をきっかけに、組織内で議論が始まりました。同社はトークンを公開することを意図していると主張しましたが、私たちは潜在的な攻撃ベクトルについて懸念を共有しました。例えば、Python や NPM パッケージなどのアーティファクトの内部名がインターネットに公開された場合、依存関係の混乱に対する攻撃ベクトルが生まれ、組織に大きな影響を及ぼす可能性がありました。
セキュリティ関係者は、組織の資産に関しては、社内外を問わずすべての個人を十分に監視する必要があるという判断を下しました。多くの専門家がアクセスできる以上、誰かがミスを犯すのは時間の問題です。その結果、この企業はレジストリに対してより厳格な管理を実施し、ユーザ登録と有効期限付きのトークンの発行を義務付けました。これも、セキュリティチームが熱心に学び、コミュニティを啓蒙している一例です。
ケース3：攻撃者の餌食となる医療機関への完全なアクセス
その中には、PGP キー、ウェブサイトへの完全なアクセス、データベースアクセス、ステージング環境、Stripe (決済アプリケーション) キー、およびそのコードなど、組織の環境に対するキーとシークレット情報が多く含まれていました。これらの情報は、攻撃者がコードベースを汚染し、組織の環境に不正にアクセスするために使用された可能性があります。最後に、これは医療機関であったため、国家的な脅威にさらされた人物や、ダークウェブで個人の特定できない情報を販売し、医療機関の顧客の個人情報盗難につながる可能性のある金融の脅威にさらされたかもしれません。残念ながらその医療機関には、この問題を正しく理解できる適切な専門家が見つからなかったのですが、3週間の粘り強い説得の結果、私たちが開示した問題に対して、彼らは直ちに行動を起こしました。
ケース4：環境変数を匿名ユーザに公開する
また、匿名ユーザがアーティファクトレジストリにアクセス可能な、ハイテク・スタートアップも発見しました。その企業では、アーティファクトビルドセクションへのアクセスも許可され、匿名ユーザは環境変数を閲覧することができました。そこから、匿名ユーザは、アーティファクトレジストリの管理者アクセス資格、本番環境の AWS 資格、会社のソースコード管理および CI 環境へのアクセス資格を見ることができたのです。
私たちはこの問題を会社に警告し、CTO は、機密性の高い環境に対するアクティブな AWS 認証情報を持つシャドー IT の事例であると認めました。
すぐにできる対策
あなたの環境にレジストリインスタンスがある場合は、直ちに以下の対応をされることをお勧めします。
- インターネットに公開されているかどうかを確認します。
- レジストリが意図的にインターネットに接続されている場合、バージョンが致命的に脆弱でないか、デフォルトのパスワードが無効になっているかを確認します。さらに、パスワードが十分に強力であることを確認します。
- 匿名ユーザが無効になっていることを確認します。匿名ユーザが意図的に有効になっている場合は、リポジトリ内の公開アーティファクトにシークレット情報が含まれていないことを確認します。
- 公開された可能性のあるシークレット情報はすべてローテーションします。
安心して取り組め、リスクを軽減するための便利なチートシートを用意しました。
ユーザからは、CI/CD 技術スタックが幅広くなると非常に便利であるとの声が聞かれます。定期的に各インスタンスを手動でチェックする代わりに (多くの企業が通常の開発業務に様々な異なるツールやインスタンスを活用していることがわかりました)、ツールがセキュリティ基準を適用し、どんなに広範囲で複雑であっても開発組織全体でそれを検証してくれます。
まとめと緩和策
Aqua Nautilus では、しばしば組織と関わり、現在のクラウドセキュリティの実践について洞察を得ることがあります。このような議論の中で、CISO、セキュリティエンジニア、DevOps エンジニア、アプリケーションセキュリティの専門家など、多くのセキュリティ専門家が、1つの設定ミスがもたらす重大で有害な影響を十分に理解していないことが明らかになりました。環境の堅牢化を謳っているにもかかわらず、多くの人がクラウドの誤設定に関連するリスクに気づかないままです。
私たちは、露出したレジストリや誤設定されたレジストリの背後にいる人物と、熟練した攻撃者がもたらす潜在的な影響をより深く理解することを目標に調査を開始しました。その結果、驚きと懸念の両方が得られました。
また、私たちの調査は、組織がセキュリティ責任開示プログラムを導入することがいかに重要であるかを明らかにしています。このプログラムは、セキュリティ研究者が自社製品に発見した潜在的な脆弱性を構造化された方法で報告できるように設計されています。このプログラムにより、企業は、悪意ある者に悪用される前に、セキュリティ上の問題に迅速に対処し、解決することができます。
私たちの研究では、このプログラムを使って、深刻な設定ミスを開示しました。Nautilus は、既存の責任ある開示プログラムを持つ組織は、1週間以内に誤った設定を修正できることを発見しました。しかし、そのようなプログラムが存在しない組織では、そのプロセスはより困難で時間がかかるものでした。
まとめると、セキュリティ責任開示プログラムは、組織がサイバー攻撃からシステム、データ、評判を守るのに役立つ重要なツールです。組織は、潜在的なセキュリティ問題の報告を容易にするために、専用の電子メールアドレスとウェブサイト上のフォーカルポイントを確立または追加することが重要です。
この調査から得られた主な教訓は、クラウドネイティブ環境のリスクの検出と軽減に、誰もがもっと投資すべきだということです。露出したコンテナレジストリやアーティファクトレジストリに関連するリスクを効果的に低減するためには、次のような対策を講じることが不可欠です。
- VPN やファイアウォールなどのネットワーク制御でリポジトリを保護します。これにより、リポジトリを外部の脅威から保護し、不正アクセスのリスクを低減することができます。
- 強力な認証と認可の手段を導入します。これには、強力なパスワードの使用、二要素認証、SSO、デフォルトパスワードの置き換えが含まれます。
- 鍵、認証情報、およびシークレット情報を定期的にローテーションします。これには、不正アクセスを防止するために、パスワード、アクセスキー、その他の認証・認可の形式を定期的に変更することが含まれます。
- 最小特権アクセス制御とスコープを導入し、特に匿名アクセスの場合、異なる役割に適切なレベルのアクセスを割り当て、必要に応じて特定のリポジトリとアーティファクトへのアクセスを制限します。
- 定期的に機密データをスキャンします。これには、既知の脆弱性やシークレット情報についてアーティファクトとコンテナのレジストリをスキャンし、リポジトリで定期的にセキュリティ評価を実施することが含まれます。攻撃者に悪用されるのを防ぐため、脆弱性には速やかに対処して緩和し、公開されたシークレット情報はローテーションすることが重要です。
これらのベストプラクティスを実施することで、組織はレジストリやアーティファクトリポジトリを公開するリスクを効果的に軽減し、潜在的なセキュリティ脅威から保護することができます。レジストリおよびアーティファクトリポジトリの公開によるリスクを軽減するための推奨事項の全リストは、こちらからダウンロードしてください。
