OpenSSL は、コンピュータ ネットワーク上で安全な通信を実装するために広く使用されているオープンソース ソフトウェア ライブラリです。どのくらい広く使われていますか?そうですね、HTTPS Web ページにアクセスしたことがある場合は、OpenSSL 暗号化を介してアクセスした可能性があります。このライブラリは、データの暗号化、復号化、認証、デジタル署名検証のための暗号化機能とプロトコルを提供します。 OpenSSL は、Web サーバー、電子メール サーバー、仮想プライベート ネットワーク (VPN)、およびその他の種類のネットワーク通信を保護する必要があるほとんどの場所で使用できます。
上の段落を見ると、インターネットの適切な動作にとって OpenSSL がいかに重要であるかが明らかになるはずです。これは、多くのコンピュータ システムやアプリケーションにとってセキュリティ インフラストラクチャの重要なコンポーネントです。機密データを不正アクセスから保護し、ネットワーク通信の整合性と信頼性を確保するのに役立ちます。そのため、ライブラリの管理者は脆弱性を非常に深刻に受け止め、できるだけ早くパッチを適用しようとします。攻撃者が World Wide Web インフラストラクチャの安全な通信回線にアクセスすることを想像することはほとんど考えられません。
この記事では、3.0.7 年 2022 月の OpenSSL パッチ XNUMX の原因となった脆弱性を検証し、OpenSSL メンテナがこの問題に対処した方法から何が学べるかを見ていきます。
脆弱性
25 年 2022 月 XNUMX 日、OpenSSL プロジェクトは、 アドバイザリー いくつかの問題に対処するための新しいパッチが間もなくリリースされる予定であることを警告します 重大な 脆弱性。 「クリティカル」タグは、脆弱性が悪用される可能性が高く、影響を受けるサーバー上の秘密キーや RCE が盗まれる可能性が高いことを意味します。
1 週間後の 2022 年 3.0.7 月 XNUMX 日、OpenSSL プロジェクトは新しいパッチ XNUMX と 特定の脆弱性 彼らは修正することを目指していました。それまでの間に、脆弱性の評価は重大から「高重大度」に引き下げられました。
では、これらの脆弱性とは何でしょうか?
CVE-2022-3602 – X.509 電子メール アドレスの 4 バイト バッファ オーバーフロー – X.509 証明書の検証、特に名前制約チェックでは、XNUMX バイトのバッファ オーバーランが発生する可能性があります。攻撃者が悪意のある電子メール アドレスを使用すると、スタック上の攻撃者が制御する XNUMX バイトがオーバーフローする可能性があります。このバッファ オーバーフローによって、クラッシュ (サービス拒否が発生する) やリモート コード実行が発生する可能性があります。当初、これは重大として分類されていましたが、追加のテストにより、多くのプラットフォームがリモート コード実行のリスクを軽減するためにスタック オーバーフロー保護機能を使用していることが判明しました。
CVE-2022-3786 – X.509 電子メール アドレスの可変長バッファ オーバーフロー – X.509 証明書の検証、特に名前制約チェックでは、バッファ オーバーランが発生する可能性があります。攻撃者は、証明書内に悪意のある電子メール アドレスを作成し、46 進数の XNUMX である文字「.」を含む任意の数のバイトでスタックを埋めることができます。このバッファ オーバーフローの結果、クラッシュが発生する可能性があります (エラーを引き起こす)。サービス拒否）。
これらの脆弱性がどれほど深刻であるかを繰り返しておきます米国サイバーセキュリティおよびインフラストラクチャセキュリティ庁である CISA は、 アドバイザリー OpenSSL と同日、encouraユーザーと管理者にレビューを依頼する OpenSSL のドキュメントを参照し、該当する場合は新しいパッチ 3.0.7 にアップグレードします。
前に説明したように、OpenSSL を実行しているオペレーティング システムまたはメール サーバーでの RCE (リモート コード実行) は非常に悪質であるため、 適切なパッチが見つかって提供されると、脆弱性が発見されます。
次は何が起こる
最初の勧告が発表されるとすぐに、人々は慌て始めました。 「パニックにならないでください」が常套句だった 当時の OpenSSL が重大な問題を抱えているというニュースを人々がどれほど真剣に受け止めているかを示しています 脆弱性
この勧告が公開されるとすぐに、関連するすべての関係者は、サーバー、OS、アプリケーション、パッケージなどでどのバージョンの OpenSSL が使用されているかを把握しようと躍起になりました。社内での OpenSSL の使用だけでなく、3 番目のバージョンの OpenSSL が使用されているかどうかも把握する必要がありました。パーティ ベンダーまたはサービス プロバイダーは、脆弱な OpenSSL バージョンを使用していました。当時、使用しているバージョンがわからない場合、またはベンダーやサービス プロバイダーが使用しているバージョンがわからない場合は、潜在的な RCE のリスクを冒すよりも、アプリケーションをオフラインにする方が安全であると考えられていました。
アドバイザリではパッチのスケジュールが事前に示されていたため、人々は自分自身のインフラストラクチャとベンダーやサービスプロバイダーのインフラストラクチャを理解する時間が与えられました。アイデアは、パッチがリリースされ次第、必要に応じてアップグレードを実行できるように、関連するインフラストラクチャに関して必要なすべてを計画することでした。
どのように対処しますか?
ここで、あなたが、知っている限りサーバーで OpenSSL を使用している会社のエンジニアであるとします。アドバイザリが発表されたらすぐに、どのバージョンのライブラリがどこで使用されているか (まだ実行されている場合はレガシー コードも含む) を把握し、ベンダーやサービス プロバイダーについても同じことを把握する必要があります。
これは、 SBOM 本当に役立つかもしれません。 SBOM はソフトウェア部品表の略で、特定のソフトウェア製品を構成するすべてのコンポーネントとソフトウェアの依存関係のリストです。 SBOM には通常、すべてのソフトウェア コンポーネントの名前とバージョン (今後の説明を参照)、それらのソースとライセンス、各コンポーネントに関連する既知の脆弱性やセキュリティ問題などの情報が含まれます。
あなたが責任あるエンジニアとして、各製品の最新の SBOM を持っていることを確認していれば、OpenSSL をどこで使用しているか、どのバージョンが使用されているかを見つけるのは、SBOM ファイルで検索を実行するだけの簡単な作業だったでしょう。 。会社が提携しているベンダーまたはサービス プロバイダーに最新の SBOM を確実に要求していれば、そこでも同じ検索を行うことができたはずです。
この脆弱性は 3.0.0 から 3.0.6 までのバージョンにのみ影響すると言われているため、実行しているバージョンを確認するだけで、どのアプリケーションを削除するか、新しいパッチ 3.0.7 で更新する必要があるかを知ることができます。 XNUMX。
OpenSSL を使用する有名なオペレーティング システムとエンタープライズ アプリケーションのリストがどれほど広範囲に及ぶかを確認するには、これをチェックしてください。 リスト 人々がどれほど心配すべきかを理解するために、公共サービスとして公開されました。
証拠に基づいたセキュリティ ハブがどのように役立つか
進化するサイバーセキュリティ環境の一部として、 脆弱性、私たちは現在目撃しています アプリケーションセキュリティからソフトウェアサプライチェーンセキュリティへの進化。これらの問題を解決するために、新世代のツールとテクノロジーが開発されました。ソフトウェア開発ライフサイクルとソフトウェアコンポーネントの信頼性を保証できる、証拠に基づいた継続的なコードセキュリティ保証プラットフォームを提供することで、自動化されたツールとソリューションは、組織が新たなレベルのセキュリティを達成するのを支援します。依存関係と脆弱性を継続的にマッピングすると、パッチが利用可能になったときに修正したりパッチを適用したりすることが簡単になります。
筆記 はソフトウェア サプライ チェーンのセキュリティ ハブです。証拠を収集し、CI/CD パイプラインを通過するすべてのビルドに対してそれを提示します。 Scribe のソリューションの目標は、ソフトウェアの透明性を高め、ソフトウェア開発者とユーザーの間の信頼を育むための EU および米国の規制とベスト プラクティスへの準拠を容易にすることでした。このプラットフォームにより、包括的な SBOM やその他のセキュリティに関する洞察を作成して共有することが可能になります。さらに、プラットフォームは、表示しているビルドが NIST の SSDF フレームワークと SLSA レベル 3 の両方の要件に準拠していることを確認できます。ビルドごとに SBOM を備えた証拠ストアがあるため、どこでどのバージョンのライブラリを使用しているかを手探りする必要はもうありません。今では、テキスト文書内で特定の文を探すのと同じくらい簡単にそれを理解できます。
最後の言葉: 次の大規模な脆弱性の公開に備えてください
パッチ 3.0.7 の OpenSSL プロジェクトのストーリーは、潜在的に重大な脆弱性に対処する方法について、同様に重要な XNUMX つの視点を提供します。
影響を受ける側、つまりこれらの脆弱性によって侵害される可能性のある企業またはプロジェクトから、当社は透明性を確保するよう通知しました。彼らは害を及ぼす可能性のある情報をすぐに開示することはありませんが、問題を認識するとすぐに開示できるものはすべて開示します。それだけでなく、問題に関する可能な限りの情報に加えて、修復のタイムラインも提供します。パッチや修正が存在すると、何が問題で、どのように悪用される可能性があるかを正確に開示することを躊躇しませんでした。この種の透明性は信頼を促進します。ユーザーと顧客は、会社が収益や取締役会と同じくらい、または少なくとも同じくらい自分たちを大切にしていることを知り、感じたいと考えています。
2014 年、OpenSSL プロジェクトは「」と呼ばれる重大なバグの犠牲になりました。心血' – OpenSSL の TLS/DTLS 実装における重大な欠陥により、攻撃者が影響を受けるサーバーから暗号化キー素材、パスワード、その他の機密情報などの機密情報を取得することが可能になりました。 Heartbleed は、OpenSSL の重大な脆弱性がさまざまなプログラムや Linux ディストリビューションに影響を与える可能性があることを示しました。脆弱なシステムをすべて特定して修正しようとすると、セキュリティ チームは何か月にもわたって頭の痛い問題を抱えていました。ソフトウェアの更新とパッチ適用をより迅速かつ簡単に行える SBOM のようなツールを導入すれば、どの企業のサイバーセキュリティ チームにとっても恩恵となるでしょう。
修復する側から見ると、何を扱う必要があるのかを正確に把握することは、そのような潜在的な緊急事態に対処できるようにするために、どのパッケージのどのバージョンをどこで使用しているのかを知ることが不可欠です。 Log4J を例に挙げると、一部の企業は、この脆弱性が発見されてから XNUMX 年以上経った今でも、この脆弱性の影響を受けるかどうかを確認しようとしています。
心配する必要があるのはソフトウェアやサーバーだけではなく、使用しているサードパーティ ベンダーや、API 接続を使用している場合でも連携しているサービス プロバイダーのことも考慮する必要があるということは、私たち全員が私たちは、私たちの間に信頼の網を構築する必要があります。このような信頼は、できる限り確実な証拠に依存する必要があります。独自の SBOM および取引先の会社の SBOM を作成して追跡し、それらの SBOM を共有し、悪用可能な脆弱性を発見した場合は誠意を持って発表し、修正してください。
このような証拠を共有することが、企業の最新の PR をソーシャル メディアで共有するのと同じくらい当たり前の世界に到達するには、私たち全員が協力する必要があります。この信頼がなければ、私たちは皆が懸命に維持するために相互接続されたインフラストラクチャを破壊する次の大きな重大な脆弱性への準備を整えているだけです。
このコンテンツは、エンドツーエンドのソフトウェア サプライ チェーン セキュリティ ソリューションの大手プロバイダーである Scribe Security によって提供されており、ソフトウェア サプライ チェーン全体のコード成果物とコード開発および配信プロセスに最先端のセキュリティを提供しています。 詳しくはこちら。
関連記事
