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
Will disable all below.
viewpdf
viewxls
viewppt
viewdoc
viewfile
Hope you are aware that webdav disabling will affect office connector and related features.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Atlassian Government Cloud has achieved FedRAMP Authorization at the Moderate level! Join our webinar to learn how you can accelerate mission success and move work forward faster in cloud, all while ensuring your critical data is secure.
Register NowOnline forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.