Quick Analysis - CVE-2019-2725 Payload

Since few days now there has been a constant hammering of the weblogic honeypots with the exploits targeting a deserialization vulnerability leading to remote code execution vulnerability identified by CVE-2021-2725. 

The initial request to exploit the vulnerability looks like below,

The payload is a base64 string that gets decoded and saved to "servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/4dde4d88.jsp". Below is the decoded version of the base64 blob.

Following the 1st request a 2nd request is sent to the server. It looks like below ,

Reading the ".jsp" file it is clear that this blob in the 2nd request is base64 encoded and encrypted using AES. The key for decryption is hardcoded in the jsp file. They key can be identified as "fc5e038d38a57032". Using the key the blob in the 2nd request can be decrypted. It turns out the 2nd blob is a class file. The key is also saved in the session using "session.putvalue" into the variable "u". Below is the decrypted version using cyberchef.

Decompiling the class to source we can get an understanding of what's happening in the background. The class gets information about filepath, os, architecture, path, drivelist (line 70-80) encrypts using the same key (line 93 or 109 or 125) and posts it as a response.

How to Debug Weblogic Server using Intellij - A Primer

In recent times there were multiple reports of Weblogic vulnerabilities and debugging becomes an important task if you are to understand the vulnerability/exploit. This blog post discusses how to setup Intellij for debugging Weblogic vulnerabilities.

To debug Weblogic vulnerabilities the first step would be download and install Intellij. Installing the Ultimate edition of Intellij is important because the Community edition doesn't have the facility to debug Weblogic application. The other requirement would be to download and install the Oracle Weblogic application.

Check out the video demonstrating the process of setting up Intellij for Weblogic server vulnerability debugging.

 

A nice stack layout of the exploit arrived at "ProcessBuilder" class.

:144, ProcessBuilder (java.lang)
newInstance0:-1, NativeConstructorAccessorImpl (sun.reflect)
newInstance:39, NativeConstructorAccessorImpl (sun.reflect)
newInstance:27, DelegatingConstructorAccessorImpl (sun.reflect)
newInstance:513, Constructor (java.lang.reflect)
invokeInternal:242, Statement (java.beans)
access$000:39, Statement (java.beans)
run:140, Statement$2 (java.beans)
doPrivileged:-1, AccessController (java.security)
invoke:137, Statement (java.beans)
getValue:98, Expression (java.beans)
getValue:445, MutableExpression (com.sun.beans)
getValue:108, ObjectHandler (com.sun.beans)
eval:130, ObjectHandler (com.sun.beans)
startElement:238, ObjectHandler (com.sun.beans)
startElement:453, AbstractSAXParser (com.sun.org.apache.xerces.internal.parsers)
emptyElement:179, AbstractXMLDocumentParser (com.sun.org.apache.xerces.internal.parsers)
scanStartElement:1343, XMLDocumentFragmentScannerImpl (com.sun.org.apache.xerces.internal.impl)
next:2756, XMLDocumentFragmentScannerImpl$FragmentContentDriver (com.sun.org.apache.xerces.internal.impl)
next:648, XMLDocumentScannerImpl (com.sun.org.apache.xerces.internal.impl)
scanDocument:511, XMLDocumentFragmentScannerImpl (com.sun.org.apache.xerces.internal.impl)
parse:808, XML11Configuration (com.sun.org.apache.xerces.internal.parsers)
parse:737, XML11Configuration (com.sun.org.apache.xerces.internal.parsers)
parse:119, XMLParser (com.sun.org.apache.xerces.internal.parsers)
parse:1205, AbstractSAXParser (com.sun.org.apache.xerces.internal.parsers)
parse:522, SAXParserImpl$JAXPSAXParser (com.sun.org.apache.xerces.internal.jaxp)
parse:69, WebLogicParser (weblogic.xml.jaxp)
parse:156, RegistryParser (weblogic.xml.jaxp)
parse:364, SAXParser (javax.xml.parsers)
parse:142, SAXParser (javax.xml.parsers)
getHandler:238, XMLDecoder (java.beans)
readObject:201, XMLDecoder (java.beans)
readUTF:111, WorkContextXmlInputAdapter (weblogic.wsee.workarea)
readEntry:92, WorkContextEntryImpl (weblogic.workarea.spi)
receiveRequest:179, WorkContextLocalMap (weblogic.workarea)
receiveRequest:163, WorkContextMapImpl (weblogic.workarea)
handleRequest:27, WorkAreaServerHandler (weblogic.wsee.workarea)
handleRequest:141, HandlerIterator (weblogic.wsee.handler)
dispatch:114, ServerDispatcher (weblogic.wsee.ws.dispatch.server)
invoke:80, WsSkel (weblogic.wsee.ws)
handlePost:66, SoapProcessor (weblogic.wsee.server.servlet)
process:44, SoapProcessor (weblogic.wsee.server.servlet)
run:285, BaseWSServlet$AuthorizedInvoke (weblogic.wsee.server.servlet)
service:169, BaseWSServlet (weblogic.wsee.server.servlet)
service:820, HttpServlet (javax.servlet.http)
run:227, StubSecurityHelper$ServletServiceAction (weblogic.servlet.internal)
invokeServlet:125, StubSecurityHelper (weblogic.servlet.internal)
execute:301, ServletStubImpl (weblogic.servlet.internal)
execute:184, ServletStubImpl (weblogic.servlet.internal)
wrapRun:3732, WebAppServletContext$ServletInvocationAction (weblogic.servlet.internal)
run:3696, WebAppServletContext$ServletInvocationAction (weblogic.servlet.internal)
doAs:321, AuthenticatedSubject (weblogic.security.acl.internal)
runAs:120, SecurityManager (weblogic.security.service)
securedExecute:2273, WebAppServletContext (weblogic.servlet.internal)
execute:2179, WebAppServletContext (weblogic.servlet.internal)
run:1490, ServletRequestImpl (weblogic.servlet.internal)
execute:256, ExecuteThread (weblogic.work)
run:221, ExecuteThread (weblogic.work)

The exploit is based on - https://www.exploit-db.com/exploits/46780.