Improper Authorization Vulnerability In Atlassian Confluence

Why this exploit was so dangerous

Noted initially on Tuesday, 31 October, details of the incident CVE-2023-22518 - Improper Authorization Vulnerability In Confluence Data Center and Server were very sparse at the time. It was a severe issue with a severity of 9.1 (but with only destructive capability noted). The best path to mitigation was to ensure a solid backup strategy and remove your instance from the internet if you couldn't update to a patched version, which was available immediately.

At this point, we assume the internal discussion was much like ours at Eficode. We thought that something like an injection of SQL commands to drop the database would have been at play. Regardless, we quietly patched, notified our customers, and moved on.

Atlassian’s reassurance that code execution and data exfiltration were impossible was likely a contributing factor to the danger. However, whether they were clear on how the vulnerability would evolve is unknown.

Initial communication and mitigation plans being misleading

Acting quickly turned out to be the saving grace at Eficode. Vendors choose one of two ways to distribute information. They either tell their partners first, allowing a quiet wave of patching to occur before details of the exploit become public, or they open up to everyone to ensure that data is available immediately.

In this second instance, a race triggers between security teams trying to patch and threat actors trying to exploit. However, this case being marked as a lower severity initially gave that breathing room. It was destructive and not exploitative.

But by the end of the week, the severity of the exploit had been increased to 10.0, and Remote Code Execution had been developed as proof-of-concepts. As of writing this, weaponized exploits are readily available on GitHub.

Several days after the first PoCs appeared, we received news of Ransomware attacks.

By the time these things occurred, Eficode's instances were already patched.

Lacking baseline security measures

Ransomware, of course, is heavily dependent on a company's lack of effective security measures. In this case, backups. A robust backup solution is the key to resolving ransomware attacks quickly and efficiently.

In Cybersecurity, we have a term: Cybersecurity fatigue. This is an employee's weariness with the measures required to provide a secure platform, and it's this very phenomenon that leads to situations where backups are not in place, where firewalls are not implemented, and where sensitive resources are publicly accessible.

As security threats and responding to them continue to grow, fatigue will grow alongside them, and this is starkly visible in DevOps, where teams are often makeshift groups of coders and infrastructure specialists with no clearly defined security policies.

Unrecoverable loss of data is the fastest route to insolvency of a company to date. More and more companies are trying to dance around facts and failing to acknowledge that they're now IT companies alongside whatever else they used to be.

One of the ways around this is, of course, to use a Managed Service provider like Eficode who runs these platforms for hundreds of companies, covering services like Jira, Confluence, Bitbucket, GitLab, GitHub, Jenkins, and other hosted DevOps applications.

How instances are discovered

One of the initial mitigation points for this vulnerability was simple: Remove it from the public internet. This is always a great way to reduce attack surface, but it assumes you can always trust every employee in your company.

Because of this potential for internal attack, as well as company profiles, it's easy to think such attacks are targeted. This is, for the most part, untrue. They're simple attacks of convenience. Tools such as Shodan.io exist as search engines, not for information, but for machines connected to the internet.

Searching for:

Confluence "country:fi"

shows several hundred open Confluence instances on the public internet in Finland alone. Without the filter, we get tens of thousands.

How to exploit

Exploiting the issue turned out to be extremely simple: Making a single HTTP POST request to the following endpoint:

/json/setup-restore.action

with the following header specified:

"X-Atlassian-Token": "no-check",

Confluence administrators use this endpoint to restore the site from a compressed backup, which is uploaded in the data of the request. Typically, an administrative endpoint is protected by some form of authentication measure. However, in affected versions, no such security measure is in place.

Simply injecting a compromised Confluence backup containing malicious plugins like the Web Shell Plugin, commonly seen during this attack, completes this attack.

How to mitigate

Several steps for mitigating exist. Updating to a new version is the surefire way. In cases where that is not possible, removing the instance from the public internet is a good attack surface reduction, if not mitigation.

Blocking the following URLs at the network level also stops the exploit based on current

/json/setup-restore.action
/json/setup-restore-local.action
/json/setup-restore-progress.action

But the safest way to operate is simply to patch to the latest fixed version.

What's next for me as a user?

Assuming you have patched to a fixed version, your Confluence instance should be safe. Keeping apprised of Atlassian security notifications can be achieved. Similar feeds can be found for most DevOps tools.

But if you find your teams are suffering from Cybersecurity fatigue, you can also look for a Managed Services vendor who will handle these things, freeing your developers up to do what they do best and code awesome things.

What's next for security?

This vulnerability shows a problem in the Cyberworld, revealed in a single easy question: What do this exploit and Log4Shell have in common?

They both have a severity of 10.0.

And yet Log4Shell grounded the internet to a halt for several weeks while this exploit is relatively well in hand. What's the difference?

It turns out that the most common Cybersecurity metric for measuring incidents, the CVSS (Common Vulnerability Scoring System), only measures one thing: Impact per system.

We have no way of measuring how widespread an attack is, and while our only significant metric is how bad an exploit can be if it's active on the system, we're going to run into confusing cases like this one, where 10.0 severity affects some Confluence installations number in the thousands, while Log4j was installed in millions of systems.

Cybersecurity should look into the development of metrics for coverage and impact to go alongside the CVSS score to make these incidents (and their impact) clearer.

Atlassian Data Center Security with Eficode ROOT

As we wrap up, it's worth mentioning how Eficode ROOT can make your life easier in these tricky cybersecurity times. Think of it as having a dedicated team always on top of things like the CVE-2023-22518 patch. They handle the security updates smoothly and quickly as part of what they do every day. This means you can focus on your main work, knowing that the security side of things is handled without extra stress or effort.