Atlassian announces 0-day hole in Confluence Server – update soon!
Credit to Author: Paul Ducklin| Date: Fri, 03 Jun 2022 16:59:18 +0000
Software development and colloboration toolkit behemoth Atlassian is warning of a dangerous zero-day in its collaboration software.
There’s no alert about the bug visible on the company’s main web page, which features the company’s best-known tools JIRA (an IT ticketing system) and Trello (a discussion board), but you’ll find Confluence Security Advisory 2022-06-02 on the Confluence sub-site.
The official bug number is CVE-2022-26134.
The existence of the bug was outed by US threat response company Volexity, which claims to have uncovered the vulnerability while investigating an in-the-wild incident that “included JSP webshells being written to disk”.
Webshells revisited
You’ll remember webshells, no doubt, because they were all over the news just over a year ago during the so-called Hafnium attacks, allegedly conducted by Chinese hackers against Microsoft Exchange servers in March 2021.
Webshells are a nasty way of opening up a backdoor into a network using an attack that sometimes requires attackers to do little more than write one tiny file into part of a web server where content is stored.
In the 1990s, hackers with write access to your website would probably have got their kicks out of adding flaming skulls to your home page, and of drawing immediate public attention to the fact that they’d broken in.
But by adding a web page that includes what’s called a server-side script, today’s attackers can give themselves a secret way into your network without drawing attention to themselves at all.
That’s because a lot of web servers don’t just contain static files that get sent out to remote users when they put in the right URL.
Instead, web servers often rely on files that, when requested by a user, are executed as a program by a scripting engine inside the web server, and used to generate the actual content that gets sent back.
If that sounds dangerous, it is, although it’s generally considered a feature, not a bug.
Indeed, server-side scripting is the background to technologies such as Microsoft’s ASP (active server pages – the name says it all!) and Java’s JSP (Jakarta Server Pages).
As Wikipedia puts it:
JSP […] is a collection of technologies that helps software developers create dynamically generated web pages based on HTML [and] other document types.
Webshells can be as simple as one line of code that does a three-step process like this:
--> Extract text from the URL or the body of the incoming web request --> Run the extracted text itself as a script --> Send the output of the rogue script back as the reply
The webshell doesn’t even need to contain any specific malware code of its own that might stand out.
As long as the attacker can control (or even simply guess) the name of the webshell file they’ve implanted, then they can simply visit the server URL that corresponds to that file, any time they like…
…and upload new malware code for immediate execution every time.
Of course, this sort of “run anything you want any time” does tend to leave behind traces that an attacker can’t easily control and that a threat hunter can look out for, such as unexpected error messages, unusual network connections, or non-web-related processes showing up on a web server.
But those artefacts only show up as a side-effect of malicious activity that’s already happened, so the attackers have the upper hand until someone notices something.
What happened?
As you can imagine, Atlassian isn’t giving away any specific information about the bug at this point, given that it’s still working on a fix.
Fortunately, even though Volexity decided to blog about this security hole publicly rather than disclosing it privately to Atlassian and giving the company a few days to fix it quietly, both parties seem to have kept enough details under wraps that we aren’t aware of any “here’s how you do it, folks!” sample code floating around at the moment.
Atlassian is advising customers who can pre-filter incoming web data to look out for URLs containing ${
, saying that blocking these “may reduce your risk”.
That makes this bug sound a bit like the infamous Log4Shell hole from the end of 2021, where text that was logged didn’t actually get logged literally if it contained special commands bracketed in ${....}
characters.
If you’ve ever used the Bash shell, you’ll be familiar with this sort of “metacommand”. In Bash, the magic brackets are round, not squiggly, so that the text $(runthis)
doesn’t get used exactly as it’s written, but instead gets replaced with the output generated by executing the runthis
command, which is a very different and much more dangerous thing indeed.
We’re therefore guessing that this exploit is triggered by the way that Atlassian’s code processes the “query” part of URLs that don’t just have a servername and a filename, but are followed by some sort of query string, typically preceded by a question mark.
Interestingly, the characters {
and }
aren’t actually allowed to appear in URLs, and are supposed to be transmitted as special “escape codes” in hexadecimal instead, thus appearing as %7B
and %7D
respectively.
Whether this bug depends on rogue URL characters that were sent without being escaped, or whether you should be checking for ${
after the URL has been “unescaped” by your web server isn’t clear.
So, if you are going to add a temporary URL filter, we’d suggest looking out for the {
character in both its raw and escaped forms, just in case.
What to do?
Atlassian has dubbed this bug Critical, and has said it will have a patch out at an “estimated time [of] EOD June 3 PDT”, which is a reassuring yet vague and tautological at the same time.
(The phrase EOD is unspecific in its own right, and doesn’t really need the word “estimated” to accompany it.)
Remember that EOD stands for end-of-day, and thus could be as late as one minute to midnight.
And 2022-06-03T23:59 UTC-7
(where PDT is short for Pacific Daylight Time, as used in June on the West coast of the US) is 2022-06-04T06:59 Zulu
time, which is just shy of 8am on Saturday in the UK, and 9am in Western Europe.
In other words, be prepared to stay up late, or to get up early, because you will want to grab the patch as soon as you can.
That’s because we’re assuming that the patch is likely to reveal the nature of the attack and how to exploit it, and thus that proof-of-concept files and actual attacks will soon follow.
In the meantime:
- Take your Confluence servers offline temporarily if that’s an option.
- Block open access to your servers directly from the internet if you can.
- Consider blocking URLs with
${
in them if you have a quick way to add a basic filter.
Not enough time or staff to keep on top of cybersecurity?
Unsure where to start when you spot suspicious activity?
Learn more about Sophos Managed Threat Response:
Sophos MTR – Expert Led Response ▶
24/7 threat hunting, detection, and response ▶