Back To Blog

Confluenza and the Network Attack Surface, Part 2

A Story of the Confluence Exploit and ZTNA Hero

In Part I, we put on the shoes of a novice hacker and easily exploited a Confluence Server on the public internet, resulting in full network access. We also realize the problem is not specific to a software vendor but rather the common practice of placing servers on the public internet. 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.

In this blog I’m continuing the story by showing the hacker could easily give themselves persistent access to the server. The enterprise might have patched or upgraded the Confluence Server to a non-vulnerable version, but is it too late? Will the hacker still have server access? What about access to the rest of the network?

Network Persistence Before and After Confluenza

A compromised user account on the Confluence Server not only puts this server at risk, but can even grant east-west access to other resources inside the network perimeter. We lucked out with the sample server being configured improperly as it took only a few minutes to create a new sudo user, but since this CVE is all over the news we know the customer will probably upgrade or patch Confluence sooner than later.

Persistence can be accomplished using any remote administration tool (RAT), but to make it simple for this demo we simply configured an attacker server listening on port 443 with Netcat, and then executed the Netcat command on the Confluence server to initiate a reverse shell. Ports 80/443 are usually the least suspicious because most servers need to communicate outbound.

Why is this important? It’s not about the vulnerability itself but the fact that many enterprises can’t get everything patched or upgraded quickly, and these situations are impossible to predict. When you have servers and services exposed on the public internet that are not intended to be accessed by “anyone”, there is unnecessary risk being added to your organization. 

Simply patching the server to remove/remediate the vulnerability does not mean you are in the clear — if the server was already compromised, malicious actors will still have access! Even worse is if the malicious actors conducted additional exploration or lateral movement within your network. So even if you simply wiped the Confluence Server VM and spun up a brand new one with the latest non-vulnerable version, a malicious actor could still have authenticated access to your network.

Axis Security to the Rescue

Security is hard. Axis Security helps make it easier for organizations of all sizes by reducing the network attack surface and providing a seamless user experience. Four easy steps can help mitigate these threats, even if new vulnerabilities are found like CVE-2021-26084 in the future. 

The Axis Security ZTNA platform enables your organization to remove the need for inbound connectivity and prevents unauthenticated traffic from ever reaching your network or servers:

  1. Deploy an Axis Connector on your private network
  2. Configure your existing Identity Provider with Axis Security
  3. Create a web application and policy in Axis Security for your Confluence server
  4. Change the existing public DNS record to point Confluence to the Axis Security cloud
  5. Move the Confluence Server into your private network

That’s it! Your Confluence server no longer exists on the public internet and users can seamlessly access it just like before. You can repeat these steps for any other application servers in your DMZ that do not have to be open to the general public. 

The best part? This can be done without installing agents on user devices, and gives you an extra layer of protection for access-type vulnerabilities like Confluenza.

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!

Start Simplifying Your App Access