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.

It’s been an eventful 12 months. With people working from home, there’s been an over 40% surge in machines accessible from the internet running RDP, with RDP attacks up over 400%.¹ This site even has instructions for how to create more than one RDP instance on the same Windows 10 machine.² There are also  these instructions for Windows 2016, that create a larger attack surface that by allowing multiple RDP connections into the same endpoint.³ Lots of companies enable access to critical systems via web portals with logins requiring you pass identity authentication, but SolarWinds SUPERNOVA and Microsoft Exchange ProxyLogon showed how quickly a vulnerability compromises that security. 

But are hackers really scanning the internet, looking for places to attack? Have you wondered how often an average IP address gets scanned and then attacked? I decided to find the truth in the humorous movie quote, “If you build it, he will come” by setting up a basic honeypot with a boring name in an out-of-the-way web hosting center. This, I thought, might answer the question of whether attacks are focused on the big IaaS/PaaS providers, or whether an SMB (that I’d be mimicking) might be found, scanned, and then attacked—and how quickly.

What is a honeypot, you may ask? The term comes from the world of espionage, wherein spies used romance as a way to steal secrets, which was called setting a ‘honey trap’ or ‘honeypot’. The cyber version works in a similar way – creating a sacrificial computer system that is designed to sit on the internet and look innocent and unprotected, mimicking a target for hackers. It uses their attacks to gain information about the tactics, techniques, and procedures (TTPs) used by malicious actors.

The Experiment- Setting up the honeypot trap

Here are the four simple steps I used to mimic an SMB on a budget.

1. Signed up for an account with a cloud provider that isn’t one of the well-known three AWS, Azure, GCP.
2. Spun up a Linux VM and deployed a multi-spectrum honeypot.
3. Attached a public IP to this VM.
4. Monitored the logs.

Why An Account on a Smaller Cloud Provider?

For this test, why did I not want to sign up with the top three cloud providers? I suspect their public CIDR blocks are perhaps too well known and top of the list for botnet scanning. I know people are constantly looking for insecure AWS configurations, S3 buckets with clear text passwords, and, likewise, Azure blobs for configuration errors that are easy to hack.

Deploying the Honeypot

While you could run various opensource honeypots a la carte, there is no substitute for a full spectrum package like T-Pot. It containerizes 19 honeypot projects, each specializing in a particular service, that has them working together like a complex organism. The included ELK Stack was the cherry on top to present all collected data in a beautiful dashboard. Data is broken down in multiple ways to help you visualize patterns quickly from most popular ports probed by origin country to Username/Password combos attempted most often. Every organization should have at least one T-Pot running. I can’t recommend this Github project enough.

I was expecting plenty of scanning—everyone gets scanned, all the time. If you have no services open and you are only listening to the traffic, you have little to worry about. Being port scanned, while mildly annoying from generating extra logs on your firewall, does no actual damage. At high volumes, the constant scanning could cause your threat hunting team to miss an actual attack commencement amongst the noise, but that’s a topic for another post.

I thought about spinning up a regular server with WWW/RDP/SSH/VPN services to mimic a real-world machine in the wild. However, the logging facilities are geared towards the day-to-day operations and not optimized for detecting port scans and interactive hacking attempts.

Attaching the Public IP

I purposely did not advertise my IP to the hackers with an exciting DNS record like:

• portal.acme.com
• webmail.acme.com
• ssh1.acme.com
• F5APM.acme.com
• Solarwinds.acme.com

Monitoring the Logs

I bet you have a number in mind for how long it took for crawlers and botnets to find my anonymous IP and start scanning it. I wondered too—would it take them an hour? 1 day? 1 week?  
How about 30 seconds? Yes, within 30 seconds the scans started showing up. Within 60 seconds, I had my first login to Cowrie (SSH honeypot service). And within 3 minutes, the first exploits were being uploaded and captured by Dionaea, the malware and exploit capture honeypot. (All this visibility was achieved by running T-Pot, which will open your eyes quickly to the unseen internet.)

I let the experiment run for only two weeks, and here are my results:

Adding up the stats from all 19 honeypots, I was hit by roughly 2 million attacks against my single public IP. That’s not scans—that’s active toolkits and scans and attempts to compromise through my (fake) available services.

Doesn’t VPN or VDI Technology Make You Safer?

Yes, I introduced an attack surface to the world that looked ripe for the plucking. But this is no different than every enterprise out there who has needed to host publicly facing Web/SSH/RDP/VPN services for their employees to access internal tools they need to do their work. Working from home was not merely an option due to Covid, it was a requirement for most jobs requiring a computer.
Many organizations are attempting to minimize their IP attack surface by hiding their internal services behind the VPN Concentrator or a Secured Portal like F5’s APM. But as illustrated by F5’s recent announcement of critical vulnerability CVE-2021-22986 that allows Remote Command Execution, by just having the F5 BIG-IP exposed and listening on the internet introduces a lot of risk. And attacks against VPNs themselves are rising; Citrix and Fortinet have both had their VPN modules hacked. Virtual Desktop Interfaces (VDIs) are under siege as well.

What About Patching management?

As all long time Microsoft administrators know, patch Tuesday brings a bounty of bug announcements with their fixes from Microsoft. Exploit Wednesday quickly follows as bad actors waste no time in modifying their weapons with the newfound knowledge. Unfortunately, this is often followed by ‘Uninstall Thursday’ as patches, not just from Microsoft, have resulted in introducing other critical issues to the patched system. 

When you’re patching a single node, the risks are fairly low. However, if you’re patching a VPN gateway or F5 APM that all your employees depend on daily, the risks of patching are substantially higher. As one VPN vendor support engineer once told me, “We urge you to apply the patch to your VPN ASAP, but there is a 40-50% chance you might, just might, brick the box. So be at a location where you can physically reboot the box and have access to lights out management to undo the patch.”

Conclusion

You can’t leave your network open, but you can’t always patch reliably; what should a responsible CISO to do? There is a better choice in a Zero Trust Network Access model. A SaaS ZTNA solution makes your old VPN attack surface disappear. Hackers can’t attack what they can’t see. The Axis Security Application Access Cloud provides complete ZTNA protection using a SASE overlay approach, so no matter where the applications live or where the users are logging in from, you get end-to-end protection from device to network to app. It even includes features like adaptive access controls, user monitoring for dangerous activity, and the ability to revoke access and end sessions if threats are identified.

¹ RDP attacks up over 400%: https://www.zdnet.com/article/ten-disturbing-coronavirus-related-cybercrime-statistics-to-keep-you-awake-tonight/

² Increase in RDP connections: https://www.thewindowsclub.com/increase-the-number-of-remote-desktop-connections-in-windows-10

³ Enable concurrent RDP sessions: https://social.technet.microsoft.com/Forums/en-US/c52b6da7-cdf2-4e1f-95d1-6471c6f2f6b0/easiest-way-to-enable-more-than-2-concurrent-rdp-sessions-on-windows-server-2016?forum=winserverTS

The post How do Hackers Hack – An Experiment in Open Portal Attacks appeared first on Axis Security.