Mitigation for Confluence vulnerability CVE-2019-3395
Asked by Toshio Kikuchi:

Hi all,

Recently Atlassian has announced a critical Confluence vulnerability.  
<https://confluence.atlassian.com/doc/confluence-security-advisory-2019-03-20-966660264.html>

Of course the best way to fix the issue should be updating Confluence to the fixed version.  
However, currently we don't have enough time to thoroughly test our custom plugins with the new version.  

And Atlassian's mitigation plan to disable WebDAV plugin may not be acceptable, as we regularly use the Office Connector feature.

Hence we started to find another mitigation, and are wondering if the following would work or not. The idea is, as we are running Confluence behind a Apache reverse proxy, we added the followings to the Apache settings.

RewriteEngine On  
RewriteCond %{REQUEST_URI} \^/confluence/.\*$  
RewriteCond %{REQUEST_METHOD} \^(PROPFIND\|PROPPATCH\|MKCOL\|COPY\|MOVE\|LOCK\|UNLOCK)  
RewriteRule .\* - \[R=405,L\]

This simply blocks all the WebDAV methods and returns a Method Not Allowed error.

Hope to hear from you if our approach looks good or not.

BR,

Toshio


Answers:
author: sara
body: Will disable all below.

viewpdf  
viewxls  
viewppt  
viewdoc  
viewfile


author: sara
body: Hope you are aware that webdav disabling will affect office connector and related features.

comments: author: Toshio Kikuchi
body: Thanks Sarath,

Of course we know - our understanding is that disabling WebDAV plugin gives heavier impact to Office Connector features than blocking WebDAV protocols only.


author: Diego
body: Hello there Toshio! Thanks for taking your time to read our advisory and taking action to fix it. Your settings can help the issue but will not fix all the aspects of the exploit.

For example:
> * The proxy can still be bypassed
> * Someone with malicious intent that has internal access can still use the exploit
> * Blocking the features with the proxy for all users does not seem to be an option
> * You may fail a security audit if there is one because the exploit is still present

As you have noted, the correct fix for the situation is to upgrade the system. With this in mind, I would like to know:

1. Which version of Confluence are you running?

Remember, if you plan to upgrade your instance soon, first try the upgrade on a test instance. Ideally, this test instance is an exact replica of your current production instance.

This can help us to determine the best approach for your case. Looking forward to your reply!

comments: author: Toshio Kikuchi
body: Hi Diego,  

Thank you for your comments.  

Could you explain what you mean by the item #3 "Blocking the feature with the proxy for all users does not seem to be the option"?

For the rest of the items, I do understand your concerns.  
Our mitigation plan may not be perfect, but still is much better than leaving the vulnerability as-is. There are very limited number of users who can bypass the proxy or are having internal access to the Conf servers.

Our current version is 6.6.4 - we know you have 6.6.12 but we still have certain concerns for compatibility with our custom plugins. We will work on planning to update our Confluence in the near future.

Regards,

Toshio


author: Diego
body: Hello there!

Sure. When I said that I tried to convey the idea of "blocking all calls, no matter where they came from". Which would effectively keep users from using the features needed.

A good idea for testing your upgrade, is to create a Test Instance. This instance must be an exact replica of your production.

Having a clone of your production can help you understand how the upgrade will happen and also to test your plugins after upgrading the instance.

Let us know if there is anything else we could help you with!


author: Toshio Kikuchi
body: Hello Diego,

Thanks for your update.

Humm... I suppose that our proxy is blocking all WebDAV calls no matter where they come from, except for very few admin users who have direct access to our backend servers. Are you pointing out that such exceptions do exist?

Or if you wanted to tell us that someone else can also bypass our blocking rules , please let me know.

Regards,

Toshio


author: Daniel Eads
body: A concern might be that any machine in any part of your network that had WebDAV access could be used as an attack vector. A non-privileged attacker could still exploit a vulnerable Confluence instance from the part of your network that still had WebDAV access.

While I definitely appreciate your efforts in trying to come up with an alternate mitigation strategy, really the best thing to do is upgrade. I would encourage you to use the mitigation effort toward testing an upgrade to **6.6.13**. The enterprise releases have few changes outside of security/bugfix patches, so it's very likely that your custom plugins will not need any changes. I would also suggest that temporarily disabling the WebDAV plugin (and inconveniencing the users that rely on the Office Connector unfortunately) while you test your plugins is better than potentially having a security incident.

I hope that's not too direct - we're happy to help with questions but we can't thoroughly test the workaround you've looked at, so we can't conclude that it would be a safe mitigation strategy.

All the best,  
Daniel


Tags: atl-confsec

confluence-server

server