Last Friday, Volexity published a zero day exploit (CVE-2022-26134) on Atlassian Confluence. This post is to share some tips on how to check your Confluence instance is safe, and also some practical advice to protect your Confluence on-prem. 

About the vulnerability

This bug affects all versions of Confluence since 1.3.0. It is a critical vulnerability because it allows unauthenticated users to execute code within the Confluence server remotely. According to Imperva Threat Research, there are widespread scanning and attempts of exploitation on the Internet.

How to fix the vulnerability

Atlassian alerted the customers promptly and responded with high priority. We are thankful that Atlassian released the fix in less than 24 hours.

For details of the fix, please refer to the official Confluence Security Advisory 2022-06-02.

How to check your Confluence for malicious access

Here are some basic checks that you can execute to check for any traces of malicious attempts. If there is any occurrence, then you may want to engage the security experts for more in-depth foresenic investigation.

URL requests containing ${

Since one of the attack mechanisms is to use ${ in the request URL, it would be helpful to scan the web server access logs for any occurrences. Please update the path of the Apache httpd/ Nginx access logs accordingly.

grep '${' /etc/httpd/logs/*access*.log
grep '%24%7B' /etc/httpd/logs/*access*.log

URL requests from known IP addresses

Based on the Volexity report, there are some IP addresses which are used by the attackers. Similarly, you can grep the access logs to check for any occurrences. Note: It is possible that there may be other attackers using other IP addresses.

grep 154.146.34.145 /etc/httpd/logs/*access*
grep 154.16.105.147 /etc/httpd/logs/*access*
grep 156.146.34.46 /etc/httpd/logs/*access*
grep 156.146.34.52 /etc/httpd/logs/*access*
grep 156.146.34.9 /etc/httpd/logs/*access*
grep 156.146.56.136 /etc/httpd/logs/*access*
grep 198.147.22.148 /etc/httpd/logs/*access*
grep 198.147.22.148 /etc/httpd/logs/*access*
grep 221.178.126.244 /etc/httpd/logs/*access*
grep 45.43.19.91 /etc/httpd/logs/*access*
grep 59.163.248.170 /etc/httpd/logs/*access*
grep 64.64.228.239 /etc/httpd/logs/*access*
grep 66.115.182.102 /etc/httpd/logs/*access*
grep 66.115.182.111 /etc/httpd/logs/*access*
grep 67.149.61.16 /etc/httpd/logs/*access*
grep 98.32.230.38 /etc/httpd/logs/*access*

How to protect your Confluence instance

Actually, the best form of defense against unauthenticated attacks is to place the server behind the firewall. This will effectively block all attackers from mounting a direct attack remotely. That is a key reason why some security sensitive enterprises are choosing Confluence Data Center. We know that it is not possible for a software to be 100% free of bugs. So there might be another vulnerability waiting to be discovered in the future.

By using Long Term Support release of the product, it reduces the effort to upgrade since the critical security fixes will be available as long it is architecturally possible. This contributes greatly to a quick reaction to any future zero day exploits.

For those organizations who are working remotely, it is possible to access via VPN or use Web application firewalls for added protection. Both CloudFlare and Imperva have announced that their customers are protected from this vulnerability since they will ensure all requests are authenticated before relaying it to Confluence.

Last but not least, do make sure the license technical contacts are up-to-date. As an Atlassian Solution Partner, we have witnessed a number of occurrences when critical alerts from Atlassian are missed due to staff turnover.