How to wipe-out any Confluence Server instance (accident or attack)

[#1]

Yes. It is possible. No backend access needed. You can wipe your instance by accident, but it is also possible to use this UX/UI flaw as an attack at your competitor. So. Be careful about lines below. In this article I will explain what is wrong, how you can prevent yourself from being a victim and what should Atlassian do to fix this. 

Yes, I reported this as a bug, but Atlassian consider this as suggestion, so, if you agree with me, please leave your vote and comment at: https://jira.atlassian.com/browse/CONFSERVER-59730

I also notified security@atlassian.com but without any response. 

So, whats going on?

Well, there are two scenarios. Accident and bad guy. I will explain both of them below, but the result is the same: Confluence data, users, configurations are wiped out. Both scenarios count with https://confluence.yoursite.com/admin/backup.action used for the import, as only here you can import the zip files. 

The accident scenario

You are the Confluence administrator trying to migrate content from Cloud to Server, where the target instance is not empty. You are exporting space per space, as migration of all spaces is not possible. So, Cloud Confluence will generate you a bunch of “confluence-export.zip” files. Well. But you also have a full site Cloud Confluence export in your downloads. Which is named - yes, you are guessing right “confluence-export.zip”.

When you, as administrator, try to import those “confluence-export.zip” files containing spaces, everything is fine. Spaces are imported and users can use them. But when you accidentally select “confluence-export.zip” with site export, guess what will happen? Nothing. Literary nothing. You will select site export, hit the import button and Confluence Server will start import. This will import the Cloud Site Export, but before that, whole Confluence will be wiped, including users, data and configurations. No warning. No question “Are you sure, that you really want to wipe your Confluence?”. Nothing. 

But thats not the worse case.

The bad guy scenario

Imagine, you would like to, for whatever reason, attack someone Confluence Server. There is nothing easier, that opt-in for Confluence Cloud trial and then do a site export of empty Confluence. 

Now, you just have to choose a target. Name the file like “business_tender_proposal.zip” and sent it to the target with a comment “Hello. Here is the potential business offer from us in exported Confluence Space”. What will happen next? Receiver will ask their Confluence Admin to import that space, he will import that space and without any warning, Confluence is gone. 

What should Atlassian do?

1. Verify if you are importing space or site
2. If you are importing site, show the warning, that you are about to wipe your instance
3. Put some naming conventions to Confluence export so they wont have same name for space and site
4. Pay more attention for customer trying to point to the risks

What should every admin do?

Before importing anything into Confluence Server, unpack the file provided to you. It is the zip file and it will contain exportDescriptor.properties file. Open it in text editor. There is attribute exportType. If it's equal to space, everything is ok and you can import it. If it's equal to site, this zip will wipe out your Confluence when trying to import.

I do not write those lines to harm anyone. I was just an accidental victim. And I don't want to anyone else burn his fingers. 

EDIT:

The link to Atlassian backlog is not available anymore, as it was reconsidered as security bug! Thanks everyone for pushing about that. We made it. 

[Maurice Pasman]

Typical Atlassian downplaying. I have been reporting bugs in the new editor for months, only to see them being added as feature suggestions for future consideration.

[Jan-Peter Rusch]

SCNR, Atlassian wants nobody to migrate from Cloud to Server. Why should they care? If there are any bugs the other way around, they would have been fixed in a matter of hours...

[Maurice Pasman]

@Jan-Peter Rusch Well then they should pay more attention to the current vibe of negativity that is going through the community of Cloud users. I have a few hundred clients that use Confluence, a lot of them have migrated "back" to on-prem the last 6 months, for performance reasons.

[Tomáš Vrabec _ServoData_]

@Jan-Peter Rusch Maurice is correct. Every growing company who tries Cloud going back to Server. I migrated, in total, about 25k users from Cloud to Server. Performance was not main reason - but customization, integration and security. 

[Jan-Peter Rusch]

You're all right, but Atlassian focuses on Cloud First customers, then DataCenter and then Server. So don't expect them to fix server problems or issues fast unless the bug is really a security concern. I don't see this on your bug, because you need to be at least a Confluence admin. The import page clearly states that a database backup is a good idea. Still another check before wiping out / overwriting a whole instance would be appreciated...

[Tomáš Vrabec]

Good news everyone! Suggestion was reconsidered as security bug! Hopefully this will be fixed in near future!

[Moin]

Great.... I like the suggestion what Atlassain can do. Hope atlassian will address this soon.

Between Tomas can you please help me to get the access of Bug ticket ?

[Tomáš Vrabec]

Hello @Moin 

unfortunately this is not possible, since the suggestion were reconsidered as security bug. 

You can still raise a new ticket within Atlassian support a put there a link for CONFSERVER-59730 and / or this article :-)

Hope this helps.

If I will receive any further informations about this issue, I will update this article as well. 

Cheers, Tom