Researchers Discover Flaws In Five End-to-End Encrypted Cloud Services (scworld.com) 33
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:3)
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.
Maybe do not trust clouds. (Score:1)
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.
Quite frankly, it would be harder to trust the people you hire at a cloud provider. Particularly those with advanced access to support their job.
The possibility of simply buying an insider threat, increases considerably when the pile of data is THAT big. And data clouds aren’t exactly getting smaller.
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:3)
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)
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?
No, it certainly doesn't cancel out the higher expertise. There is a 10x difference between that expertise and "yours and mine".
Also, cloud systems enable types of security you literally cannot achieve on your on-prem or local system. For example, cloud systems enable managed identities , such that there are NO passwords at all, so there are no passwords to leak, completely eliminating the possibility of a phishing attack.
Also, the defaults for configuring clous servers are set to be the most secure options
Re: (Score:2)
I appreciate the comment, I do want to though remember that there is a shared responsibility model, so isn't quite so easy to say it's all about their expertise
Re: (Score:2)
Yes indeed the responsibility is shared. As a cloud customer, you can certainly configure your systems to be insecure. But you have to work a lot harder to do so, than with on-prem systems.
Also, in the security arms race, cloud systems are proactive in hounding you to change your less-secure settings. For example, I've recently started getting notifications that my Azure web site will stop allowing TLS 1.0 and 1.1 as of a specific date. Microsoft is going to disable these whether I like it or not. On-prem,
Re: (Score:2)
I can audit the on-prem systems. I can choose who I trust to do that auditing. I can insist on open source compiled in-house so that it has been fully audited.
None of that is a possibility with cloud based services. All you can get there is "Relax! TRUST me!" as told by a sales droid who has no way of knowing him/herself.
Re: (Score:3)
None of that is a possibility with cloud based services
If that's what you think, I don't think you've actually used cloud systems. You certainly can audit your cloud systems, in more ways than you can on-prem. You can choose who does it. You can insist on open source compiled in-house. (I would argue that using open source compiled in-house would give you a *false* sense of security.) None of that changes in the cloud.
PLUS in the cloud you have the ability to use managed identities, completely eliminating the ability of phishers to breach your systems. There is
Re: (Score:2)
If it's open source, it can be used on-prem. If it's not, it's unauditable.
Compiling in house verifies that the executable you're running actually came from the source that passed the audit.
Typically, the audit and in-house compilation would be confined to security critical elements but that will vary by paranoia and actual security requirements.
Re: (Score:2)
You're missing the point. You can compile your own open source systems, and deploy them to the cloud. You're just renting somebody else's computer, instead of having it sit in front of you. In the cloud, if you want to, you can start from a blank image and build the OS yourself. That does not require on-prem.
With that said, I don't think building your own open source code is much of an advantage. OpenSSL with Heartbleed ran on millions of computers, both in the cloud and on on-prem servers. Theoretically, y
Re: (Score:2)
So at that point, the big cloud advantage you claim is that you get to be a renter rather than an owner and you have to trust someone else's physical security sight unseen.
Re: (Score:2)
There's much more to it than that (such as managed identities), but yes, I'd trust AWS or Azure's physical security far more than I trust the rinky-dink security I've seen at most on-prem server racks, where servers are stuck in random closets or wherever the company can find a few square feet of unused space. That kind of attitude about servers does not suggest that companies are willing to spend big bucks on security.
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)
Indeed. That is why I call myself an expert on the "use of cryptography". As long as you keep things simple and respect KISS, it is not that hard to get right. Just do not roll your own modes or protocols or the like and make sure your keys are good. For example for encrypted backups, you can even simply script something with PGP/GnuPG and it can even be public-key, i.e. the secret key for decryption does not even need to be present on the encrypting system.
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)
And as a bonus, if the sysadmin of the on-prem system messes up, you can talk to them and find out whether a firing is in order or whether it was an accident and what they are doing to prevent a repeat.
As to attackers: The goal of encryption is not to make it impossible to break in. It is to make it prohibitively expensive for all expected scenarios. If somebody really wants the data at all cost, they can kidnap the sysadmin's or CEO's children or, if they have more time, set up a nice honey-trap. That has
Re: (Score:3)
It's possible to not mess up *at all* and still get hacked.
You are exactly right, it's prohibitively expensive to account for and protect against "all expected scenarios." This is why cloud servers are superior--large cloud companies have armies of security experts who actually do perform all these "prohibitively expensive" mitigations. They can afford it, because they can do it at scale. YOU cannot.
Re: (Score:2)
That's cute. "Because I can see my system, I know what's happening on it." No you do not. One click on a phishing link, and you're hosed, whether your machine is sitting in front of you, or is on a cloud server somewhere. And don't think you're too smart to be phished. It just a matter of time before one of them tricks even you.
Re:Maybe do not trust cloud operators? (Score:4, Insightful)
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 peace of mind.
For actually keeping data secure, best thing is to take the cloud provider claims with a grain of salt and pack your own parachute.
Re: (Score:2)
As to (1), agreed. Sometimes some joke of an IT auditor requires "encryption" without understanding. I even know one case were a strongly isolated environment got its isolation compromised because some idiot auditor required Anti-Virus in there. Moron. That organization is now dead though and you read about that in the news. (Not allowed to say the company name.)
Also agreed to (2). I just use GnuPG for encrypted backups, with the secret key offline.
The key, as always in good engineering, is to understand wh
More likely than being hacked (Score:1)
Fshy feeling about pcloud from the start (Score:1)
Did NSA help design the protocols (Score:3)
Flaws???? (Score:4, Interesting)
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.
Re: (Score:2)
The word "flaw" implies "unintended", and I think we all know that's just not the case.
I know this seems naive, but indulge me: Are you referring to intended flaws aka backdoors, as sub rosa required by relevant state actors?
... the time it took the company to tell some AI to draft them.
THIS is what I increasingly worry about, regarding encryption and maybe even aspects of functionality.