Tomcat Manager in Confluence

[Daniel Call]

I want to remove (or just disable) one of the apps on the build in tomcat 9 web server (called webcart).

Should I be enabling tomcat manager to do this, is is there a better way?

[Nic Brough -Adaptavist-]

Confluence generally is not run with other applications in Tomcat - in theory, it can, but the standard installers won't set up Tomcat with anything that enables it, you have to do quite a bit of work to get it to work (ok, unless you're on a very old, unsupported version of Confluence based on the WAR/EAR distribution)

So the answer to this question becomes "how are you enabling these apps?"

[Daniel Call]

Hi Nic,

Many thanks for your response.
As far as I'm aware no-one is enabling any additional apps on the Tomcat web server. We're running a vanilla VM with Windows 2016 datacenter which is hosting our install of Confluence (in a default self hosted install) and that's it.

We use the Nessus vulnerability scanner on all the web servers and it's flagging that a "webcart" app is installed with publicly visible folders on this web server but I can't find where this app or folders are, this is why I wanted to have a look in Tomcat manager to try and find it.

FYI, this is the error - https://www.tenable.com/plugins/nessus/10298

Daniel

[Nic Brough -Adaptavist-]

That would be quite interesting - the webcart thing is not part of Confluence and not installed with it, so either Nessus is mis-reporting, or someone has added it to your Tomcat for some reason (and then hidden it somehow by renaming things!)

My instinct is that Nessus is probably firing a false positive.

[Daniel Call]

Ok I have an update on the cause, after spending a bit of time looking into this,

I looks like confluence is responding with a 200 OK for URL's that shouldn't exist, which Nessus is taking as an assumption that webcart is installed.

So there is definitely nothing installed on the web server that shouldn't be there, but in order to prevent this false positive I need to make the web server not respond with a 404 for non-existent pages if that makes sense.

As an example, if I go to https://myconfluencesite.com/somerandomtext it should show a 404 but it's directing to https://myconfluencesite.com/#all-updates which is a real page

[Nic Brough -Adaptavist-]

Mmm, ok, it's supposed to redirect people to the application when they land on a duff url.  This is built into Confluence, you'd need to strip out the code that does it.

[Daniel Eads]

Hey Daniel,

I've tested this against the most recent Confluence release as well as an older Confluence 6.6 install. The behavior I'm seeing is this:

• confluence.domain/gibberish returns a 404 response code with a "Page not found" page in the application
• confluence.domain/#gibberish returns a 200 and drops you on the dashboard
• confluence.domain/#webcart/orders returns a 200 and drops you on the dashboard

The hashes are used to inform the dashboard which type of activity to show you in recent versions of Confluence.

What version are you running? I am wondering if the behavior might be different on really old versions (such as 5.x) and this is leading to the behavior you're seeing.

If the primary concern is getting that particular vulnerability scan to pass (instead of just dismissing it in your scanner), you could also consider having a reverse proxy like Apache or IIS sit in front of Confluence if you don't already. The reverse proxy could have a match for the particular URL the scanner is looking for and manually return a 404 before the request makes it to Confluence. Kind of hacky, but as this is clearly a false positive, I don't believe this would water down your security.

Cheers,
Daniel

[Daniel Call]

Hi Dan,

We're running version 6.14.2

So after checking this myself I can see that: https://kb.themindgym.com/gibberish/#webcart returns the same page as https://kb.themindgym.com/#webcart

In fact I can write anything before or after the # and it still redirects to the all updates page.

Yes, my objective here is to get the Nessus scan to pass as this has been flagged up several times and they want it to show green.  I realise this is not a real vulnerability but it's still flagging up on the monthly reports.

I will look into the possibility of using a proxy, but other than that, is there anything I can change in confluence config to get round this?

Thanks

Daniel

[Daniel Eads]

I'm not aware of any configurations that would change this behavior unfortunately! If you aren't currently behind a proxy, there's also the possibility of using Tomcat itself (the Java application server that serves Confluence) to block those particular pages. I mention this only as a technical possibility - I would definitely not recommend trying to do this in practice because the rules can get dicey and cause unintended breakages.

Looks like (at least according to Tenable's forum) you might have a couple options in re-casting the risk or accepting the risk available as well.

Edit: after reading the vulnerability listing you posted earlier again, I think you might also want to consider contacting Tenable's customer support to see if they'll update their match rules against the false positive.