Penetration Test Report (Cure53): pentest report mailvelope

Pentest-Report Mailvelope 12.2012 - 02.2013
Cure53, Dr.-Ing. Mario Heiderich / Krzysztof Kotowicz
Index
Introduction
Tes t Chronicle
Methodology
Vulnerabilities
MV -01-001 Insufficien t Outpu t Filtering enables Frame Hijacking Attacks ( High )
MV -01-002 Arbitrary JavaScrip t execution in decrypted mai l contents ( High )
MV -01-003 Usage o f externa l CSS loaded via HTTP in privileged contex t ( Medium )
MV -01-004 U I Spoo f via z - indexed positioned DOM Elements ( Medium )
MV -01-005 Predictable GET Parameter Usage for Connection Identifiers ( Medium )
MV -01-006 Rich Tex t Editor transfers unsanitized HTML conten t ( High )
MV -01-007 Features in showModalDialog Branch expose M ailer to XSS ( Medium )
MV -01-008 Arbitrary File Download with RTE editor filter bypass ( Low )
MV -01-009 Lack o f HTML Sanitization when using Plaintex t Editor ( Medium )
Miscellaneous Issues
Conclusion
Introduction
“Mailvelope uses the OpenPGP encryption standard which makes it compatible to
existing mail encryption solutions. Installation of Mailvelope from the Chrome Web Store
ensures that the installation package is signed and therefore its origin and integrity can
be verified. Mailvelope integrates directly into the Webmail user interface, it's elements
are unintrusive and easy to use in your normal workflow. It comes preconfigured for
major web mail provider. Mailvelope can be customized to work with any Webmail.”1
1 http :/ / www . mailvelope . com /about
Test Chronicle
• 2012/12/20 - XSS vectors in common input fields (Mailvelope options etc.)
• 2012/12/20 - XSS vectors hidden in exported public PGP keys (via seahorse)
• 2012/12/21 - HTML injections/XSS inside encrypted HTML mail body
• 2012/12/21 - Webkit CSP bypass probing via data URIs and SVG
• 2012/12/21 - Attempts to inject JavaScript via Kendo UI Templates
• 2012/12/22 - Source code analysis JS/HTML
• 2012/12/22 - XSS tests with H5SC payloads
• 2012/12/30 - Additional Tests with showModalDialog Branch
• 2012/12/31 - Tests with showModalDialog / X-Domain Drag&Drop / Copy&Paste
• 2013/01/01 - Ongoing design discussion and threat modeling
• 2013/01/07 - showModalDialog tests with new payloads
• 2013/01/12 - Verified fixes, tested against new copy&paste attack vectors
• 2013/01/14 - Verified security for Xing HTML5 RTE
• 2013/01/16 - Finalized tests, discussions and report
Methodology
The test against Mailvelope was not a classic penetration test against a static target, but
rather a very early evaluation of Mailvelope’s security implementation and its security
design’s aspects. The bugs listed in this report are based on a test against an alpha
version, thus they are mostly absent from currently deployed versions. Mailvelope does
not embark on an easy mission. It attempts the complicated split between being secure
enough in implementation, information flow and design to be able to safely “bring PGP to
the browser” but as well be capable of providing a satisfying user experience to allow
even non-technical users to benefit from its privacy assuring goals and features.
Note that this report by no means encourages usage of PGP and related libraries in the
DOM of the enhanced websites or web-mailers. All cryptographic business logic as well
as any form of secret data must never be available to the website’s DOM, being strictly
isolated in the browser’s extension context. Naturally, dealing with encrypted and
decrypted messages in the context of a browser extension, which resides on top of
almost arbitrary web mailer interfaces, raises a set of novel challenges. To be able to
enumerate those properly, a threat model has to be designed and agreed upon by
development and pentest teams. The result of this agreement shall be outlined as
follows:
• A rogue sender - attempting to abuse the lack of server-side XSS filtering
dictated by end-to-end encryption on top of a web-mailer interface for client-side
attacks against the user and the web-mailer platform itself. Note that no server-
side filtering can be applied to the encrypted mail body - so the extension must
filter after decryption or render the content in a safe way. Goal: All data must be
safe, even if a rogue sender is part of the communication.
• A rogue web-mailer - attempting to gain information on the plaintext before
encryption or after decryption. This includes side-channels such as the height of
a text container, keystroke intervals, focus events and other information being
passed between user and browser extension. Goal: All data must be safe, even if
the mail provider has malicious intent.
• A rogue third party - potentially attacking the web-mailer or any other website
the user is active on to try finding a lever to get a hand on the decrypted
information or any other secret used during the process of creating, encrypting,
receiving, decrypting and reading mails. Goal: All data must be safe, even if the
mail provider was attacked or the user has a malicious tab opened.
The first version of Mailvelope was completely incapable of preventing attacks from a
rogue or attacked web-mailer. The mail editor, the buttons to trigger encryption and
decryption, as well as the passphrase dialog for the key, were placed in the same
window as the web-mailer UI (in our specific test-case Gmail). In order to attack the
privacy of the conversation protected by Mailvelope, the adversary controlling the DOM
of the web-mailer would have to create an element that overlaps the mail editor. This
simple trick would make it possible for the adversary to record the keystroke for mail
composition and password, obtaining a clearly unacceptable amount of data from the
victim in result. The cryptographic protection would have simply been bypassed by a
naive yet powerful UI redressing attack.
The only way to get around this problem across browser versions and families was to
completely detach the critical dialogs from the UI, which means using modal dialogs.
Non-modal dialogs would enable a small attack surface for focus stealing attacks. An
attacker could simply request focus for a different view, and thereby redirect victim’s
keystrokes. Depending on the browser’s capabilities, the attack could have been carried
out so subtly that our victim would notice the redirected keystrokes far too late, yet again
irreversibly leaking a significant portion of private information. Unfortunately, modal
dialogs in Google Chrome are not modal and have never been such. This means that an
attacker can place another “modal” on top of the “modal” and simply spoof its
appearance, with sensitive data leakages as a consequence. For this reason, the loss of
focus on Mailvelope dialog windows had to be dealt with differently and a trust token,
clearly identifying the modal rather than a spoofed version is desirable. To obtain this
goal, a feature seen in Cryptocat, namely the color coding for the OTR keys, was
introduced. Along with that, several mechanisms capable of noticing and reacting to
focus loss and focus changes were implemented. For these and several other
components of Mailvelope, we needed to find solutions with a capability of providing the
necessary level of security while still preserving productivity, which could, when
hindered, deter the users from the tool. During the feature and design discussions, it
turned out helpful to keep the most important security requirement in mind: Never must
any of the users’ secrets and sensitive data in any way leak to anyone other than the
intended recipient(s). Neither an attacker, nor the mail provider (be it benign or not) or
any other party must have any awareness of this data. This requirement includes simple
XSS attacks, geometry-based side-channels, keystrokes, data storage, information
flows, predictable URLs and other vectors and information sinks.
In its current stage, Mailvelope might not yet be ready for unresented global usage - but
the majority of web-security and UI-based security issues should have been addressed
successfully. Mailve