asoto-r7 (33)

Opinion

This product isn’t used everywhere, but it’s common in large enterprise networks. In some instances, it would be expected to see this product externally accessible, allowing an attacker initial access to the network.

Background

Oracle WebLogic Server (WLS) is a Java EE application server currently developed by Oracle, and it was acquired from BEA Systems in 2008. It is also bundled in other Oracle products such as Oracle Application Testing Suite, which is what the analysis is based on. By default, OATS ships with WebLogic 12.1.3.

The AsyncResponseService component in WebLogic allows a remote user to send a SOAP request that contains a malicious payload in XML format, which ends up being parsed and decoded as Java code, and result in remote code execution.

Our analysis is also based on Metasploit Framework’s pull request #11780.

Vulnerable Setup

The following is the exact setup I used to test and analyze the vulnerability:

• Windows Server 2008 R2 x64 (other Windows systems are also supported)
  
  • .Net Framework 3.5 enabled (from add/remove features)
    
  • IE ESC (from Server Manager) disabled
    
  • 8GB of RAM (at least more than 4GB will be used to run OATS)
    
  • Duel-Core processor
    
• oats-win64-full-13.3.0.1.262.zip (x86 did not work for me)
  
• Jdk-7u21-windows-x64.exe
  
• OracleXE112_Win64.zip (Newer version 18c did not work well for me)
  
• Firefox (I had to install this because IE on Win2k8 is completely outdated)
  
• Adobe Flash installed (IE ESC needs to be disabled in order to install this)
  

For installation instructions, please refer to the Oracle Application Testing Suite Installation Guide.

The Basics of Java Serialization

XMLEncoder

To convert a Java object in XML format, XMLEncoder is meant for that. For example:

import java.io.*;
import java.beans.XMLEncoder;
import java.util.HashMap;

public class SerializationExample {
    public static void serialize(Object obj) throws Exception {
      ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
      XMLEncoder encoder = new XMLEncoder(outputStream);
      encoder.writeObject(obj);
      encoder.close();
      String xml = outputStream.toString();
      System.out.println(xml);
    }

    public static void main(String[] args) throws Exception {
      HashMap map = new HashMap();
      map.put("key1", "Hello World");
      serialize(map);
    }
}

The above will produce the following XML (this is saved as example.xml for decoding):

<?xml version="1.0" encoding="UTF-8"?>
<java version="1.8.0_212" class="java.beans.XMLDecoder">
 <object class="java.util.HashMap">
  <void method="put">
   <string>key1</string>
   <string>Hello World</string>
  </void>
 </object>
</java>

To produce unsafe serialized data, you can use ysoserial. Another example (that executes system command whoami):

$ java -jar ysoserial-0.0.6-SNAPSHOT-all.jar CommonsCollections1 whoami

XMLDecoder

To convert XML back to Java code, XMLDecoder is used:

import java.io.*;
import java.beans.XMLDecoder;
import java.util.HashMap;

public class DeserializationExample {
    public static Object deserialize(String xmlPath) throws Exception {
      BufferedInputStream inputStream = new BufferedInputStream(new FileInputStream(xmlPath));
      XMLDecoder decoder = new XMLDecoder(inputStream);
      Object obj = decoder.readObject();
      decoder.close();
      return obj;
    }

    @SuppressWarnings("unchecked")
    public static void main(String[] args) throws Exception {
      Object obj = deserialize("example.xml");
      HashMap map = (HashMap) obj;
      String value = map.get("key1");
      System.out.println(value);
    }
}

And this is our ouput for deserializing example.xml:

$ java DeserializationExample
Hello World

Vulnerability Analysis

Based on previous experience with Oracle Application Testing Suite, I know that WebLogic is installed as a Windows service named “Oracle ATS Server.” It listens on port 8088, which actually isn’t the same as the original WebLogic port on 7001. Since WebLogic is a Java EE application server, a proper way to debug it is using a Java decompiler (such as JD-GUI) to look at JAR files, and setting up a remote debugging environment for real-time analysis.

Remote Debugging WebLogic

To set up remote debugging for dynamic analysis, the first thing for OATS is making sure the WebLogic service is shut down. You may go to Control Panel –> Services to do that. Next, we want to modify WebLogic’s starting script, also known as startWebLogic.cmd. In this file, we want to add the following line as the first JAVA_OPTIONS:

set JAVA_OPTIONS=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=n

And then we can go ahead and start the script:

C:\OracleATS\oats\bin\startWebLogic.cmd

Note: If you have WebLogic installed (and not OATS), you might have a different directory structure, but the starting script is always named startWebLogic.cmd.

