Introduction

On January 16 2024, Atlassian issued a ​​significant alert on a critical Server-Side Template Injection (SSTI) vulnerability in Confluence Data Center and Server, identified as CVE-2023-22527. This issue found in older versions, poses a serious risk as it allows attackers without any authentication, to inject OGNL expressions. This means they could potentially run any code they want on the compromised system. Atlassian has given this vulnerability a critical rating, scoring it a perfect 10.0 on the CVSS scale.

Exploitation

Wallarm detected first exploitation attempts on January 20, 4 days after Atlassian published the advisory. The majority of attacks were scanning activity in order to identify the vulnerability using an Out-of-band Application Security Testing (OAST) technique.

A significant increase in attacks was observed on January 22-23.

Our analysis indicates that the significant growth of attacks on January 22 aligns with the publication of Project Discovery’s research published that day. The research provided technical details, exploit code and the nuclei template for vulnerability detection.

During the attacks that we monitored on January 22 and 23, we identified more aggressive exploitation attempts, such as executing system commands or reading system files, a shift from just scanning. As of the time of this post we have not detected any attempts of targeted attacks and execution of techniques aimed at obtaining persistence access on the host, uploading of webshells or delivering additional payloads (implants) for communication with Command & Control (C2) servers.

The most recent supported versions of Confluence Data Center and Server are not affected by this vulnerability as it was mitigated during regular version updates.

We highly recommend promptly upgrading the Confluence Data Center and Server. If your confluence installation is exposed to the Internet, we highly recommend detaching the system from the Internet immediately and checking for malicious Indicators-of-compromise on the server. 

Wallarm has added additional rules for detecting exploitation of this vulnerability. Wallarm clients have the option to utilize and configure the product’s Virtual Patch feature to block the exploitation attempts if nodes are configured in monitoring (non-blocking) mode.

Previous Confluence Vulnerabilities

The Server-Side Template Injection vulnerability discovered in January is the third critical vulnerability discovered in Confluence Data Center and Server within the last 6 months. 

Previously, a Broken Access Control vulnerability (CVE-2023-22515) was discovered in October 2023 and an Improper Authorization in Confluence (CVE-2023-22518) was disclosed in November 2023 (we wrote about it here).

The first one, Broken Access Control vulnerability (CVE-2023-22515), allowed unauthenticated attackers to create unauthorized Confluence administrator accounts and access Confluence instances. 

The second Improper Authorization in Confluence (CVE-2023-22518) allowed an unauthenticated attacker to reset Confluence and create a Confluence instance administrator account. Using this account, an attacker can gain unfettered access and perform administrative actions that are available to Confluence instance administrators leading to full compromise of confidentiality, integrity and availability.

Both vulnerabilities were actively exploited in the wild. Since initial disclosure, we have observed persistent exploitation of both vulnerabilities as demonstrated on the diagram below.

Although the number of attacks for the vulnerability discovered in October started slowly decreasing by the end of year, the number of attacks is still significant. For November's vulnerability there is no decreasing trend and conversely there was an increase of attacks by the end of the year. Based on these two examples, we can expect to see a significantly high frequency of attacks targeting January's vulnerability for at least for the next 3-4 months.

Conclusion

The Server-Side Template Injection vulnerability discovered in January is a third critical vulnerability discovered in Confluence Data Center and Server within the last 6 months. All three vulnerabilities provided an unauthenticated attacker a way to gain control over the Confluence instance and execute commands on the corresponding server. The potential presence of 3 different vulnerabilities makes outdated Confluence instances a desirable target not only for attacks from the Internet but also for lateral movements attacks in the internal network.

In addition, the sequential discovery of three critical vulnerabilities attracts the attention of security researchers and bug hunters. We might expect the discovery of new vulnerabilities in Confluence software in 2024. While this is only an assumption, we highly recommend preparing for new threats by following the defense-in-depth approach: 

• Make an inventory of Internet-facing applications and reduce your external attack surface.
• Implement a regular update-management process.
• Implement a WAF/WAAP solution as an additional layer of protection. The advantage of such solutions is that even if the vulnerability is new and unknown (0-day), it may still prevent attacks by detecting the exploitation patterns and techniques.

References

• NVD NIST
• Vendor’s Advisory
• Vendor’s FAQ
• Nuclei Template

Product Changelog

Wallarm has added rules for detecting exploitation of a critical Server-Side Template Injection vulnerability in Confluence Data Center and Server (CVE-2023-22527). The vulnerability allows an unauthenticated attacker to inject OGNL expressions into the Confluence instance and, thus, execute arbitrary code in the system. Since the nuclei template for vulnerability detection was published, we have observed multiple scanning updates in client infrastructure. 

We highly recommend upgrading the Confluence Data Center and Server as soon as possible. If your confluence installation is exposed to the Internet, we highly recommend detaching the system from the Internet as soon as possible and checking the server for malicious Indicators-of-Compromise. 

Wallarm clients can also utilize and configure the product’s Virtual Patch feature  to block the exploitation attempts if nodes are configured in monitoring (non-blocking) mode.