AV Alert for WebShell Backdoor, possible RCE Security Vulnerability?

[K. Scheel]

Hi, we recently performed a full Anti Virus scan on the Windows Server VM that hosts our Jira instance and got one hit:

Threat Detected: Backdoor:Java/WebShell!MSR and Removed!
Action: Remove, Result: 0x00000000
file://[REDACTED]\JIRA-8.22.0-back.zip->JIRA/work/Catalina/localhost/ROOT/multPartReq31531.tmp
SigSeq: 0x00002667E42E32EC

While the detected file was located in a backup archive, the files currently present under .../JIRA/work/Catalina/localhost/ROOT/ seem extremely suspicious and contain code. We fear that a Remote Code Execution (RCE) exploit was attempted.

According to this Knowledge Base article, these multPartReq files can be created by anyone attempting to add add an attachment to an incorrect URL?

Isn't this possibility to create files on the server already a security vulnerability? Paired with other bugs this could lead to RCE?

The one important question we have is:
Are there any known past or present security vulnerabilities, that could lead to the execution of code contained in those multPartReq files?

Concerned regards

[Zul NS _Atlassian_]

Hi there

We've updated Jira recently to manage the unwanted files with https://jira.atlassian.com/browse/JRASERVER-75331

I've also updated the related KB article with this.

[K. Scheel]

thanks! The bug ticket states that no RCE is possible:

However An attacker cannot control the filename or its location, which prevents the possibility of RCE.

This implies that RCE would be possible, if the filename was known to an attacker? The multPartReq files on our Jira instance have a random part consisting of 3 to 5 digits (e.g. "multPartReq59811.tmp"). The digits don’t appear to be completely random, some filenames have numbers in sequential order.

I'm not sure if it is really safe to assume, that this 5 digit number cannot be guessed or bruteforced by an attacker... Are there any protections in place, that would hinder an attacker who's trying to guess the filename?

Kind regards

[Tim Eddelbüttel]

Hello,

just adding my 2 cent here, last year a customers AV team reported me also a weird file on a Jira hosts and asked some questions.

Looking at the file content it self (https://gist.github.com/sente/4dbb2b7bdda2647ba80b), it was in my case a PHP script which doesn't makes sense when you would try to attack a Java application running on Tomcat.

When I read PHP and vulnerable, then I think always Wordpress. I did some research and found https://nvd.nist.gov/vuln/detail/CVE-2020-25213. With this sample code (https://github.com/mansoorr123/wp-file-manager-CVE-2020-25213 ), I would be able to always reproduce the problem.

I also did some testing if this is specific to the Tomcat (version / configuration) bundled by Atlassian or if this is a Tomcat problem itself. I was also able to reproduce this in a default Tomcat running in Docker.

So for me, it's a Tomcat issue independently of Jira, but I have no idea why it behaves like that.

Kind Regards,
Tim

[Nic Brough -Adaptavist-]

Atlassian stuff doesn't use PHP, so you are into the wild realms of someone having injected something on to your server somehow.

It's nothing to do with your Atlassian install, something else has made its way on to your server.

[K. Scheel]

@ Tim: huh, interesting, thanks for your reply. To be honest, this is a little out of my league and I don't really have the time to try and reproduce these things.

@ Nic: Well, it is the Atlassian install that allowed the upload of Tim's PHP script. But the execution of that script is probably not possible with the tomcat webserver used by Jira I guess... Maybe this was just some bot trying random exploits on publicly reachable webservers. I think this is also what happened to our Jira instance. We're now trying to figure out if an attacker might have been successful in the past...

Cheers!