It appears the attack is based on a failed login leaking information, and that 512 failed logins would be enough for Mega itself to crack the key.
But, to be a practical attack, the client software would first have to be modified to conceal the suspiciously big number of bogus failed logins from the end user (if I understood clearly)
> Since the server code is not published, we cannot implement a Proof-of-Concept (PoC) in which the adversary actually controls MEGA. Instead, we implemented a MitM attack by installing a bogus TLS root certificate on the victim.
> ...
> The log in attempt fails, which is only a limitation of the MitM setting. A malicious cloud provider can perform this attack without the user noticing.
Thanks for clarifying it. Yes, the writing about it is surprisingly unclear. Even on the original paper and the dedicated website for this bug, there's a frustrating lack of clarity about what they mean by "login" and how much the user is in the loop of this attack, which could be an important gating factor making it unlikely to ever have been a practical exploit
I just decided nothing I was savings (OS ISOs, school backups, music)was worth hoarding. For super super important things I just use dropbox (free tier) or email zip files to myself.
It does depend on a malicious party gaining access to the servers.
In that case they could also update the code and leak the password directly as many people pointed out in the ars thread. It's still a lot better than no e2e as with Google and Microsoft.
I always use cryptomator on top of OneDrive. I'm thinking using it on top of mega instead might not be a bad idea at all. It's still an extra layer even if it's breakable.
But not sure if I'll trust mega to stick around. Pretty sure the suit around Kim Dotcom's extradition is still going on.
9 comments
[ 3.0 ms ] story [ 22.9 ms ] threadBut, to be a practical attack, the client software would first have to be modified to conceal the suspiciously big number of bogus failed logins from the end user (if I understood clearly)
From the original article https://mega-awry.io/ (emphasis mine):
> Since the server code is not published, we cannot implement a Proof-of-Concept (PoC) in which the adversary actually controls MEGA. Instead, we implemented a MitM attack by installing a bogus TLS root certificate on the victim.
> ...
> The log in attempt fails, which is only a limitation of the MitM setting. A malicious cloud provider can perform this attack without the user noticing.
Thanks for clarifying it. Yes, the writing about it is surprisingly unclear. Even on the original paper and the dedicated website for this bug, there's a frustrating lack of clarity about what they mean by "login" and how much the user is in the loop of this attack, which could be an important gating factor making it unlikely to ever have been a practical exploit
In that case they could also update the code and leak the password directly as many people pointed out in the ars thread. It's still a lot better than no e2e as with Google and Microsoft.
I always use cryptomator on top of OneDrive. I'm thinking using it on top of mega instead might not be a bad idea at all. It's still an extra layer even if it's breakable.
But not sure if I'll trust mega to stick around. Pretty sure the suit around Kim Dotcom's extradition is still going on.
Or force a re-encryption after 300 logins or so?