[liberationtech] Encrypted Pastebins: Attack Vectors against ezcrypt.it and 0bin.net

[carlo von lynX]

	Synopsis:

    Hi, you may have seen the popularity rising of https://ezcrypt.it and its imitator https://0bin.net. These are services that let you encrypt a message using Javascript in your own browser, then pass on the encrypted contents for the service to store while you pass the decryption key your browser generated directly to the recipient using the #<anchor> part of the URL. You MUST not send it to the server. Once the recipient clicks on the URL her browser will keep the <anchor> on the client side, get the content and the necessary Javascript from the server and the Javascript will then access the <anchor> in order to decrypt the message in the browser.

    In other words, this is a pretty nifty way to use existing web technology to implement opportunistic end-to-end encryption.

    I can tell three attack vectors that an adversary can use - two active and a "passive" one - to gain access to the encrypted contents of the message.

	1. Active local adversary attack:

    This is the more obvious one: An adversary gains access to the server and changes the Javascript or HTML code in such a way, that an unencrypted copy of the message is submitted to the server. The attacker can choose to do this only for specific targets in order to avoid getting caught. See http://secushare.org/end2end for more on these kind of attacks.

	2. Local man in the middle attack:

    Similarly to attack 1, if the attacker cannot gain access to the server she can still intercept communications using false HTTPS certification and provide modified HTML or Javascript from there. You can protect your recipients against this kind of attack by having them install Certificate Patrol (see http://patrol.psyced.org).

	3. "Passive" global adversary attack:

    Although we haven't seen any evidence yet, it is reasonable to assume that many computing facilities offering server hosting, housing and especially virtual machine hosting (VPS) have been compromised using Patriot legislation to offer a 24/7 surveillance access to authorities. See http://secushare.org/2011-FSW-Scalability-Paranoia for more information on this kind of attack. The authority can therefore access all encrypted messages being stored on the server passively as they move around server memory or virtual hard disk. In other words, once this infrastructure is in place with the computing center, there is no way for the server administrator to observe such kind of surveillance.

    Combined with the ability of a global adversary to evaluate the URLs as they are passed on through the Internet by means of e-mail or Facebook chat, the authority can extract the private key attached to the URL and apply it to the encrypted data obtained from the server in order to decrypt the message without showing up in the access logs of the server.

	Conclusion / Recommendation:

    There are safer ways to communicate privately: Pond, I2P, freenet, TorChat, RetroShare (see http://secushare.org/comparison). OTR and PGP not as much, but still better (see http://secushare.org/PGP for details). If you have the possibility to install such a software, do so. If you don't, try to at least pass the URL over a safe channel such as OTR. If that still isn't an option, then find a server that is very unlikely to be tapped by the authorities according to attack vector (3) and install the service from the available source codes. Remember to also protect yourself against attack vector (2) with certificate pinning practices.

    Sorry for spoiling this apparently "easy" solution, but the Internet is currently more broken than that.