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!

The post Confluenza and the Network Attack Surface, Part 2 appeared first on Axis Security.

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!

The post Confluenza and the Network Attack Surface, Part 1 appeared first on Axis Security.

A vulnerability is published on the CVE program. That means, due to the responsible disclosure procedure, that the affected vendor was already informed about it. At that point, it’s safe to assume that advanced threat actors and nation states probably already knew about it and how to exploit it effectively. However, once in the public domain, it’s a whole different ball game. Bug bounty hunters, cyber criminals, and researchers looking to make a name for themselves start the race to the effective exploit. The vendor has probably already released a patch, but patches take time to propagate, and the patch can be reverse engineered by adversaries to better direct themselves towards the vulnerable areas.

In some cases, like the notorious Conficker worm that affected virtually every windows machine online, this leads to a widespread computer worm. In others, like BlueKeep, it allows for ransomware to propagate easily and without human interaction within networks.

So what happened? (and why should enterprises be concerned)

On August 25th 2021 a remote code execution vulnerability of Atlassian Confluence was published and given the identifier CVE-2021-26084. The clever name Confluenza was later given to it. It affected virtually every version of Confluence that’s not hosted by Atlassian. A patch was made available that day, but we all know old versions die hard.

On Aug 31st, 2021, rootxharsh and iamnooob published an exploit for CVE-2021-26084. At that point, every half-savvy attacker could scan for vulnerable instances and wreak havoc.

The vulnerability took advantage of an insecure handling of OGNL, an expression language that provides syntax for evaluating expressions. Generally, it allows an attacker to craft an OGNL expression and send it to the remote server for evaluation. That evaluation can include the execution of arbitrary code on the remote server hosted on the victim’s network. Even worse in this case, the vulnerability extends to non-authenticated users so even strong auth and MFA can’t help if the threat actor has direct access to the application. Infect with ransomware? Steal data? Install a backdoor? Whatever the adversary’s goal is – this is one huge leap towards the crown jewels. This is a big deal.

Confluence is a wiki-like collaboration tool that is part of the Atlassian suite. According to Atlassian, 83% of Fortune 500 companies use their suite of products. Their products are ubiquitous among product and R&D teams. Many organizations use it as the formal means of maintaining a knowledge base, but sometimes it is introduced into the organization from the bottom upwards. Confluence is offered for a trial period for free, so teams may have set up a vulnerable instance that has since been forgotten. Think they’re going to patch it?

What’s next?

For this vulnerability, the patch is out, and it’s best to patch all Confluence servers on your network. Some WAF configurations have also been suggested, though this is not foolproof and can be circumvented, something is better than nothing.

This is not a trivial task. Organizations seldom keep a full inventory of their applications, and shadow IT is still an issue for many organizations.

ZTNA – at your service

So it would be really helpful to have all of your apps services cloaked and hidden from the public internet, and the intranet for that matter. To prevent direct access. To have every request or action accounted for. To gain out-of-the-box remediations that would have prevented this vulnerability even before it was published. That’s exactly how ZTNA is moving the legacy network security paradigm of having to be perfect every time, to a significantly reduced attack surface.

Without deploying any agents, without making modifications to the network or server, and without publishing an internet-facing endpoint – Axis already helped enterprises get full protection, visibility and control over their Confluence, Jira, and other corporate applications. When this vulnerability was released, they could remain calm. Their servers are outside the reach of scans and attackers, and the built-in sanitization and WAF capabilities would prevent even privileged users from exploiting this vulnerability.

Responding to new vulnerabilities can feel like a game of “whack-a-mole”, but organizations that adopt a Zero Trust architecture have longer time to respond, fewer possible ways in, and a much smaller blast radius when an attack does happen. There is no better time than now to make a change. Axis Security helps customers transform legacy networks to Zero Trust architecture in minutes. This is a rare opportunity to improve both security and user experience. Please don’t hesitate to reach out and let us know how Axis can help.

The post Confluenza: What is CVE-2021-26084 and why should you care appeared first on Axis Security.