After executing the script, there should be two ports. Port 4000 is the port our debugger can attach to, and port 8088 is the WebLogic Service. At this point, you can use a debugger to connect to port 4000 and start the debugging session. In my case, I am using IntelliJ out of personal preference.

Finding AsyncResponseService Code in OATS

Finding the AsyncResponseService code is a mystery in OATS. There are a lot of JAR files, and what we want is clearly buried somewhere. Without understanding the architecture, realistically speaking we are better off digging some documentation and look for a hint there. Thankfully, Oracle does a pretty good job in documentation, so we found the following WebLogic server client type table in this write-up titled “Oracle Fusion Middleware Developing Stand-alone Clients for Oracle WebLogic Server”:

Notice wseeclient.jar is for WebLogic’s SOAP service, so that’s what we to analyze. Usually I’d be pretty happy about that, except OATS doesn’t have this file (a stand-alone WebLogic server does, though). This just indicates the web service class is probably a dependency of some client when it is built, so we need to find that client.

In a different documentation (Oracle Fusion Middleware Developing JAX-WS Web Services for Oracle WebLogic Server), it mentions a JAR called com.oracle.webservices.wls.jaxws-wlswss-client_12.1.2.jar in a table:

There are other ones, but the one above is more interesting, because it literally says it supports asynchronous request and response. Sounds like a match for AsyncResponseService, right? Well, by decompiling com.oracle.webservices.wls.jaxws-wlswss-client.jar, we found AsyncResponseHandler, which apparently is a valid starting point because it hits our breakpoint in IntelliJ.

The Execution Flow Map

WebLogic is quite a complex application to analyze. Although we hit the AsyncResponseHandler breakpoint, turns out it isn’t the best place because we are kind of in the middle of the code, therefore we should map out the flow a little bit to understand the whole picture. We know that our Java payload is triggering ProcessBuilder, so we can set up a breakpoint there, and understand what happened:

start:1007, ProcessBuilder (java.lang)
invoke0:-1, NativeMethodAccessorImpl (sun.reflect)
invoke:62, NativeMethodAccessorImpl (sun.reflect)
invoke:43, DelegatingMethodAccessorImpl (sun.reflect)
invoke:498, Method (java.lang.reflect)
invoke:71, Trampoline (sun.reflect.misc)
invoke:-1, GeneratedMethodAccessor37 (sun.reflect)
invoke:43, DelegatingMethodAccessorImpl (sun.reflect)
invoke:498, Method (java.lang.reflect)
invoke:275, MethodUtil (sun.reflect.misc)
invokeInternal:292, Statement (java.beans)
access$000:58, Statement (java.beans)
run:185, Statement$2 (java.beans)
doPrivileged:-1, AccessController (java.security)
invoke:182, Statement (java.beans)
getValue:155, Expression (java.beans)
getValueObject:166, ObjectElementHandler (com.sun.beans.decoder)
getValueObject:123, NewElementHandler (com.sun.beans.decoder)
endElement:169, ElementHandler (com.sun.beans.decoder)
endElement:318, DocumentHandler (com.sun.beans.decoder)
endElement:609, AbstractSAXParser (com.sun.org.apache.xerces.internal.parsers)
emptyElement:183, AbstractXMLDocumentParser (com.sun.org.apache.xerces.internal.parsers)
scanStartElement:1339, XMLDocumentFragmentScannerImpl (com.sun.org.apache.xerces.internal.impl)
next:2784, XMLDocumentFragmentScannerImpl$FragmentContentDriver (com.sun.org.apache.xerces.internal.impl)
next:602, XMLDocumentScannerImpl (com.sun.org.apache.xerces.internal.impl)
scanDocument:505, XMLDocumentFragmentScannerImpl (com.sun.org.apache.xerces.internal.impl)
parse:841, XML11Configuration (com.sun.org.apache.xerces.internal.parsers)
parse:770, XML11Configuration (com.sun.org.apache.xerces.internal.parsers)
parse:141, XMLParser (com.sun.org.apache.xerces.internal.parsers)
parse:1213, AbstractSAXParser (com.sun.org.apache.xerces.internal.parsers)
parse:643, SAXParserImpl$JAXPSAXParser (com.sun.org.apache.xerces.internal.jaxp)
parse:133, WebLogicXMLReader (weblogic.xml.jaxp)
parse:173, RegistryXMLReader (weblogic.xml.jaxp)
parse:392, SAXParser (javax.xml.parsers)
run:375, DocumentHandler$1 (com.sun.beans.decoder)
run:372, DocumentHandler$1 (com.sun.beans.decoder)
doPrivileged:-1, AccessController (java.security)
doIntersectionPrivilege:80, ProtectionDomain$JavaSecurityAccessImpl (java.security)
parse:372, DocumentHandler (com.sun.beans.decoder)
run:201, XMLDecoder$1 (java.beans)
run:199, XMLDecoder$1 (java.beans)
doPrivileged:-1, AccessController (java.security)
parsingComplete:199, XMLDecoder (java.beans)
readObject:250, 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:33, WorkAreaServerHandler (weblogic.wsee.workarea)
handleRequest:142, HandlerIterator (weblogic.wsee.handler)
dispatch:115, 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:301, BaseWSServlet$AuthorizedInvoke (weblogic.wsee.server.servlet)
service:177, BaseWSServlet (weblogic.wsee.server.servlet)
service:844, HttpServlet (javax.servlet.http)
run:280, StubSecurityHelper$ServletServiceAction (weblogic.servlet.internal)
run:254, StubSecurityHelper$ServletServiceAction (weblogic.servlet.internal)
invokeServlet:136, StubSecurityHelper (weblogic.servlet.internal)
execute:346, ServletStubImpl (weblogic.servlet.internal)
execute:243, ServletStubImpl (weblogic.servlet.internal)
wrapRun:3432, WebAppServletContext$ServletInvocationAction (weblogic.servlet.internal)
run:3402, WebAppServletContext$ServletInvocationAction (weblogic.servlet.internal)
doAs:321, AuthenticatedSubject (weblogic.security.acl.internal)
runAs:120, SecurityManager (weblogic.security.service)
run:57, WlsSubjectHandle (weblogic.servlet.provider)
doSecuredExecute:2285, WebAppServletContext (weblogic.servlet.internal)
securedExecute:2201, WebAppServletContext (weblogic.servlet.internal)
execute:2179, WebAppServletContext (weblogic.servlet.internal)
run:1572, ServletRequestImpl (weblogic.servlet.internal)
run:255, ContainerSupportProviderImpl$WlsRequestExecutor (weblogic.servlet.provider)
execute:311, ExecuteThread (weblogic.work)
run:263, ExecuteThread (weblogic.work)

