Springライブラリの新しい脆弱性：危険にさらされているかどうかを知る方法と対処法
先日、Javaコミュニティで最も人気のあるライブラリの1つであるSpringライブラリが、リモートコード実行（RCE）に関する2つの脆弱性を公開しました。どちらの脆弱性にも該当するリスクがあるのか、またどのような対処をすればよいのかを理解しやすくするために、"Spring4Shell" と "Spring Cloud Function" について既知の詳細をまとめました。
脆弱性1 - "Spring4Shell" (CVE-2022-22965)
2022年3月29日、コミュニティは、Spring Core (SC) を標的としたエクスプロイトの概念実証のスクリーンショットを含む一連のツイートを発見し、最新リリース版である 5.3.17 を含む Spring Core のすべてのバージョンでリモートコード実行が可能であることを確認しました。
どのようなアプリケーションがリスクにさらされているのか？
現在、Tomcat上でホストされているアプリケーションのみが、この新しいエクスプロイトの危険にさらされていることが確認されています。この悪用は、Embedded Tomcat Servlet Containerやその他のTomcat以外のアプリケーションに対して成功したとは証明されていませんが、将来的にこれらのフレームワークに対して成功する可能性を排除するものではありません。
Springは、この脆弱性について公式声明を発表し、現時点での理解では、以下の条件を満たすことで脆弱性が発生することを明らかにしました。
- JDK 9 以上
- サーブレットコンテナとしてのApache Tomcat
- 従来のWARとしてパッケージ化（Spring Bootの実行可能なjarとは対照的）。
- spring-webmvc または spring-webflux の依存関係
- Spring Framework バージョン 5.3.0 から 5.3.17, 5.2.0 から 5.2.19, およびそれ以前のバージョン
Spring4Shell」の悪用はどのように行われるのですか？
この悪用は、メソッドの署名にPlain Old Java Objects (POJO) を使用するリクエストで「データバインディング」 (org.springframework.web.bind.WebDataBinder) を使用することに依存します。
ここで、FooクラスはPOJOクラスであり、次のように定義できます。実際のクラスは、クラス・ローダーによってロードされる限り、重要ではないことに注意してください。
このようなメソッドでリクエストが処理される場合、クラス・ローダーがクラスの解決に使用されます。クラスローダーは実行時にクラスをロードする役割を担っており、最初にメモリに可能なすべての型をプリロードする必要がありません。新しいクラスが使用されるときに、どの .jar ファイルをロードすればよいかを判断します。
この脆弱性についての最新かつ詳細な情報は、Springのブログ記事で直接確認することができます。
脆弱性2 - Spring Cloud 機能 (CVE-2022-22963)
2022年3月27日、サイバーケンドラは、Spring Cloud Functionsに存在するパッチが存在しない0日間のリモートコード実行（RCE）の脆弱性に関する詳細を公開しました。この脆弱性には、ID「CVE-2022-22963」が付与されています。Spring Expression Resource Access Vulnerability」です。
どのようなアプリケーションがリスクにさらされているのか？
この脆弱性は、これらの条件下でアプリケーションに影響を及ぼします。
- JDK 9 以降
- Spring Cloud Functionsのバージョン3.1.6以下、3.2.2以下、または未対応のバージョン
搾取の仕組みは？
Spring Cloud Functionは、開発者がspring.cloud.function.routing-expressionプロパティを通じてルーティングの処理方法を設定する機能を提供する。通常は設定やコードを通じて行われる。これは、"Spring Expression Language" (SpEL)を受け入れる強力な機能です。今回の脆弱性により、このプロパティはリクエストのHTTPヘッダを通じて設定できることが判明しました。つまり、攻撃者はRoutingFunctionエンドポイントへのHTTPリクエストに直接SpELコードを埋め込み、任意のコードを実行することが可能です。
リスクを軽減するために、ユーザーはどのような手段を取るべきでしょうか？
Springは、バージョン3.1.7および3.2.3をリリースし、HTTPヘッダによるこのプロパティの設定を許可しないことでこの問題に対処し、脆弱性を軽減しています。いずれのバージョンにもアップグレードした後、追加の手順は必要ありません。
開発者がより安全なコードを書くための支援方法についてもっと知りたいですか？デモをご予約いただくか、セキュアコードコーチで無料のセキュアコーディングガイドラインをご覧ください。
情報源
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
先日、Javaコミュニティで最も人気のあるライブラリの1つであるSpringライブラリが、リモートコード実行（RCE）に関する脆弱性2件を公開しました。Spring4Shell」と「Spring Cloud Function」について、既知の内容を整理し、リスクがあるかどうか、リスクがある場合の対処方法について説明します。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
先日、Javaコミュニティで最も人気のあるライブラリの1つであるSpringライブラリが、リモートコード実行（RCE）に関する2つの脆弱性を公開しました。どちらの脆弱性にも該当するリスクがあるのか、またどのような対処をすればよいのかを理解しやすくするために、"Spring4Shell" と "Spring Cloud Function" について既知の詳細をまとめました。
脆弱性1 - "Spring4Shell" (CVE-2022-22965)
2022年3月29日、コミュニティは、Spring Core (SC) を標的としたエクスプロイトの概念実証のスクリーンショットを含む一連のツイートを発見し、最新リリース版である 5.3.17 を含む Spring Core のすべてのバージョンでリモートコード実行が可能であることを確認しました。
どのようなアプリケーションがリスクにさらされているのか？
現在、Tomcat上でホストされているアプリケーションのみが、この新しいエクスプロイトの危険にさらされていることが確認されています。この悪用は、Embedded Tomcat Servlet Containerやその他のTomcat以外のアプリケーションに対して成功したとは証明されていませんが、将来的にこれらのフレームワークに対して成功する可能性を排除するものではありません。
Springは、この脆弱性について公式声明を発表し、現時点での理解では、以下の条件を満たすことで脆弱性が発生することを明らかにしました。
- JDK 9 以上
- サーブレットコンテナとしてのApache Tomcat
- 従来のWARとしてパッケージ化（Spring Bootの実行可能なjarとは対照的）。
- spring-webmvc または spring-webflux の依存関係
- Spring Framework バージョン 5.3.0 から 5.3.17, 5.2.0 から 5.2.19, およびそれ以前のバージョン
Spring4Shell」の悪用はどのように行われるのですか？
この悪用は、メソッドの署名にPlain Old Java Objects (POJO) を使用するリクエストで「データバインディング」 (org.springframework.web.bind.WebDataBinder) を使用することに依存します。
ここで、FooクラスはPOJOクラスであり、次のように定義できます。実際のクラスは、クラス・ローダーによってロードされる限り、重要ではないことに注意してください。
このようなメソッドでリクエストが処理される場合、クラス・ローダーがクラスの解決に使用されます。クラスローダーは実行時にクラスをロードする役割を担っており、最初にメモリに可能なすべての型をプリロードする必要がありません。新しいクラスが使用されるときに、どの .jar ファイルをロードすればよいかを判断します。
この脆弱性についての最新かつ詳細な情報は、Springのブログ記事で直接確認することができます。
脆弱性2 - Spring Cloud 機能 (CVE-2022-22963)
2022年3月27日、サイバーケンドラは、Spring Cloud Functionsに存在するパッチが存在しない0日間のリモートコード実行（RCE）の脆弱性に関する詳細を公開しました。この脆弱性には、ID「CVE-2022-22963」が付与されています。Spring Expression Resource Access Vulnerability」です。
どのようなアプリケーションがリスクにさらされているのか？
この脆弱性は、これらの条件下でアプリケーションに影響を及ぼします。
- JDK 9 以降
- Spring Cloud Functionsのバージョン3.1.6以下、3.2.2以下、または未対応のバージョン
搾取の仕組みは？
Spring Cloud Functionは、開発者がspring.cloud.function.routing-expressionプロパティを通じてルーティングの処理方法を設定する機能を提供する。通常は設定やコードを通じて行われる。これは、"Spring Expression Language" (SpEL)を受け入れる強力な機能です。今回の脆弱性により、このプロパティはリクエストのHTTPヘッダを通じて設定できることが判明しました。つまり、攻撃者はRoutingFunctionエンドポイントへのHTTPリクエストに直接SpELコードを埋め込み、任意のコードを実行することが可能です。
リスクを軽減するために、ユーザーはどのような手段を取るべきでしょうか？
Springは、バージョン3.1.7および3.2.3をリリースし、HTTPヘッダによるこのプロパティの設定を許可しないことでこの問題に対処し、脆弱性を軽減しています。いずれのバージョンにもアップグレードした後、追加の手順は必要ありません。
開発者がより安全なコードを書くための支援方法についてもっと知りたいですか？デモをご予約いただくか、セキュアコードコーチで無料のセキュアコーディングガイドラインをご覧ください。
情報源
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
先日、Javaコミュニティで最も人気のあるライブラリの1つであるSpringライブラリが、リモートコード実行（RCE）に関する2つの脆弱性を公開しました。どちらの脆弱性にも該当するリスクがあるのか、またどのような対処をすればよいのかを理解しやすくするために、"Spring4Shell" と "Spring Cloud Function" について既知の詳細をまとめました。
脆弱性1 - "Spring4Shell" (CVE-2022-22965)
2022年3月29日、コミュニティは、Spring Core (SC) を標的としたエクスプロイトの概念実証のスクリーンショットを含む一連のツイートを発見し、最新リリース版である 5.3.17 を含む Spring Core のすべてのバージョンでリモートコード実行が可能であることを確認しました。
どのようなアプリケーションがリスクにさらされているのか？
現在、Tomcat上でホストされているアプリケーションのみが、この新しいエクスプロイトの危険にさらされていることが確認されています。この悪用は、Embedded Tomcat Servlet Containerやその他のTomcat以外のアプリケーションに対して成功したとは証明されていませんが、将来的にこれらのフレームワークに対して成功する可能性を排除するものではありません。
Springは、この脆弱性について公式声明を発表し、現時点での理解では、以下の条件を満たすことで脆弱性が発生することを明らかにしました。
- JDK 9 以上
- サーブレットコンテナとしてのApache Tomcat
- 従来のWARとしてパッケージ化（Spring Bootの実行可能なjarとは対照的）。
- spring-webmvc または spring-webflux の依存関係
- Spring Framework バージョン 5.3.0 から 5.3.17, 5.2.0 から 5.2.19, およびそれ以前のバージョン
Spring4Shell」の悪用はどのように行われるのですか？
この悪用は、メソッドの署名にPlain Old Java Objects (POJO) を使用するリクエストで「データバインディング」 (org.springframework.web.bind.WebDataBinder) を使用することに依存します。
ここで、FooクラスはPOJOクラスであり、次のように定義できます。実際のクラスは、クラス・ローダーによってロードされる限り、重要ではないことに注意してください。
このようなメソッドでリクエストが処理される場合、クラス・ローダーがクラスの解決に使用されます。クラスローダーは実行時にクラスをロードする役割を担っており、最初にメモリに可能なすべての型をプリロードする必要がありません。新しいクラスが使用されるときに、どの .jar ファイルをロードすればよいかを判断します。
この脆弱性についての最新かつ詳細な情報は、Springのブログ記事で直接確認することができます。
脆弱性2 - Spring Cloud 機能 (CVE-2022-22963)
2022年3月27日、サイバーケンドラは、Spring Cloud Functionsに存在するパッチが存在しない0日間のリモートコード実行（RCE）の脆弱性に関する詳細を公開しました。この脆弱性には、ID「CVE-2022-22963」が付与されています。Spring Expression Resource Access Vulnerability」です。
どのようなアプリケーションがリスクにさらされているのか？
この脆弱性は、これらの条件下でアプリケーションに影響を及ぼします。
- JDK 9 以降
- Spring Cloud Functionsのバージョン3.1.6以下、3.2.2以下、または未対応のバージョン
搾取の仕組みは？
Spring Cloud Functionは、開発者がspring.cloud.function.routing-expressionプロパティを通じてルーティングの処理方法を設定する機能を提供する。通常は設定やコードを通じて行われる。これは、"Spring Expression Language" (SpEL)を受け入れる強力な機能です。今回の脆弱性により、このプロパティはリクエストのHTTPヘッダを通じて設定できることが判明しました。つまり、攻撃者はRoutingFunctionエンドポイントへのHTTPリクエストに直接SpELコードを埋め込み、任意のコードを実行することが可能です。
リスクを軽減するために、ユーザーはどのような手段を取るべきでしょうか？
Springは、バージョン3.1.7および3.2.3をリリースし、HTTPヘッダによるこのプロパティの設定を許可しないことでこの問題に対処し、脆弱性を軽減しています。いずれのバージョンにもアップグレードした後、追加の手順は必要ありません。
開発者がより安全なコードを書くための支援方法についてもっと知りたいですか？デモをご予約いただくか、セキュアコードコーチで無料のセキュアコーディングガイドラインをご覧ください。
情報源
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
先日、Javaコミュニティで最も人気のあるライブラリの1つであるSpringライブラリが、リモートコード実行（RCE）に関する2つの脆弱性を公開しました。どちらの脆弱性にも該当するリスクがあるのか、またどのような対処をすればよいのかを理解しやすくするために、"Spring4Shell" と "Spring Cloud Function" について既知の詳細をまとめました。
脆弱性1 - "Spring4Shell" (CVE-2022-22965)
2022年3月29日、コミュニティは、Spring Core (SC) を標的としたエクスプロイトの概念実証のスクリーンショットを含む一連のツイートを発見し、最新リリース版である 5.3.17 を含む Spring Core のすべてのバージョンでリモートコード実行が可能であることを確認しました。
どのようなアプリケーションがリスクにさらされているのか？
現在、Tomcat上でホストされているアプリケーションのみが、この新しいエクスプロイトの危険にさらされていることが確認されています。この悪用は、Embedded Tomcat Servlet Containerやその他のTomcat以外のアプリケーションに対して成功したとは証明されていませんが、将来的にこれらのフレームワークに対して成功する可能性を排除するものではありません。
Springは、この脆弱性について公式声明を発表し、現時点での理解では、以下の条件を満たすことで脆弱性が発生することを明らかにしました。
- JDK 9 以上
- サーブレットコンテナとしてのApache Tomcat
- 従来のWARとしてパッケージ化（Spring Bootの実行可能なjarとは対照的）。
- spring-webmvc または spring-webflux の依存関係
- Spring Framework バージョン 5.3.0 から 5.3.17, 5.2.0 から 5.2.19, およびそれ以前のバージョン
Spring4Shell」の悪用はどのように行われるのですか？
この悪用は、メソッドの署名にPlain Old Java Objects (POJO) を使用するリクエストで「データバインディング」 (org.springframework.web.bind.WebDataBinder) を使用することに依存します。
ここで、FooクラスはPOJOクラスであり、次のように定義できます。実際のクラスは、クラス・ローダーによってロードされる限り、重要ではないことに注意してください。
このようなメソッドでリクエストが処理される場合、クラス・ローダーがクラスの解決に使用されます。クラスローダーは実行時にクラスをロードする役割を担っており、最初にメモリに可能なすべての型をプリロードする必要がありません。新しいクラスが使用されるときに、どの .jar ファイルをロードすればよいかを判断します。
この脆弱性についての最新かつ詳細な情報は、Springのブログ記事で直接確認することができます。
脆弱性2 - Spring Cloud 機能 (CVE-2022-22963)
2022年3月27日、サイバーケンドラは、Spring Cloud Functionsに存在するパッチが存在しない0日間のリモートコード実行（RCE）の脆弱性に関する詳細を公開しました。この脆弱性には、ID「CVE-2022-22963」が付与されています。Spring Expression Resource Access Vulnerability」です。
どのようなアプリケーションがリスクにさらされているのか？
この脆弱性は、これらの条件下でアプリケーションに影響を及ぼします。
- JDK 9 以降
- Spring Cloud Functionsのバージョン3.1.6以下、3.2.2以下、または未対応のバージョン
搾取の仕組みは？
Spring Cloud Functionは、開発者がspring.cloud.function.routing-expressionプロパティを通じてルーティングの処理方法を設定する機能を提供する。通常は設定やコードを通じて行われる。これは、"Spring Expression Language" (SpEL)を受け入れる強力な機能です。今回の脆弱性により、このプロパティはリクエストのHTTPヘッダを通じて設定できることが判明しました。つまり、攻撃者はRoutingFunctionエンドポイントへのHTTPリクエストに直接SpELコードを埋め込み、任意のコードを実行することが可能です。
リスクを軽減するために、ユーザーはどのような手段を取るべきでしょうか？
Springは、バージョン3.1.7および3.2.3をリリースし、HTTPヘッダによるこのプロパティの設定を許可しないことでこの問題に対処し、脆弱性を軽減しています。いずれのバージョンにもアップグレードした後、追加の手順は必要ありません。
開発者がより安全なコードを書くための支援方法についてもっと知りたいですか？デモをご予約いただくか、セキュアコードコーチで無料のセキュアコーディングガイドラインをご覧ください。
情報源
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
始めるためのリソース
セキュア・バイ・デザインベストプラクティスの定義、開発者の能力向上、予防的セキュリティ成果のベンチマーク
このリサーチペーパーでは、Secure Code Warrior 共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士、そして専門家であるクリス・イングリス（Chris Inglis）氏（元米国サイバーディレクター、現パラディン・キャピタル・グループ戦略顧問）、デヴィン・リンチ（Devin Lynch）氏（パラディン・グローバル・インスティテュート・シニアディレクター）が、CISO、アプリケーション・セキュリティ担当副社長、ソフトウェア・セキュリティの専門家など、企業のセキュリティ・リーダー20人以上への詳細なインタビューから得られた主な知見を明らかにします。
セキュリティ スキルのベンチマーク: 企業におけるセキュアな設計の合理化
セキュアバイデザイン（SBD）構想の成功に関する有意義なデータを見つけることは、非常に困難である。CISO は、セキュリティプログラム活動の投資収益率（ROI）とビジネス価値を、従業員レベルと企業レベルの両方で証明しようとすると、しばしば困難に直面します。言うまでもなく、企業にとって、現在の業界標準に対して自社の組織がどのようにベンチマークされているかを把握することは特に困難です。大統領の国家サイバーセキュリティ戦略は、関係者に「デザインによるセキュリティとレジリエンスを受け入れる」ことを求めている。セキュアバイデザインの取り組みを成功させる鍵は、開発者にセキュアなコードを保証するスキルを与えるだけでなく、規制当局にそれらのスキルが整っていることを保証することである。本プレゼンテーションでは、25万人以上の開発者から収集した社内データ、データに基づく顧客の洞察、公的研究など、複数の一次ソースから得られた無数の定性的・定量的データを紹介します。こうしたデータ・ポイントの集積を活用することで、複数の業種におけるセキュア・バイ・デザイン・イニシアチブの現状をお伝えすることを目的としています。本レポートでは、この領域が現在十分に活用されていない理由、スキルアッププログラムの成功がサイバーセキュリティのリスク軽減に与える大きな影響、コードベースから脆弱性のカテゴリーを排除できる可能性について詳述しています。
始めるためのリソース
明らかになった：サイバー業界はセキュア・バイ・デザインをどのように定義しているか
最新のホワイトペーパーでは、当社の共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士が、CISO、AppSecリーダー、セキュリティ専門家を含む20人以上の企業セキュリティリーダーと対談し、このパズルの重要なピースを見つけ出し、Secure by Design運動の背後にある現実を明らかにしました。セキュア・バイ・デザインは、セキュリティ・チーム全体で共有された野心ですが、共有されたプレイブックはありません。
