Confluence OGNL Injection Vulnerability
Atlassian announced a vulnerability in the very popular (and very good) Confluence software: CVE-2021-26084 (an OGNL injection – in fact, very similar to the infamous Equifax vulnerability of 2017).
Atlassian reacted well to quickly provide a patch, and hopefully organizations implement the patch soon (scans taken show there were likely over 10,000 Atlassian Confluence servers running the exploitable version), but many orgs have already announced they were breached.
Fortunately, NetFoundry customers were protected because their Confluence servers (and other app servers) are essentially off the network due to NetFoundry’s unique Zero Trust 2.0 architecture. Attackers could not reach NetFoundry protected Confluence servers in order to exploit the vulnerability.
This Zero Trust 2.0 paradigm shift of completely closing down the network paths is important beyond the Confluence case – there will always be vulnerabilities in software (there will be over 20,000 CVEs this year) – so it is critical to reduce the surface area by which those vulnerabilities can be exploited. In fact, the same architecture also protected NetFoundry customers from recent attacks such as the Kaseya ransomware attack, because those attacks also required the cyberattack to get access to exploit the vulnerability.
Note: there are many differences between Zero Trust 1.0 and NetFoundry’s Zero Trust 2.0 (see the paper linked at the bottom for a full analysis), but a primary difference is the inbound firewalls ports are still open in Zero Trust 1.0. In other words, ironically, Zero Trust 1.0 solutions suffer from the same Firewall Fallacy that doomed VPN and SD-WAN solutions.
Why didn’t our firewalls, VPNs and SD-WANs protect us against the Confluence, Kaseya and other similar attacks which will cost us over $1 trillion this year? Because firewalls usually don’t know the difference between your actual Confluence users and ransomware attackers. Here’s how both your Confluence user and and attacker “identify” themselves to your firewall: IP address 188.8.131.52.
Yep, they look the same, because they are both using IP addresses as identities. This forces us to to open inbound ports in our firewalls. Then, after the firewall, we try to separate between your Confluence user and the cyberattack. Unfortunately, that doesn’t always work, as evidenced by all of these successful attacks (even the act of keeping thousands of firewall rules up to date adds complexity and potential for errors).
Add Identity To The Party
Ok, we need a stronger identity than IP addresses. We’ll use X.509 certificates, bidirectionally authenticated per session. We’ will include those identities as part of software endpoints which can go anywhere (even inside an application such as Confluence – see the video at the bottom of this post for when we embed the endpoint in a Postgres driver to enable agentless zero trust):
Great, so we now closed all the ports on our firewalls, eliminating the network paths to our Confluence servers, which means the cyberattack can’t get to the server to exploit CVE-2021-26084. That’s progress but now our actual user (on her mobile phone) can’t get to Confluence either. There is no data path for her to get to Confluence, or even to the Private Fabric Routers in the middle. Good! We only want to spin up a path if she is strongly identified, authenticated and authorized for the specific Confluence resource she is requesting (least privileged access).
Authorized, Least Privileged Access
In NetFoundry’s Zero Trust 2.0 architecture, if a data path is to be opened, it needs to be identified, authenticated and authorized for the specific service it is requesting (Confluence in this case). IF that happens, then the user will get an ephemeral data path, good for that specific session, brokered by the Private Fabric Routers:
Our cyberattacker is still out of luck – no credentials by which to request a connection (and no easy way to get them like brute forcing passwords, hacking MFA or even manipulating/tricking users…because we are using private key – public key X.509 bi-directional certificate exchanges). Our attacker can’t even see the nodes – there is no network path.
How about our Confluence user? She actually doesn’t yet have a data path either. Not until she is able to identify, authenticate and receive least privileged access authorization from the session control layer of her Private Fabric (not shown in diagram – discussed in the linked paper at the bottom). After that authorization, she gets access to an ephemeral data plane, brokered by her Private Fabric Routers, to get to her Confluence Server. The Confluence Server is meanwhile protected – no inbound ports are opened. Instead, both our user, and the Confluence server open session-specific, ephemeral, least privileged paths to their Private Fabric Routers (the Routers use the same strong identification, authentication and authorization solution as the other endpoints).
The least privileged part means that if our user tries to connect to some other app – let’s say Mattermost – but doesn’t have access to that specific app, then she is in the same boat as the cyberattacker. This is really important because if here Confluence session is compromised, the attack can’t spread laterally to other assets such as Mattermost.
Spin up Zero Trust 2.0
Most of us in the security, tech and networking worlds are cynics, and for good reason. Meanwhile, the marketeers have flocked to use and abuse the Zero Trust terms because all the experts are saying Zero Trust helps mitigate against cyberattacks such as this one and the recent ransomware attacks, making this post seem even more suspicious. So…to address the three primary thoughts most of us have when reading a post like this:
Download a whitepaper to get into the nitty gritty details and read through some customer case studies.
Head over to our open source to try it for yourself.
For folks looking at the above, and thinking it looks complex, here is a video in which an engineer makes an app dark in about 15 minutes with zero infrastructure.
And, most importantly, find some way to close your firewall ports (even if it is a different way than the NetFoundry customers used to shield themselves from these attacks). There will always be CVEs. You don’t need to expose them to the world.