Overview

Atlassian Confluence Server is a popular web-based corporate content management system, allowing remote teams to collaborate efficiently on projects. With over sixty thousand customers including Docker, Linkedin, and Twilio, vulnerabilities in Confluence could have a significant impact on a large user base.

While performing detailed service permissions analysis using our flagship product, we discovered numerous products in production environments which are installed with unsafe permissions.  Root cause analysis of these permissions settings has led us to identify flaws in the way many products are installed, including Confluence Server.  These flaws allow for local privilege escalation attacks, typically allowing any unprivileged user to take complete control of the host.  More information on service permissions, DLL sideloading/hijacking, and related issues can be found in our previous blog post on the topic, as well as in the vulnerabilities we have published to date (CVE-2021-29221, CVE-2021-26556).

Confluence installs itself as a Tomcat service, Tomcat9.exe, which runs as NT AUTHORITY\Network Service. While this vulnerability does not represent a direct escalation to LocalSystem, there appear to be publicly documented techniques that could allow an attacker to further escalate from Network Service to LocalSystem (the fully privileged administrative user). This vulnerability would also allow any user to gain control of the Confluence service and any sensitive data it may have access to.

Exploitation

Below, we demonstrate how Atlassian Confluence is vulnerable to a DLL hijacking attack under certain conditions, allowing an unprivileged local attacker to take over the Confluence service.

To demonstrate this flaw, we first acquired the software installer.

During the installation we used the default settings at every step, except for the installation directory which we changed to C:\Confluence in order to demonstrate the permission misconfiguration. This directory can be created through the installer GUI.

If the installation is successful, we should find the service is registered as demonstrated by the following command:

Note the improper permissions, BUILTIN\Users Allow *, on the installation directory, which are inherited from the drive root. This gives any local user the ability to create arbitrary files in the installation directory, which we can then leverage in a DLL hijacking attack.

To fully demonstrate the implications of this vulnerability, first create a new unprivileged user. Then, as this new user, download the provided IPHLPAPI.dll file. Note how the user has permissions to add the poisoned DLL to the installation directory.

From here, restart the computer, or restart the Confluence service as an administrator. The payload contained in the DLL will then execute and the evidence of that can be found in the text file  C:\Confluence\pwned.

The Fix

The vendor, Atlassian, has acknowledged the issue and is working on a new version which corrects the vulnerability.  Unfortunately, the vendor was unable to provide updated software within the 90-day disclosure time frame.  However, Atlassian did publish an informational page containing detailed technical information and work-arounds for customers in the mean time.  Confluence Server administrators may also consider leveraging the script at the bottom of our previous blog post.

We will update this post once a CVE and patch are provided by Atlassian.

Vendor Notification

Feburary 25th, 2021	Reported to security@atlassian.com
March 1st, 2021	Confluence team response
March 24th, 2021	Continued correspondence with Confluence team
May 10th, 2021	90 day deadline reminder
June 1st, 2021	Confluence provided draft public vulnerability page
June 3rd, 2021	DeepSurface advisory published

Acknowledgements

We would like to thank the Confluence security team for their excellent response and thoroughness in investigating this issue.