Rapid7 Analysis: CVE-2023

On October 4, 2023, Atlassian released an advisory for CVE-2023-22515, a critical vulnerability affecting on-premises instances of Confluence Server and Confluence Data Center. Atlassian initially described this vulnerability as a Privilege Escalation, but they have since recategorised it as a Broken Access Control vulnerability. Attlassian has provided a CVSS base score of 10.0, which appears appropriate based on our analysis.

Atlassian indicated that this vulnerability was exploited in the wild as a zero-day vulnerability, prior to their knowledge or a patch being available. The observed attacker behavior included leveraging CVE-2023-22515 to create a new administrator user, but we believe that this is not the only way the vulnerability could be used.

Our analysis concludes that this vulnerability is remotely exploitable by an unauthenticated attacker, and can be leveraged to create a new administrator account on the target Confluence server. This can lead to a total loss of integrity and confidentiality of the data held in the server. Since the root cause of the vulnerability allows an attacker to modify critical configuration settings, an attacker may not be limited to creating a new administrator — there may be further avenues of exploitation available. An OWASP classification of Injection , (i.e. CWE-20: Improper Input Validation ) seems more appropriate than Broken Access Control, as access control implies the use of either authentication or authorization as part of the vulnerability’s root cause. Our analysis indicates that the root cause lies in the lack of correct filtering in the SafeParametersInterceptor class.

We begin to explore this vulnerability by diffing the most recent vulnerable version of the software, version 8.5.1, against the patched version, 8.5.2. We extracted all the JAR files and decompiled their contents with the CFR decompiler. The following changes are notable and form the basis of our investigation.

The first thing we identify is the class com.atlassian.xwork.interceptors.SafeParametersInterceptor has been significantly modified, as shown below. Confluence is a very large Java application that is built upon the Apache Struts framework. As part of this, the framework is used. The XWork framework allows setting parameters on Java objects via HTTP parameters provided in a HTTP request. This is a known security concern for Confluence, and has been documented here .

XWork allows the setting of complex parameters on an XWork action object. For example, a URL parameter of formData.name=Charles will be translated by XWork into the method calls getFormData().setName(“Charles”) by the XWork parameters interceptor. If getFormData() returns null, XWork will attempt to create a new object of the appropriate return type using its default constructor, and then set it with setFormData(newObject).

This leads to the potential for serious security vulnerabilities in XWork actions, as you can effectively call arbitrary methods on an Action object.

Seeing the SafeParametersInterceptor class appear in the diff for this vulnerability indicates this may be an avenue for attack. The SafeParametersInterceptor class attempts to filter what parameters may be set by incoming HTTP requests.

We also see the com.atlassian.confluence.impl.setup.BootstrapStatusProviderImpl class has been modified. Both the getApplicationConfig and getSetupPersister methods have been changed. The patched version of these methods both return a wrapped object which, according to the naming convention used, is designated read only.

Exploring the new com.atlassian.confluence.impl.setup.ReadOnlyApplicationConfig class, we can see it uses the Delegation (also called Proxy) design pattern to forward calls to a delegate object whilst overriding some methods to enforce a read-only interface.

Of particular interest is the method setSetupComplete. As we know from the advisory, the vulnerability was exploited to perform actions in the setup endpoints of a Confluence server. We can see below that the patched version prevents changing the setup complete value, i.e. marking the Confluence servers setup as being not-yet complete.

Finally we can note that the Struts action server-info has been removed along with the accompanying Java class com.atlassian.confluence.core.actions.ServerInfoAction. This action can be reached via the URI /server-info.action.

While not obvious from reading the diff above, we must note that the class com.atlassian.confluence.core.actions.ServerInfoAction extends the class com.atlassian.confluence.core.ConfluenceActionSupport. This will be important during exploitation.

Examining the artifacts from both the Atlassian advisory and the patch diffing, we can begin to identify the vulnerability. It appears an attacker can modify the Confluence server’s configuration to indicate that server setup has not been completed. If this is done, the attacker can then leverage the server setup endpoint /setup/setupadministrator.action (as mentioned in the vendor advisory) to create a new administrator user. As we see the class SafeParametersInterceptor being modified, we can assume that this is the avenue that allows for modifying the server configuration, specifically via the ApplicationConfiguration class, as the diff shows new read-only restrictions have been added.

When installing a new Confluence server, the setup process to configure the server, such as connecting to a database and creating the default administrator user, is performed via a web browser and several HTTP requests to endpoints located within the URI path /setup/. A new administrator account is created by a HTTP POST request to the /setup/setupadministrator.action endpoint. After setup has been completed, all setup endpoints are prevented from being called.