By examining a number of backtraces (in SoapProcess, HandlerIterator, AsyncResponseHandler, ProcessBuilder, etc), we have roughly this map:

SoapProcess -> HandlerIterator
                      |
                      | -> AsyncResponseHandler
                      | -> WorkAreaServerHandler -> XML Parsing -> ProcessBuilder
                      | -> Other handlers (21 total)

HandlerIterator Class

In here, multiple handlers are found in the handlers variable, and each has its own handleRequest routine. The code that actually performs the iteration goes like this:

for (; this.index < this.handlers.size(); this.index++) {

  Handler handler = this.handlers.get(this.index);

  // ... Some code goes here ... //

  try {
    context.setProperty("weblogic.wsee.handler.index", new Integer(this.index));
    if (!handler.handleRequest(context)) {
      // ... some code goes here ...//

At run-time, index 12 seem to hold our AsyncResponseHandler, and 16 is the WorkAreaServerHandler.

AsyncResponseHandler Class

The purpose of the AsyncResponseHandler classs is to process an incoming async response message. It is triggered when the client sends a request to the /_async/AsyncResponseService path. The official Oracle website actually has this documented quite well:

This handler only exists within the ‘async response service’ web service. The async response service is a special service that provides an addressable endpoint for services that have been invoked asynchronously by a client on the same server instance. The async response service is layered on top of our AsyncResponseBean JWS impl. To the server hosting the async response service, an async response looks like a request, but is the async response portion of a prior async request. This handler ultimately processes this async response using the ClientDispatcher handleAsyncResponse method, which uses the handler chain’s handleResponse logic. This handler assumes that at least one handler in the client handler chain will load the SoapMessageContext.getOutParams() map with the correctly processed async response message. It then stores this response (or fault) in the ASYNC_RESPONSE_PROPERTY (or ASYNC_FAULT_PROPERTY) context variable for use by AsyncResponseBean. This last (AsyncResponseBean) is ultimately called by the ComponentHandler. The AsyncResponseBean handles looking up the proper callback method on the JWS and invoking it with the async response processed/generated by this handler.

Since the PoC is feeding the action and relates field with random values, this would cause AsyncResponseHandler to bail in the handleRequestInternal method:

WsStorage storage = WsStorageFactory.getStorage("weblogic.wsee.async.store", new AsyncInvokeStateObjectHandler());

try {
  ais = (AsyncInvokeState)storage.persistentGet(relatesTo);
  if (ais == null) {
    throw new JAXRPCException("Cannot retrieve request information for message " + relatesTo);
  }
}
catch (PersistentStoreException e) {
  if (LOGGER.isLoggable(Level.FINE))
    LOGGER.log(Level.FINE, e.getMessage(), e); 
  throw new JAXRPCException(e);
} 

WorkAreaServerHandler

The WorkAreaServerHandler is actually the one that eventually triggers XML parsing. There seems to be no official API documentation about this class, but most write-ups related to WorkAreaServerHandler are associated with CVE-2017-10271.

When HandlerIterator calls WorkAreaServerHandler’s handleRequest method, this line is most interesting:

interceptor.receiveRequest(new WorkContextXmlInputAdapter(header.getInputStream()));

A lot of things happen in this line of code. The first that happens is the getInputStream() loading up the XML code for workarea, meaning this portion here, and returns a ByteArrayInputStream:

soap_payload <<     %Q||
soap_payload <<       %Q||
soap_payload <<         %Q||
soap_payload <<           %Q||
soap_payload <<             %Q|#{string0_cmd}|
soap_payload <<           %Q||
soap_payload <<           %Q||
soap_payload <<             %Q|#{string1_param}|
soap_payload <<           %Q||
soap_payload <<           %Q||
soap_payload <<             %Q|#{shell_payload.encode(xml: :text)}|
soap_payload <<           %Q||
soap_payload <<         %Q||
soap_payload <<       %Q||
soap_payload <<       %Q||
soap_payload <<     %Q||

After getting the ByteArrayInputStream, WorkContextXmlInputAdapter loads that in XMLDecoder:

private final XMLDecoder xmlDecoder;
public WorkContextXmlInputAdapter(InputStream is) { this.xmlDecoder = new XMLDecoder(is); }

The receiveRequest will then trigger WorkContextXmlInputAdapter to read the first object defined in the XML document with the readObject method:

public String readUTF() throws IOException { return (String)this.xmlDecoder.readObject(); }

After readObject is called, a chain of reactions will occur to deserialize the XML file back to Java code, which in this case is processing the malicious ProcessBuilder code.

Patch Analysis

In WorkContextXmlInputAdapter, instead of loading the InputStream directy to XMLDecoder, some validation occurs:

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()));
}

