Knowing a repository ID(repid), domain name and having a valid cloud account, it is possible to delete any sync set definitions on the cloud preventing other users to synchronize.
How to reproduce?
1) Imagine 2 on premisses instances A and B managed by 2 distinct clients. Lets say client A on instance A and client B on instance B.
2) Client B for one reason or another got the repository id of client A) (lets say B got the permission to connect to A using CMIS: curl -uphil:phil "http://<server A>:8080/alfresco/s/cmis" | grep repositoryId Lets assume it returns 8d416a7c-4686-42c1-a11e-68ef54a77f46)
3) Lets say that B) has an account that he can use to log in the same tenant as A on the cloud (Not sure it is compulsory)
4) B) logs in server B) and get a valid ticket with a user that has valid cloud account. Ex: curl -v "http://localhost:8080/alfresco/service/api/login?u=phil&pw=phil" → a valid ticket is returned TICKET_408857bd10eaeae27625335ac2d41c83e264006d
5) B) has installed the attached module and continuously calls : curl "http://<server B>:8080/alfresco/service/ssd/hackssd?alf_ticket=TICKET_408857bd10eaeae27625335ac2d41c83e264006d&network=alfresco.com&repoid=8d416a7c-4686-42c1-a11e-68ef54a77f46"
Note: in the above call it is the repo id of A
6) A cloud user must now add something or modify something on a folder that is synchronized with server A) Assume it is FOLDER_A
The calls continuously made on step 5) should return a line similar to the line here under indicating that the ssd was deleted in the cloud breaking cloud synchronization:
The malicious code is in HackSsd.java in the attached eclipse project.
The problem comes from the fact that
cloudSyncSetDefinitionTransport.pullChangedSSDs(repoID); can be called without specifying a repo id that is the actual repo id of the caller. Also for pullChangedSSDs(repoID) there should be something less easy to steal than just the repo id.
Another problem is that cloudSyncSetDefinitionTransport.deleteSSD(ssdId, tenantId); can be called even if ssd was not created from the repo that created it.
Those ssd entities should be sealed/signed using something less easy an public than repoid in order to prevent that type of attack and if the attacker does not have the signature then deletion is forbidden.