For example, the following cURL request to create a new administrator will fail with an error message that reads “Your confluence instance is already completely set up.”. Note, the X-Atlassian-Token: no-check header allows us to avoid the XSRF check, as implemented in the com.atlassian.xwork.interceptors.XsrfTokenInterceptor.

To understand why this is happening, we explore the application’s struts.xml file. This file contains a list of interceptors . These interceptors execute before (and after) a Struts Action (such as /setup/setupadministrator.action) is executed. One such interceptor is SetupCheckInterceptor.

We can see below that the SetupCheckInterceptor will test BootstrapUtils.getBootstrapManager().isSetupComplete() as part of the check to determine if the Confluence server is already set up.

Examining the implementation of DefaultAtlassianBootstrapManager.isSetupComplete we can see that the application configuration method isSetupComplete is called to check if the setup has been completed.

If we can make isSetupComplete return false, then SetupCheckInterceptor will not return “alreadysetup” and the setup endpoints, such as /setup/setupadministrator.action will become accessible.

As we already saw from diffing the patch, the class com.atlassian.confluence.impl.setup.BootstrapStatusProviderImpl was modified to enforce a read-only application configuration. We therefore want to target the application configuration instance and call its setSetupComplete method with a parameter of false. This will make isSetupComplete return false.

We know we can leverage the XWorks2 feature of supplying HTTP parameters to call setter methods on objects. We need to identify an unauthenticated endpoint whose Action object also exposes a suitable get method that will allow us to access the application configuration.

Remembering the class com.atlassian.confluence.core.actions.ServerInfoAction, seen during diffing, we explore the base class it inherits from, com.atlassian.confluence.core.ConfluenceActionSupport.

We can see this class has a getter method getBootstrapStatusProvider which returns the BootstrapStatusProviderImpl instance we are looking for.

BootstrapStatusProviderImpl, in turn, has a getter method getApplicationConfig to return the application’s configuration.

Finally, we can see the class com.atlassian.config.ApplicationConfig implements the setter method setSetupComplete.

Putting this all together, we know that from the class com.atlassian.confluence.core.ConfluenceActionSupport, we would need to call the following chain of methods to set the setupComplete variable to false.

As we know XWorks2 will allow us to perform this type of getter/setter sequence, we can construct an HTTP parameter that implements the above chain of method calls using the notation that XWorks2 requires.

Stepping through SafeParametersInterceptor.doIntercept in a debugger, we can observe that while the parameter we supply is identified and filtered via SafeParametersInterceptor.filterSafeParameters, this has no effect on the underlying base class ParametersInterceptor, which will continue to process all the parameters supplied.

Finally, we can trigger the vulnerability with the following cURL request against the unauthenticated /server-info.action endpoint.

After the above has completed, we issue a new request to the endpoint /setup/setupadministrator.action, which will now succeed. A new administrator has been created with a password we control.

To avoid a message being displayed to all users, stating that setup has been completed, we can issue a request to the /setup/finishsetup.action endpoint.

We can now log into the target Confluence server as the newly created administrator haxor.

We have seen that the root cause of this vulnerability is the attacker’s ability to perform complex getter/setter chains on the Action object for unauthenticated endpoints, allowing for modification of critical properties. By modifying the setupComplete variable, the attacker was able to leverage the setup functionality to create a new administrator user. However, the attacker is not limited to this, and it is reasonable to assume there are other avenues of exploitation beyond targeting a specific endpoint such as /server-info.action which inherits from ConfluenceActionSupport (as do many other actions), or leveraging the vulnerability to create a new administrator user.

The Confluence access logs , for example C:\Program Files\Atlassian\Confluence\logs\conf_access_log.2023-10-06.log, will contain log lines for each HTTP requests received. For example:

We can see the 3 URI paths from conducting the attack as described in this analysis. The query parameters ?bootstrapStatusProvider.applicationConfig.setupComplete=false used to modify the application’s configuration are also seen as part of an HTTP GET request. Depending on how the attacker leverages the root cause of the vulnerability, the query parameters may differ. Additionally, if an attacker can locate another suitable unauthenticated endpoint, the URI paths may differ from the above.

Versions prior to 8.0.0 are not affected by this vulnerability. According to Atlassian’s advisory, Atlassian Cloud sites are not affected by this vulnerability. Confluence sites accessed via an atlassian.net domain are hosted by Atlassian and are not vulnerable to this issue.

For more information, refer to the Atlassian advisory and release notes .