Resolving ransomware issues with ransomware protection

[pmaier1]

We recently launched the Ransomware Protection App (https://marketplace.owncloud.com/apps/ransomware_protection) which keeps users safe from ransomware attacks by providing different means from blocking current ransomware to offering smart rollback for more sophisticated attacks.

Regarding blocking ransomware attacks I thought about the flow for resolving the issues.

Exemplary current flow from user perspective 1a) Ransomware attack occurs, encrypts files in the sync dir, renames them and adds the file extension ".crypt". or 1b) Ransomware attack occurs, deletes original files and adds the file extension ".crypt" to an encrypted copy. 2) Client starts uploading the encrypted files 3) Ransomware Protection chimes in and blocks the upload as it detects the pattern ".crypt". Depending on the configuration the WebDAV API can additionally be set to read-only ("account locking"). 4) Now the user is in a situation where he locally has encrypted files in the sync folder but in ownCloud the original files are preserved. Actually it should be recommended to do a full cleanup of the whole PC and resync the original files. But (assuming ransomware has been removed while system stays in operation) as a user you might be tempted to just delete the encrypted files locally and expect the client to pull the original files from ownCloud. Instead what's happening when you delete the local, encrypted file (e,g, file.txt.crypt) the original file (e.g. file.txt) is deleted on the server. Probably this is only the case for 1a) as with 1b) you really have new files.

As the client could take note of the rename (which is not sent to the server because of the blocking mechanism) I think we could maybe prevent deleting the original file on the server and instead sync the original file to resolve the issues.

What do you think?

@michaelstingl

[pmaier1]

@SamuAlfageme Can you check this one? Is it feasible? Let's call quickly then I can explain :)

[ckamm]

@pmaier1 Yes, it does sound like removing the file locally would trigger a remote deletion once the account becomes unlocked. I don't think there's a good way of preventing that without adjusting client code.

One could bump all etags on the server which would prevent any local deletions from being propagated upwards. But it also might cause spurious conflicts and lots of downloads (for servers/clients that don't have checksums). @ogoffart, maybe there's something one could do relating to the fingerprint/restore backup code?

[ogoffart]

if all files are replaced by the ransomware, then the client should show the "everything changed" warning. (actually, this would need to be tested, maybe some directories prevent this to happen)

(1a and 1b are the same, as far as the sync logic is concerned)

@ckamm the backup restoration trick currently works the other way. If the fingerprint change, the client will simply keep conflict files in case of changes from the server. but that won't help in this case.

[pmaier1]

Thanks for your investigation. Would be nice to find a solution on this but I don't regard it as very important as the user should anyway do a clean reinstall of the system and resync after such an attack has occurred.