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.
Atlassian originally advised customers to try filtering URLs containing ${, saying that blocking these might “reduce your risk”, though it has now officially withdrawn that suggestion. (See below.)
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.
What to do?
Atlassian dubbed this bug Critical, and said it would have a patch out at an “estimated time [of] EOD June 3 PDT”, which was a reassuring yet vague and tautological at the same time.
(The phrase EOD was unspecific in its own right, and didn’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 on the West coast of the US during summer) is 2022-06-04T06:59 Zulu time, which was just shy of 8am on Saturday in the UK, and 9am in Western Europe.
Update. Atlassian’s patches are out. All officially supported Confluence Server and Data Center version are affected, and patches have apparently been released for all of these, including versions 7.4.17, 7.13.7, 7.14.3, 7.15.2, 7.16.4, 7.17.4 and 7.18.1. The company has also explained how to carry out a manual “fix” by updating specific Java files yourself if your organisation still has a sluggish process for authorising proper updates. You need to delete two buggy .jar (Java Archive) files and replace them with newer versions, and add one new .class (compiled Java module) file. [Added 2022-06-06T16:00Z.]
Recommended actions include:
- Patch right away if you can. A formal update is the best choice.
- Apply Atlassian’s manual fix if you can’t. This is the second-best choice.
- Take your Confluence servers offline temporarily, if possible, until you have installed the patch.
- Block open access to your servers directly from the internet if you can.
Note that Atlassian originally suggested a workaround involving blocking incoming URLs that contained the special character sequence ${, assuming that you had a quick and effective way to add a basic filter of this sort.
However, the company has now officially withdrawn this advice, presumably because a proper fix has now been published. (We suspect that a blanket network traffic filter for ${ would be prone not only to missing actual attacks but also to blocking legitimate data, thus producing both false negatives and false positives.)
In short, and as always: Patch early, patch often!
Not enough time or staff?
Learn more about Sophos Managed Detection and Response:
24/7 threat hunting, detection, and response ▶