Researchers Discover Flaws In Five End-to-End Encrypted Cloud Services (scworld.com) 18
SC World reports:
Several major end-to-end encrypted cloud storage services contain cryptographic flaws that could lead to loss of confidentiality, file tampering, file injection and more, researchers from ETH Zurich said in a paper published this month.
The five cloud services studied offer end-to-end encryption (E2EE), intended to ensure files can not be read or edited by anyone other than the uploader, meaning not even the cloud storage provider can access the files. However, ETH Zurich researchers Jonas Hofmann and Kien Tuong Truong, who presented their findings at the ACM Conference on Computer and Communications Security (CCS) last week, found serious flaws in four out of the five services that could effectively bypass the security benefits provided by E2EE by enabling an attacker who managed to compromise a cloud server to access, tamper with or inject files.
The E2EE cloud storage services studied were Sync, pCloud, Seafile, Icedrive and Tresorit, which have a collective total of about 22 million users. Tresorit had the fewest vulnerabilities, which could enable some metadata tampering and use of non-authentic keys when sharing files. The other four services were found to have more severe flaws posing a greater risk to file confidentiality and integrity.
BleepingComputer reports that Sync is "fast-tracking fixes," while Seafile "promised to patch the protocol downgrade problem on a future upgrade." And SC World does note that all 10 of the tested exploits "would require the attacker to have already gained control of a server with the ability to read, modify and inject data.
"The authors wrote that they consider this to be a realistic threat model for E2EE services, as these services are meant to protect files even if such a compromise was to occur."
Thanks to Slashdot reader spatwei for sharing the article.
The five cloud services studied offer end-to-end encryption (E2EE), intended to ensure files can not be read or edited by anyone other than the uploader, meaning not even the cloud storage provider can access the files. However, ETH Zurich researchers Jonas Hofmann and Kien Tuong Truong, who presented their findings at the ACM Conference on Computer and Communications Security (CCS) last week, found serious flaws in four out of the five services that could effectively bypass the security benefits provided by E2EE by enabling an attacker who managed to compromise a cloud server to access, tamper with or inject files.
The E2EE cloud storage services studied were Sync, pCloud, Seafile, Icedrive and Tresorit, which have a collective total of about 22 million users. Tresorit had the fewest vulnerabilities, which could enable some metadata tampering and use of non-authentic keys when sharing files. The other four services were found to have more severe flaws posing a greater risk to file confidentiality and integrity.
BleepingComputer reports that Sync is "fast-tracking fixes," while Seafile "promised to patch the protocol downgrade problem on a future upgrade." And SC World does note that all 10 of the tested exploits "would require the attacker to have already gained control of a server with the ability to read, modify and inject data.
"The authors wrote that they consider this to be a realistic threat model for E2EE services, as these services are meant to protect files even if such a compromise was to occur."
Thanks to Slashdot reader spatwei for sharing the article.
Maybe do not trust cloud operators? (Score:2)
They have proven time and again that they are not trustworthy. This is just one more example. At the very least get the encryption from somebody else.
Re: (Score:3)
One of these companies is Canadian (sync), and another is UK (icedrive). Both countries have laws around mandatory logging and data retention. Given these are only exploitable locally, it's unlikely but plausible that it's deliberate in their cases. A backdoor, if you will.
Re: (Score:1)
One of these companies is Canadian (sync), and another is UK (icedrive). Both countries have laws around mandatory logging and data retention. Given these are only exploitable locally, it's unlikely but plausible that it's deliberate in their cases. A backdoor, if you will.
Mandatory logging and data retention? Why do I have a feeling those are functioning about as well as the “standard” end-to-end encryption..
Re:Maybe do not trust cloud operators? (Score:5, Insightful)
Only use cloud services where you do the encryption with your own tools on your end. Don't rely on their client.
That's why E2E cloud is worthless. If you don't control the client you can't trust it.
Re: (Score:3)
Exactly. State-sponsored attacks (may be your own state) and corporate greed will ensure a massive conflict of interest if the cloud providers themselves get to "secure" the cloud.
Re: (Score:2)
So you believe that on-prem systems *are* trustworthy? How many on-prem systems truly put the necessary money and effort to make their systems secure? Not many.
Cloud is not easier to compromise than on-prem systems, IF the on-prem system is connected to the internet. And just about all of them are.
I'd say, don't trust any system that is *connected to the internet.*
Re: (Score:2)
While I understand your sentiment, you can at least control your on-prem system. Cloud is just someone else's computer after all. This is not to say that there are not vulnerabilities in your on-prem system or the configuration itself but at least you have a better chance at trusting your own system. Obviously, if it is not *your* system but the corporation you work for, then you likely can't entirely trust that either but presumably your job is to do your best to secure that system.
Short of being a crypto-
Re: (Score:2)
Short of being a crypto-specialist yourself
THIS is the key shortcoming of your position. Noe one person is enough of a specialist in cyberattacks, to be able to defend "your own computer" against them. Most corporations that have on-prem systems, are unwilling to spend the money it would require, to maintain a sophisticated, knowledgeable security team.
At least if you are running the server, you know what's being locally logged and retained.
No, no you *don't* know. You know some things, but certainly not all. There are so many, many things that are or could be logged, you have no idea what is being logged and retained, just on your own c
Re: (Score:2)
On-prem systems are hardware and software made by someone, with moderate local expertise operating them.
Cloud systems are that but with highly expert teams.
But the cloud systems are also more complex, and does that cancel out the higher expertise?
They're also bigger targets, so does that cancel out the higher expertise?
They also have quite limited liability.
Their incentives don't overlap a lot with your incentives.
On the other hand, the truly massive cloud providers are probably so powerful that, if a gang
Re: (Score:2)
Short of being a crypto-specialist yourself
Let's be very careful about that statement. There are two kinds of 'crypto-experts'. Yes, designing a new method of encryption is very difficult and requires deep math skills. But taking a well documented and robust method that someone else has designed is a programming task like any other. Yes you need to know the ins and outs of the library and the pitfalls. But they are all there are documented so it is not rocket science to avoid them and it's no more difficult than developing a website with authen
Re: (Score:2)
If I had to trust a physical system more than someone else's system where I don't know where it is, what it is, or anything about it, I'll trust a physical system. At least I know that there is a good chance the encryption I use is good enough. For example, backups with Borg Backup, I know will take a lot more for an attacker to compromise than just slinging data directly to a cloud provider.
Yes, a nation-state can get around everything, but one could say the same thing about a professional burglar and no
Re: (Score:3)
I have two trusts of cloud provider encryption:
1: Encryption is used somewhere, so I can check a box off come audits. This could mean that the cloud service has the S3 target on an encrypted disk array.
2: Actual encryption. If I have something that needs actual protection, and not legal eagle checkboxes, I pack my own parachute and use something like Cryptomator or something similar and do the encryption locally with a separate client. Same with backups, where I always turn on encryption, just for peac
More likely than being hacked (Score:1)
Fshy feeling about pcloud from the start (Score:1)
Did NSA help design the protocols (Score:2)
Flaws???? (Score:3)
The word "flaw" implies "unintended", and I think we all know that's just not the case.
The promises of end-to-end encryption and data safety are worth about as much as the time it took the company to tell some AI to draft them.