Penetration Test Report (Cure53): pentest report SC4

Pentest-Report SC4 03.2015 and 05.2015
Cure53, Dr.-Ing. Mario Heiderich, Jann Horn
Index
Introduction
Scope
Identified Vulnerabilities
SC 4-01-002 Running from file :// in Chrome is considered insecure ( High )
SC 4-01-004 XSS via Attacker - controlled usage o f malicious Filenames ( Critica l)
SC 4-01-006 Inconsisten t Warning abou t a Key ’ s Age ( Low )
SC 4-01-007 Preamble contains HTTP Link where HTTPS is needed ( Low )
SC 4-01-008 Attacker can fake Direction o f encrypted , unsigned Messages ( Low )
SC 4-01-011 Message Contents shown with attacker - controlled MIME Type ( Critica l)
SC 4-01-012 Signature does no t cover filename and MIME type ( Medium )
SC 4-02-013 Random File Names are too shor t and allow brute - force Attacks ( High )
SC 4-02-014 No Warning abou t SC 4 Copy in the Downloads Folder ( Medium )
SC 4-02-015 Differen t Conten t - Type bypasses Preview Sanitization ( Critica l)
SC 4-02-017 Links to loca l files are no t removed during Sanitization ( High )
SC 4-02-019 CSS can be used to break ou t o f DIV containing Message ( Medium )
SC 4-02-020 Signatures for transferred Files are too ambiguous ( Low )
Miscellaneous Issues
SC 4-01-001 Wrong Key - Size given in README . md ( Info )
SC 4-01-003 Hosted Version does no t employ X - Frame - Options ( Medium )
SC 4-01-005 No Conten t Security Policy Headers are being used ( Medium )
SC 4-01-009 Differen t Signer and Encrypter are accepted ( Low )
SC 4-01-010 U I issue : “ Encryp t ” is a misleading labe l ( Info )
SC 4-02-016 No Character Se t applied in Conten t - Type o f sanitized Data ( High )
SC 4-02-018 No Protection from being framed for Loca l SC 4 Version ( Low )
Conclusion
1/14
Introduction
“SC4 is a web application that provides secure encrypted communications and secure
digital signatures. It is intended to be a replacement for PGP/GPG.”
From https :/ / github . com / Spark - Innovations / SC 4
This test against the SC4 web crypto tool was carried out in two phases, one starting on
March 2015 and the other one starting in May 2015. The first phase was meant to review
the first technical prototype of the application, while the second phase united a fix
verification process as well as a conclusive test against newly added features and
protections. Findings from the first phase of the test are labelled with identifiers SC4-01-
00X while findings from phase two are labelled with SC4-02-00X.
The first phase, a quick-test against the SC4 web crypto application was performed over
the course of 1.5 days and yielded seven vulnerabilities and five general weaknesses.
Two of the identified vulnerabilities were classified to be of a critical degree of severity.
This is because they allow an attacker to remotely compromise a victim and get access
to data which is highly sensitive in the context of this particular application.
It must be noted early on that the test took place at a very early stage of the project
development. Nonetheless, it managed to pinpoint a severe design issue (described in
SC 4-01-002) resulting from a problematic and unforeseeable behavior of the
Blink/Webkit browser engine during the handling of persistent storage from a file://
origin1. Over the course of the test and throughout the accompanying communication
with the SC4 maintainers, several alternatives to working around the browser’s quirky
and insecure behavior were discussed. If none of the suggestions can ultimately be
suitable for the envisioned use-cases, it is a vital task to contact the browser developers.
A ticket2 about the storage isolation problem should be filled, and then a properly
working fix must be awaited.
The second phase of the test was also performed over a period of 1.5 days and covered
verification of fixes from phase one and more security tests against the remaining
components and newly added code. Six additional vulnerabilities were spotted and one
of them was classified to be of critical severity. In addition, two general weaknesses
were identified and reported. All were reported by the Cure53 team, addressed by the
SC4 maintainer, and generally verified as fixed by Cure53 afterwards.
Our verdict is that SC4 has developed from a proof-of-concept to an edgy and
unconventional yet reliable crypto tool. If certain limitations and constraints are
respected by its users, SC4 indeed fills a formerly unpopulated gap in the world of
browser crypto.
1 http :// en . wikipedia . org / wik i / File _ UR I _ scheme
2 https :// code . google . com / p / chromium / issues /list
2/14
Scope
• Spark Innovations SC4 App and Sources
◦ https :/ / github . com / Spark - Innovations / SC 4
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, which is simply given in brackets following the title
heading for each vulnerability. Each vulnerability is additionally given a unique identifier
(e.g. SC4-01-00X / SC4-02-00X) for the purpose of facilitating any future follow-up
correspondence.
SC4-01-002 Running from file:// in Chrome is considered insecure (High)
The file README.md instructs the user to “Download the code and open sc4.html in
your favorite browser.” This clearly implies a promise of the SC4 application being safe
when run from a file: URI. Indeed, in Firefox one Local Storage3 database exists per
folder, however, this unfortunately is not the case in Google Chrome. There all pages
loaded from file: URIs share the same Local Storage database, meaning that any other
HTML file that the user opens from his hard drive will gain access to his secret SC4
keys.
Consequently, this seems like a violation of the Web Storage spec4 (in Chrome, for local
files, the full path is the origin for security purposes). Therefore, a recommendation is to
attempt to have this changed in the Chromium codebase by filing an issue in the
Chromium bug tracker. If this approach fails, it might be necessary to prompt the user to
save data prior to closing the SC4 tab by overwriting the existing sc4.html with a version
that contains the persistent data (Alternatively stop support for running from file:// URIs
in Chrome).
Note that this appears to be a browser-engine related problem and thus also affects
Safari, Opera and other WebKit/Blink-related browsers.
Note: This issue has not been verified as successfully fixed by Cure53 in the second
round of testing. However, issues SC 4-02-013 and SC 4-02-014 address the
implementation and comment on the final fixes.
3 http :// diveintohtm l 5 . info / storage .html
4 http :// www . w 3 . org / TR / webstorage /# security - localStorage
3/14
SC4-01-004 XSS via Attacker-controlled usage of malicious Filenames (Critical)
An XSS problem was discovered in relation to maliciously prepared filenames and MIME
types. The method process_sc4_file()5 shows filenames and MIME types contained in
received messages without escaping them:
msgs.push(filename ? 'File name: ' + filename : '(No file name)');
[...]
msg(msgs.join('<br>'));
This allows an attacker to inject arbitrary HTML code into a victim’s SC4 instance by
sending him an encrypted message. Because the message is encrypted, the victim has
no chance of spotting the XSS attack. As soon as he clicks the decrypt button, the
injected script will run. To reproduce the issue from the attacker’s perspective, one must
import the victim’s public key, set a breakpoint at the top of bundle()6 and write a
harmless-looking message. Select the “Encrypt” option and click “Submit”. When the
breakpoint fires, enter the following in the developer console:
filename='hello.txt<img class=dropzone src=x
onerror="X=encrypt;encrypt=function(a,r){if(rx_keys[r]
[0]==\'test1@cure53.de\')return bufconcat([X(a,r),to_bytes(\'###### HERE COMES
THE KEY ######\'+localStorage[sk_key])]);return X(a,r)}">'
Next, let the execution continue and send the resulting message to the victim. Ass