Mega facts [Cloud Storage Service]

[Jeffrey Walton <noloader () gmail com>]

http://www.h-online.com/security/features/Mega-facts-1789685.html

Cloud storage service Mega has only just launched and no detailed
analysis of how it works has yet been performed. The following report
is based on initial observations and Mega's own documentation.

Encryption
No specific details of how this works are available at present. The
documentation provided by Mega is in this respect also limited in its
usefulness. It appears that each file is encrypted using a separate
AES key. These keys are, according to Mega, not transferred to the
server, instead encryption and decryption is performed locally by an
app running in the browser.

The idea is not new – Zerobin, for example, utilises a similar concept
to ensure that it can't be held liable for user content on its
servers. Mega has also borrowed Zerobin's trick of embedding the keys
in HTML anchor elements. Mega URLs take the form:

https://mega.co.nz/#!12wlkJza!PRA-8y246I55pJUl-...

All of the URL after the # is an internal link to an anchor within the
HTML page. Internal anchors of this type are always resolved locally
in the browser and are not sent to the server. In this case, 12wlkJza
is clearly an index for the file and PRA 8y246I55pJUl-... is the
associated key.

It is however alarming, that the one of the first analyses of the
service revealed beginner's mistakes in the usage of crypto functions.
Mega sideloads code from a content distribution network (CDN) and
checks its integrity, but the function it uses for this is by no means
fit for this purpose. Instead of a hash function such as SHA256, Mega
uses CBC-MAC to perform this check with a constant hard-coded key
(111111, 222222, 333333, 444444 ...). But even the Wikipedia page
clearly states that CBC-MACs can be easily spoofed if used with a
known key.

This leads to a situation where anybody controlling such a CDN server,
or anybody who can coerce such a person with a subpoena or the like,
can easily manipulate the code stored there. Beginner mistakes like
these do not bode well for the remainder of the crypto infrastructure
of the service.

Traceability
The encryption model is primarily intended to protect Mega from legal
problems. Whether prosecutors will be impressed by a storage provider
using technical measures to achieve ignorance of the content on its
servers remains to be seen. Whether the service might contain security
vulnerabilities which undermine the concept will only become known
following intense scrutiny.

As for Mega's willingness to cooperate with police investigations
aimed at its users, one can only speculate. The idea that the company
is unable to help investigating authorities in such cases is not
correct. Mega could, for example, at any time modify the script loaded
by the browser to send the key used for encryption to a web server.
This is a basic problem in all situations where the key-handling
program comes from an untrusted source.

In addition, although Mega states that it has no way of knowing
whether its users are storing criminal content in its cloud storage,
point 8 of its terms of use provides for de-duplication of stored
data. Should it become known, for example, that Eve has used the
service to store files with criminal relevance, this could lead to
problems for other users.

For the purposes of de-duplicating data, a server keeps lists of
hashes from currently stored data blocks. If a user tries to store a
file which has previously been uploaded by another user, they are
provided with a link to the existing storage location. This saves the
user from having to upload the file and saves the operator from having
to maintain storage space for multiple copies of the same file. The
problems caused by the fact that the data is encrypted can be resolved
by means of clever key management.

Mega would, however, be able to determine that Walter also has a copy
of the problematic file uploaded by Eve. It would also be possible to
deliberately create such a situation in order to search for specific
content. Whether Mega has actually implemented de-duplication of
content is unknown. The company has previously promised not to
implement this feature, but why then does it retain the right to do so
in its terms of use?

Quality
The service is currently still at the beta stage. It is thus no great
surprise if users discover cross-site scripting (XSS) vulnerabilities,
as indeed many already have. It may be possible to exploit XSS
vulnerabilities to inject code into the browser to compromise keys.
The fact that the infrastructure has not been able to cope with the
initial demand, that performance has been mediocre and that there have
been regular outages is also unextraordinary.

Summary
From a technical point of view, Mega has taken some interesting
approaches. Even if it's not yet possible to give a definitive verdict
on their implementation in practice, one thing is clear – the idea
that a storage service can be trusted just because you or your data is
protected by means of encryption is completely misguided. And whether
Mega founder Kim Dotcom has earned the requisite level of trust is
another question entirely.
_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.