Mega Says It Can't Decrypt Your Files. New POC Exploit Shows Otherwise (arstechnica.com) 52
An anonymous reader quotes a report from Ars Technica: In the decade since larger-than-life character Kim Dotcom founded Mega, the cloud storage service has amassed 250 million registered users and stores a whopping 120 billion files that take up more than 1,000 petabytes of storage. A key selling point that has helped fuel the growth is an extraordinary promise that no top-tier Mega competitors make: Not even Mega can decrypt the data it stores. On the company's homepage, for instance, Mega displays an image that compares its offerings to Dropbox and Google Drive. In addition to noting Mega's lower prices, the comparison emphasizes that Mega offers end-to-end encryption, whereas the other two do not. Over the years, the company has repeatedly reminded the world of this supposed distinction, which is perhaps best summarized in this blog post. In it, the company claims, "As long as you ensure that your password is sufficiently strong and unique, no one will ever be able to access your data on MEGA. Even in the exceptionally improbable event MEGA's entire infrastructure is seized!" (emphasis added). Third-party reviewers have been all too happy to agree and to cite the Mega claim when recommending the service.
Research published on Tuesday shows there's no truth to the claim that Mega, or an entity with control over Mega's infrastructure, is unable to access data stored on the service. The authors say that the architecture Mega uses to encrypt files is riddled with fundamental cryptography flaws that make it trivial for anyone with control of the platform to perform a full key recovery attack on users once they have logged in a sufficient number of times. With that, the malicious party can decipher stored files or even upload incriminating or otherwise malicious files to an account; these files look indistinguishable from genuinely uploaded data.
After receiving the researchers' report privately in March, Mega on Tuesday began rolling out an update that makes it harder to perform the attacks. But the researchers warn that the patch provides only an "ad hoc" means for thwarting their key-recovery attack and does not fix the key reuse issue, lack of integrity checks, and other systemic problems they identified. With the researchers' precise key-recovery attack no longer possible, the other exploits described in the research are no longer possible, either, but the lack of a comprehensive fix is a source of concern for them. "This means that if the preconditions for the other attacks are fulfilled in some different way, they can still be exploited," the researchers wrote in an email. "Hence we do not endorse this patch, but the system will no longer be vulnerable to the exact chain of attacks that we proposed." Mega has published an advisory here. However, the chairman of the service says that he has no plans to revise promises that the company cannot access customer data.
Research published on Tuesday shows there's no truth to the claim that Mega, or an entity with control over Mega's infrastructure, is unable to access data stored on the service. The authors say that the architecture Mega uses to encrypt files is riddled with fundamental cryptography flaws that make it trivial for anyone with control of the platform to perform a full key recovery attack on users once they have logged in a sufficient number of times. With that, the malicious party can decipher stored files or even upload incriminating or otherwise malicious files to an account; these files look indistinguishable from genuinely uploaded data.
After receiving the researchers' report privately in March, Mega on Tuesday began rolling out an update that makes it harder to perform the attacks. But the researchers warn that the patch provides only an "ad hoc" means for thwarting their key-recovery attack and does not fix the key reuse issue, lack of integrity checks, and other systemic problems they identified. With the researchers' precise key-recovery attack no longer possible, the other exploits described in the research are no longer possible, either, but the lack of a comprehensive fix is a source of concern for them. "This means that if the preconditions for the other attacks are fulfilled in some different way, they can still be exploited," the researchers wrote in an email. "Hence we do not endorse this patch, but the system will no longer be vulnerable to the exact chain of attacks that we proposed." Mega has published an advisory here. However, the chairman of the service says that he has no plans to revise promises that the company cannot access customer data.
Why So Long? (Score:2, Insightful)
I can imagine that when first created, Mega might well have been a block of swiss cheese (security wise). Even with a pitifully small budget though, after 10 years, you'd imagine it would at least have become "competent" (especially as they've been using E2E as their USP for quite some time).
I wouldn't have ever trusted Mega to keep my written plans to invade Elbonia (right under the noses of 15 envious countries) a secret , but by now they ought to be good enough for keeping files reasonably secure from re
Re:Why So Long? (Score:5, Insightful)
You've made a basic mistake; you assume that Mega cares about keeping the files secure. They only care that they convince their users that they're keeping the files secure.
Re:Why So Long? (Score:5, Insightful)
Re: (Score:2)
Bingo. If they don't know, they have a defence when accused of copyright infringement. "But our TOS says no warez! And we have no way of enforcing it!"
It also gives them an excuse not to bother with law enforcement requests for data.
Re: (Score:2)
Well of course. I mean you get what you pay for - dirt cheap online file storage is a lot like dirt cheap storage. They are all named things like 'StoreSafe' or 'KeepSafe Storage' etc and what you get is all the safety a cheap paddlock, a few sodium lamps and a slow scan recorder nobody ever looks unless there is a problem provides.
Realities
- key management is a tough
- encryption is tough when you also want to support features like search, update in place, or recovery of any kind
-
Comment removed (Score:5, Insightful)
Re: (Score:3)
We're still waiting for IPSec to be used for its originally intended purpose (no, it wasn't intended to only be used as part of a VPN protocol), allowing a computer to look up an IP, see if there's a key for it, and if so just start communicating with it using encrypted packets
You just described TLS and the various Certificate Authorities.
the real security nightmare is key exchange.
No, the real security nightmare is that Everyone wants security to be thoughtless. They don't want to spend time exchanging keys. They don't want to verify that the keys used are the ones they've used before. They don't want to check what the Certificate Hash is, much less know how to find it. They don't want to generate the keys themselves. (Let's Encrypt.), They don't want to think about what a self-signed cert is or why it can be more secure
Re: (Score:2)
And the most important one: If you're rolling your own crypto, for fscks sake get it audited by external experts! Mega never did this, so they managed to take a bunch of trendy algorithms and mechanisms and assemble them in an insecure manner.
Oh, and the corollary to that: When your crypto audit tells you there's problems, fix them rather than just adding them to your risk register.
And then a second corollary, a crypto audit isn't something you do a week before shipping, because by then all you can do is
Re: (Score:2)
Re: (Score:3, Informative)
Here is an industry secrete....
Enterprise Software is pure CRAP!
Decision 1: What language should we code it in? The answer is a language that is well known, has a big company to offer support even though you will never need it. You can't go too old with a language, but you cannot use the newer ones as well.
Decision 2: Coding methodologies? That will be dictated by the Execs, often by the guy who had taking a programming class back in College for a semester. Often Object Orientated despite if it is the b
Re: (Score:2)
Wow, nice summary. I can vouch for this and it needs to be modded up. And also it was exactly this kind of crap mentality that drove FLOSS into existence in the 80s and 90s.
Re: Why So Long? (Score:2)
Shady (Score:2)
Why would you pick a shady company like Mega to store your data?
Re: (Score:3, Insightful)
Well, there are even some who trust OneDrive...
Re: (Score:3)
Reasons (Score:2)
I mean, there are plenty of reasons to hate Microsoft. But what's wrong with OneDrive?
1) Microsoft "security".
2) Almost 100% chance there's a government backdoor that lets various government agencies scan anything stored there.
3) Bigger target for people who try to break in to collect data.
4) Just using the service gives more data on you to Microsoft.
Re: (Score:2)
Re: (Score:2)
>But what's wrong with OneDrive?
Even when you don't want it, it keeps hijacking your file locations. "Where did that file go? I saved it on my local in Document" when in reality it got saved in OneDrive//Documents, because word decided to use that Documents folder, not the usual one.
OneDrive is a pox on windows because they didn't play nice with it.
Re: (Score:2)
Re: (Score:2)
It's a PITA. I know how to do that, but most of the people I know do not and I'm the techiest of the all, so they keep coming to me for techy help and OneDrive is a common cause of requesting help.
Re: (Score:2)
Indeed, a more sensible person would store data with Meta! It's better to be 100% certain it can be decrypted and datamined!
Re: (Score:2)
Why would you pick a shady company like Mega to store your data?
My understanding of it is that people choose Mega BECAUSE it's a shady company and therefore they will not care about what shady data you are storing there.
If you believe Kimmie (Score:3, Funny)
you get what you deserve.
Seriously, the main way to find out whether Bubble Bass is lying is to watch his lips: If they move, he does. If they don't, he probably learned ventroliquism.
Re: (Score:2)
It's less "neener, neener" it's more "duh, you don't say".
The title do not really match the info (Score:5, Interesting)
The title do not really match the info given
So... the researcher found a security bug, that was fixed by mega... ... ... but this doesn't mean that mega can decrypt the files, that is over extending the info given
the researcher say that more fixes may be needed to improve the security, that while they can't be directly used now, they can open other future security problems.
mega may or may not fix those issues on the long run, it is still unknown
yes, a security bug could allow that, just like many security bugs can allow one to access other people secret information, but after the security bug is fixed, there is nothing that show that mega or anyone else can access it.
Not that i trust mega with their claim, but the title and parts of the article seems to imply that mega still have access to the user data, where the article content show a normal enterprise security problem fix workflow, fix the major problem first, recheck for other fixes later on or leave less secure features as is, because the risk of breaking things or seems as lower risk by some management (that usually are clueless about security)... still a long way to mega being able to access all your files
Re:The title do not really match the info (Score:4, Insightful)
If you really want privacy with any kind of cloud storage system like that, encrypt the data before uploading and be aware that they still get the metadata.
Re: (Score:2)
Why is this so hard?
You encrypt on the client. You probably want a random Data Encryption Key wrapped by the password which gets sent to the client. That enables you to change the password, or have multiple passwords to the same data. But the unwrapped DEK is never seen on the server.
Hard to see how you could get that wrong.
Or maybe they were doing something clever. Have the password wrap a private key. That way you could upload without the password, and only need the password for recovery. That woul
Philosophy aside... (Score:2, Troll)
If your files can ruin your life, don't create them. if you must create them, store them locally and back them up semi-locally.
Assume everything you create and put "elsewhere" is available to "somebody". Act accordingly.
Meanwhile (Score:2, Funny)
Make sure you commit all your crimes in front of a documentary film crew.
https://www.npr.org/2022/06/21... [npr.org]
"What the f*** is this?" a former top Trump 2020 official messaged the publication after seeing the news.
Re: (Score:2)
It was a reply to a now hidden comment that was equally off-topic.
Re: (Score:2)
yep - follow the advice your mother should have given you at some point - If you don't want it read, don't write it down.
Re: (Score:2)
If your files can ruin your life, don't create them. if you must create them, store them locally and back them up semi-locally.
Assume everything you create and put "elsewhere" is available to "somebody". Act accordingly.
Or... simply encrypt it before you upload it to onedrive/google/whatever.
It's not difficult. 7Zip will do the trick.
https://www.useapassphrase.com... [useapassphrase.com]
http://ciphersaber.gurus.org/ [gurus.org]
Comment removed (Score:5, Interesting)
CryFS Whatever Your Cloud (Score:2)
Emphasize this! (Score:2)
"As long as you ensure that your password is sufficiently strong and unique, no one will ever be able to access your data on MEGA. Even in the exceptionally improbable event MEGA's entire infrastructure is seized!" (emphasis added).
To editors, you didn't add any emphasis. That means you added something like italics or bold to the original, to call out your important point. I doubt you added all-caps MEGA, or the exclamation point.
For the record, in my quote above, (emphasis added)
Kinda, maybe. (Score:3)
This opens the platform to a key-recovery attack that is practical under certain circumstances, namely once a user has logged into an account slightly more than 512 times.
I think it's fantastic that someone bothered to verify the claim though I doubt anyone but intelligence agencies would bother to actually do it. There is a fair chance that someone at the NSA/GCHQ is miffed that someone just ruined their fun.
If you control Mega and inject malicious code (Score:2)
The researchers do make an assumption that Mega will run for at least a few years while compromised (the attack requires the presence of malicious code and anywhere from 512-1024 up to 2^16 logins to be able to extract a single key).
This isnâ(TM)t unique to Mega though, any system that allows you to type things in a website can be potentially affected by the malicious entity running the website.
Obvious research paper is obvious, perhaps they could use bigger keys, that will up the case from 1024 guesse
Am I missing something? (Score:1)
How would cracking the password for the login let you decrypt the files?
Surely any files are encrypted locally before being uploaded?
Are there people who happily expose their data to nosy, intrusive operating systems and send it en clair through compromised, backdoored routers across compromised, corrupt ISPs and then think "Hurrah! My datas are all secure because some random jerks claim to be encrypting it as it enters their storage facility!" ?
Re: (Score:2)
How would cracking the password for the login let you decrypt the files?
Because the key is derived at least in part from the password ultimately. So cryptography attacks become possible reducing the effort otherwise required for a key search.
Surely any files are encrypted locally before being uploaded?
I have no idea but the reality is - dose not really matter. Its online file storage "the point" for a large portion of the users is to be able to access the content from multiple endpoints. (some people might just use it as an offsite backup I suppose) Access from multiple endpoints means the key must be either reproducible, like say der
Re: (Score:1)
How would cracking the password for the login let you decrypt the files?
Surely any files are encrypted locally before being uploaded?
My understanding of mega's service is that the encryption key is directly derived from the password. So if you have the password, you can generate the key.
They can't decrypt files encrypted before uploadin (Score:2)
I use MEGA myself (the free 50GB service), but ALL files that I upload to MEGA are first strongly encrypted on my local system before uploading to my MEGA cloud drive. Thus even if someone does manage to somehow steal my cloud files and decrypt them, the resulting "decrypted" files are simply my original LOCALLY ENCRYPTED files that were encrypted beforehand using a completely different password and encryption
"Dotcom" is so 90s, shouldn't he have changed his (Score:2)