The validate method invovles checking a collection of XML tags that could be abused, such as: object, new, method, void, and array. These restrictions would easily stop ysoserial payloads:

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 array length limitation");
                }

                this.overallarraylength += var7;
                if (this.overallarraylength >= WorkContextXmlInputAdapter.OVERALLMAXARRAYLENGTH) {
                  throw new IllegalStateException("Exceed over all array limitation.");
                }
              } catch (NumberFormatException var8) {
                // ...
              };
  }

This is another priv esc in the win32k.sys system. It leverages windows popup windows to craft a race condition to overwrite an allocated section of memory, then hand that memory location to a funtion that executes it in Kernel mode.

It is being actively used in the wild.

The mitigations are pretty strong. Microsoft released a patch, and internal security controls on Windows 8 and above prevent writing to the allocated memory, so while the exploit might be present on later systems, it is not usable. In the writeup by the discoverer, (s)he claims that the fix in Windows 8 was backported to Windows 7x64 systems, but lists SP1 as vulnerable. I assume this means the fix was in a patch release.

This is a very well-written research paper, with lots of artifacts and a Github-hosted PoC. As privesc’s go, this looks pretty reliable. Since I’m not seeing any publications from Comodo yet, this may still be useful in the wild.

We still haven’t seen a PoC for this, likely because these switches are expensive and the firmware is paywalled. Further, the advisory returns a 503 right now, so here’s the archive.org link: https://web.archive.org/web/20190521004255/https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190501-nexus9k-sshkey

It’s interesting that this needs to be exploited over IPv6. However, it’s likely that a foothold in the target network or a tunnel through a compromised machine would allow access to this switch. These switches are used as part of SDN-based datacenters, so getting a foothold on a compromised server might allow an attacker to pivot to another subnet, VLAN, or cloud.

