Confluenza and the Network Attack Surface, Part 1

A Story of the Confluence Exploit and ZTNA Hero

It feels like there’s a new story every week about a vulnerability that affects thousands of enterprises. This is great job security for everyone working in InfoSec, as well as anyone on the “other” side! Before we get to the fun stuff, I want to reiterate how vulnerabilities like this can happen to any vendor. We are here to learn from these situations and share insights on how these types of situations can be mitigated. Make sure to read Confluenza: What is CVE-2021-26084 and why should you care by Gil Azrielant (CTO, Axis Security) for more technical details around this exploit.

Let’s get started with a little background on the Network Attack Surface and how it relates to Confluenza… Many organizations still have vulnerable Confluence Servers exposed to the public internet! This might make sense when using Confluence to collaborate with external users, partners, or customers. In many cases the protection is a firewall, a WAF, and strong authentication.

The other option is to bring the Confluence server into the private network so it no longer is accessible on the internet, but this prevents many organizations from conducting business properly when third party users or customers need to access the server. Giving users a VPN client isn’t a great option from a user experience standpoint. More importantly, many VPNS are (improperly) configured with much greater network access than required for a use case such as this. This contributes to a larger attack surface beyond one server. Parts of your entire network can be exposed via lateral movement!

What if I told you there is a way to reduce your overall network attack surface that can also protect your organization when the next pre-auth vulnerability is found in software you own?

*It is important to make a distinction that I am referring to how reducing the attack surface prevents anyone on the public internet from seeing or communicating with your servers. If your servers are vulnerable, you are still at risk from insider threats and users/devices that have access to your internal network. You should absolutely always maintain software with the latest updates, but reducing the attack surface helps mitigate against the unknown outsider threats (basically over 4.5 Billion global internet users)!

Proposed Solution:

• Bring your servers back into the private network (no more inbound connections from the internet, no more public DNS records, no more public IP addresses)
• Prevent unauthenticated sessions from ever reaching your network, even to web applications
• Provide a seamless user experience for employees, contractors, and even customers
• Helps mitigate future risk when other software vulnerabilities are found (by reducing the number of users and devices that can get to the “front door” of your applications)

Exploit in Action

Curious how easy it is to exploit this vulnerability? We will walk through the steps a novice hacker might take to get access to an enterprise network, how the network might still be exposed even after patching or upgrading to a non-vulnerable version of Confluence, and how the Axis Security ZTNA platform can help your organization.

Step 1 – Finding some Confluence targets

First thing we need to do is find some Confluence Servers on the public internet. There are many tools, scripts, lists, and websites that make scanning for targets easy. What we demonstrate here is that using even the simplest means of finding companies that have:

DNS records that include “confluence” (such as confluence.mycompany.com). Once you find a record that points to an IP address you can make a safe bet it’s a Confluence Server hosted in their network
3rd party tools, such as Censys or Shodan, can be easily used to scan for open confluence servers regardless of the port being used

Step 2 – Running the Exploit

Now that we have our target, it’s a matter of running this simple exploit. There are quite a few GitHub repos with scripts in various languages that can execute this exploit. For this demo I decided to go with a Go version found here: https://github.com/taythebot/CVE-2021-26084. 

All I have to do is run the Go app with the target Confluence Server URL and it immediately reveals if the server can be exploited. I also have an option to create an interactive remote shell to execute commands, or can pass commands individually. Examples below:

• Interactive Shell: go run exploit.go -t https://confluence.mycompany.com -i
• Runs Individual Commands: : go run exploit.go -t https://confluence.mycompany.com -c whoami

It’s really THAT EASY!

Step 3 – Executing some Remote Commands

Now the real fun starts. We probably want to see what OS is hosting the Confluence server, what groups and permissions the current user has, is the user part of the sudoers group, etc. In our demo we decided to run just a few commands to get more information about the server, users, permissions and network. Here’s what we found and did in less than a few minutes:

• The confluence user is part of sudoers
• The server is configured to not require password to sudo
• The OS is Ubuntu 20.04
• Created a new user badguy
• Added badguy to the sudoers group
• Installed and ran some tools like nmap

What Comes Next?

Tune in for Part 2 of this story to find out how the novice hacker stayed in the network (persistence) even after the Confluence Server got patched, and how Axis Security can help. Hint: If your Confluence Servers are no longer reachable on the public internet, will a hacker still be able to use a pre-auth vulnerability like Confluenza to compromise your network?

Worried about excessive VPN permissions? We are too. Read our white paper here.

Please reach out to us if you would like to learn more about the Axis Security platform!