Penetration Test Report (Cure53): pentest report minilock

Pentest-Report MiniLock 07.2014
Cure53, Dr.-Ing. Mario Heiderich / Dipl. Math. Franz Antesberger / Dr. Jonas Magazinius
Index
Intro
Scope
Tes t Chronicle
Identified Vulnerabilities
ML -01-006 Unicode Passphrase causes Denia l o f Service ( L ow )
Miscellaneous Issues
ML -01-001 Possible Uncloaking via de - crypted HTML Files ( Low )
ML -01-002 Lack o f exception handling causes Denia l o f Service ( Info )
ML -01-004 Recommended Recipien t ID Truncation ( Info )
ML -01-005 Insufficien t Entropy in generated Passphrase ( Medium )
ML -01-007 Use o f deprecated Functions escape () and unescape () ( Low )
ML -01-008 Missing senderID emits uncaugh t Error and causes App to freeze ( Info )
ML -01-009 Scryp t is used with static Sal t assisting Dictionary Attacks ( Info )
ML -01-010 Manipulated Metadata causes App to freeze ( Info )
ML -01-011 Weak Passphrases possible using Unicode and Umlauts ( Medium )
ML -01-012 Unicode Filenames cause erroneous Downloads ( Low )
Conclusion
Intro
“MiniLock is a small, portable file encryption software. The idea behind its design is that
a passphrase, memorized by the user, can act as a complete, portable basis for a
persistent public key identity and provide a full substitute for other key pair models, such
as having the key pair stored on disk media (the PGP approach).”
From https://github.com/kaepora/miniLock
This penetration test was carried out by three testers of the Cure53 team over the period
of four days. The test identified one medium-range vulnerability, arguably rather
harmless under the considered scope. In addition, ten general weaknesses, minor flaws
and issues that warrant security-recommendations. Tests were carried out against the
miniLock browser extension itself, its locally-modified versions and the provided source-
code. Over the course of the pentest, the issues were reported in an ongoing manner by
Cure53 and resolved by the author. The fixes were subsequently verified as valid and
working by the testing Team.
Scope
• MiniLock Application
◦ Source-code provided by Nadim Kobeissi
◦ Six tested revisions (fixes were installed after live-reporting)
Test Chronicle
• 2014/07/09 - Penetration-Test begins
• 2014/07/10 - First tests analyzing attack surface and possible sources and sinks
• 2014/07/10 - JavaScript SCA for DOMXSS sinks
• 2014/07/10 - Tests with encryption / decryption of files with malicious names
• 2014/07/10 - Basic tests for UI security
• 2014/07/10 - Tests against gaps in Chrome’s download handling of insecure file types
• 2014/07/10 - Tests using tampered miniLock files
• 2014/07/10 - Tests using a rogue client with tampered IDs
• 2014/07/11 - Tests against the miniLock file parser
• 2014/07/11 - Extended tests with Unicode passphrases and filenames
• 2014/07/14 - Tests with Unicode passphrases
• 2014/07/14 - Tests attempting to narrow down a denial-of-service issue ( ML -01-006)
• 2014/07/14 - Reproduction of ML -01-006 on several Chrome versions
• 2014/07/14 - Checked sources other than javascript (css, woff, img)
• 2014/07/14 - Analysis of miniLock file parsing
• 2014/07/14 - Analysis of encryption/decryption routines
• 2014/07/14 - Checked scrypt configuration
• 2014/07/15 - Checked password entropy
• 2014/07/15 - Checked nacl
• 2014/07/15 - Checked “strange” passwords
• 2014/07/15 - Further analysis of miniLock file parsing
• 2014/07/15 - Analysis of multi-user encryption/decryption
• 2014/07/16 - Checked scrypt salt validation
• 2014/07/21 - Finalization of Pentest-Report
Identified Vulnerabilities
The following sections list both vulnerabilities and implementation issues spotted during
the testing period. Note that findings are listed in a chronological order rather than by
their degree of severity and impact. The impact factor is simply given in brackets
following the title heading for each vulnerability. Each vulnerability is additionally given a
unique identifier for the purpose of facilitating future follow-up correspondence.
ML-01-006 Unicode Passphrase causes Denial of Service (Low)
A discovery was made in regards to the use of a Unicode passphrase (more specifically
- the UTF-16 Emoji characters), for which miniLock determines the key as valid and
henceforth unlocks the application. However, the app actually freezes and a
RangeError is thrown. Note that the problem appears to exclusively reproduce on
Chrome 38, the Canary version at the time of testing.
Example Passphrase:

Error:
Uncaught RangeError: Invalid array buffer length js/lib/crypto/scrypt.js:40
Strangely, an attempt to enter the Unicode passphrase once causes miniLock to cease
working altogether, even if the app is restarted. On any occasion that this particular or
another user tries to enter a valid and formerly working passphrase, the same error will
be thrown. Again, this problem only reproduced successfully on Chrome Canary
(version 38). Chrome 35 was not affected by this problem.
The miniLock app should test whether the pass phrase chosen by the user is valid and
working. While this issue is not an attack per se (except for causing a persistent denial-
of-service), it might be used as such in the later stages of development. Consequently,
it should be mitigated as soon as possible.
Note: The issue was reported during the pentest and fixed properly. The fix was
achieved when a hash over the passphrase was created and then used for encryption.
Miscellaneous Issues
This section covers those noteworthy findings that did not lead to an exploit but might aid
an attacker in achieving their malicious goals in the future. Most of these results are
vulnerable code snippets that did not provide an easy way to be called. Conclusively,
while a vulnerability is present, an exploit might not always be possible.
ML-01-001 Possible Uncloaking via de-crypted HTML Files (Low)
MiniLock showed a minor weakness with potentially harmful files that are considered
harmless by Google Chrome (among them are HTML and SVG files). To illustrate the
issue, one needs to track and observe what Chrome does upon finishing the download
of a file. In this case, the decrypted file received and processed by miniLock is subject to
investigation.
When a file is received after decryption, one can essentially face two possible scenarios:
1. Chrome 35+ main window is open, a download will show in the footer bar, users
can click on the downloaded file to cause it to open.
2. Chrome 35+ main window is not open. Harmless downloads will automatically be
placed in the ~/Downloads folder. The files deemed harmful or dangerous
Chrome fail to download. A file called "Unconfirmed...xxx.crdownload" will be
created in the ~/Downloads folder as there is no window to display the dialogue.
Chrome assumes that certain downloads are safe and others are not. Obviously, the
determination is controlled through the use of a black-list. Extensions like .exe, .scr, .url,
.com, .pif, .bat etc. are considered dangerous. Conversely, .html, .xht, .svg, for instance,
are not. The ones belonging to the latter category are unable to directly execute arbitrary
code on the system. Nonetheless, they may execute JavaScript locally. What can
happen upon a single click on a decrypted file in the Chrome footer-bar is the following:
• Uncloaking the full path to the user's home directory and sending it to evil.com.
This can serve as a de-anonymization if the user is not careful and avoids
opening the HTML file locally.
• Reading of local files from the ~/Downloads folder whenever the IE is the default
handler (which it is on Windows XP - 8.1 for .svg, .xht and many other extensions
classifying files as capable of causing local XSS) as it is possible for a local file
applied with Zone Identifier 3 to access and read any other file applied with the
same Zone Identifier.
In order to succeed, one only has to create a file called test.html or test.xht (or even
dolphins.svg), encrypt it, send it, have it be decrypted and get the user to click on the
downloads bar in the footer area of Chrom