It’s terrifying that this certificate supports all issuance and application policies. Reddit users have proven that this can be used to MitM HTTPS-encrypted web browsing, as well as to sign code. It’s unclear as to whether the certificate is unique to each install (which would turn this into maybe a local privesc, or whether the certificate is shared across all installs, at which point this becomes a threat to any Dell user on a compromised network.

It’s also worth pointing out that some users didn’t have the certificate described, but then had it added later after running updates. So sysadmins might have checked for this, but then had their workstations put into a vulnerable state afterwards.

I’m seeing that it’s Windows Server versions 2012 though 2019, and that 2008 isn’t affected. But it’s been a few weeks and all we have to go off of is still the Microsoft advisory. That said, as Brian Krebs pointed out, this is the fifth vuln we’ve seen in Microsoft’s DHCP handling code, which would be super interesting given the broadcast nature of the protocol and the lack of logging and monitoring associated with DHCP broadcasts.

Given Firefox’s strong-armed autoupdater, it would be unlikely that a client workstation is still exploitable. However, the vulnerability reaches way back (into 2015), meaning kiosks and embedded devices are likely another story, especially if they’re using read-only storage to boot each time. These devices would likely be publicly-accessible and network-connected, but would require an attacker to be physically present or to gain control of the resource that the organization configures the kiosk to use.

While the author specifically lists ARP spoofing and DNS hijacking as necessary, I suspect ARP spoofing is not a needed step and DNS cache poisoning may also work to turn this into a remote, site-wide attack.

Perhaps more interesting is that it’s unstated (in both the blog post and the Dell advisory) whether this software supports auto-update, and it seems like Dell would have mentioned it if it did. Instead, Dell points to a manual EXE-based installer. The software only runs on Dell and AlienWare hardware, so I wasn’t able (or willing to be persistent enough) to get it to run in a VM.

There are a few PoCs for this one. Exim is a bear to setup and I wouldn’t be shocked to find unpatched servers because sysadmins don’t want to touch them. Since they’d be Internet-accessible, there’s a lot of attacker utility here for the small population that uses Exim.

Likely a dud, but it’s worth watching if this turns from a DoS to an RCE.

Watch this one for details. In the meantime, if you can’t patch, then block TCP/3389 (or whatever port you might be mapping RDP to), enable Network Level Authentication (NLA), or disable RDP.

This exploit is critical. RDP is ubiquitous in corporate settings, which are the most likely to have older Operating Systems deployed. That issue is complicated by the general reasoning that most older Operating systems are there to support legacy equipment and are less likely to receive automated patching.

EDIT (24-July-2019): Welp, we’ve heard lots of researchers say they’re privately holding onto PoCs, but now PoCs and details are starting to surface. It won’t be long until this one is easily weaponized, and I’m willing to bet it’s being used in the wild, if only in selected cases.

Alpine Docker prior to 7 March 2019, (edge 20190228 snapshot, v3.9.2, v3.8.4, v3.7.3, v3.6.5) do not set a root password, allowing a user to escalate to root if the user installs shadow or linux-pam. This docker image is used as a base for many custom-built docker containers and often-distributed images.

Older and unsupported containers can be mitigated by:

    # make sure root login is disabled
    RUN sed -i -e 's/^root::/root:!:/' /etc/shadow

Alternatively you could make sure that you don’t have linux-pam installed.

What common docker images use Alpine? Are any of them locked to older versions? It may be worth looking through the Docker Hub to identify commonly downloaded/starred images: https://hub.docker.com/search?q=alpine&type=image

CVE-2019-2725 (aka CNVD-C 2019-48814) exploits an XML deserialization vulnerability in Oracle WebLogic via the AsyncResponseService component. The exploit provides an unauthenticated attacker with remote arbitrary command execution.

According to the vendor, Oracle WebLogic Server v10.3.6.0 and 12.1.3.0 are affected.

In addition to a public proof-of-concept, a Metasploit module has been published to allow for exploitation of Windows, Linux, and Unix hosts. It has been successfully tested on v10.3.6.0, and exploitation failed against 12.2.1.2.

A vulnerability in the installed-by-default Widget Connector macro within Atlassian Confluence provides for unauthenticated remote code execution via a network-listening web service. The attacker sends crafted JSON via an HTTP POST request to the rest/tinymce/1/macro/preview endpoint, including a malicious _template variable which triggers the vulnerable server to callback to the client on an arbitrary IP address and port.

The vulnerability affects Confluence Server before version 6.6.12, from version 6.7.0 before 6.12.3, from version 6.13.0 before 6.13.3, and from version 6.14.0 before 6.14.2.

A pull request for this exploit was submitted to the Metasploit Framework on 12 April 2019. The Metasploit exploit module did not work when tested against 6.13.0.

Analysis

The nature of this exploit provides a reliable exploit onto a vulnerable server, with minimal downside of detection or crashing the target. In additon, the attacker can leverage HTTPS to encrypt the exploit attempt, bypassing network intrusion detection.

Overall, I think this exploit is going to be in high use. Given the popularity of Confluence, the tendency for organizations to self-host Confluence, and the lack of downsides for an attacker to try this exploit, I think we’ll see a lot of use out of this one.