Penetration Test Report (Cure53): pentest report Subrosa may2014

Pentest-Report Subrosa 05.2014
Cure53, Dr.-Ing. Mario Heiderich / Dr. Jonas Magazinius
Index
Intro
Scope
Tes t Chronicle
Identified Vulnerabilities
SR -01-001 XSS via unfiltered Display Name in Camera View Overlay ( High )
SR -01-002 XSS via unfiltered Display Name in Cal l Notification ( Critica l)
SR -01-004 XSS via unfiltered Display Name in online Notification ( Critica l)
SR -01-007 WebSocke t Protoco l vulnerable to Replay Attacks ( Critica l)
SR -01-008 Manipulation o f IV changes Decryption Outpu t ( Critica l)
SR -01-009 Password update leads to ful l accoun t compromise ( Critica l)
SR -01-013 Cal l Extension Attack allows for cover t Surveillance ( High )
Miscellaneous Issues
SR -01-003 Possible passive XSS via unfiltered News Item URL ( Low )
SR -01-005 Reliance on Server - Sanity causes tremendous XSS Risk ( Medium )
SR -01-006 Subrosa Version Check can be bypassed ( Low )
SR -01-010 User information partially sen t in C leartex t ( Medium )
SR -01-011 U I can be broken using localStorage . sidebarWidth ( Info )
SR -01-012 No X - Frame - Options Headers or any Form o f CSP is used ( Low )
Conclusion
Intro
“Subrosa is an encrypted communication platform. Reclaim your privacy and talk freely.
It's free and open source, with no ads.”
“With Subrosa, reclaim your privacy and dignity. All your communications are encrypted,
and your encryption keys are never sent to Subrosa, and we can't read your messages
or listen to your calls without your encryption keys, even with guns pointed.”
From https :/ / subrosa . io /
This penetration test was carried out by two testers of the Cure53 team over the period
of six days. The test identified six vulnerabilities of which five were classified as critical.
Tests were carried out against the Subrosa application itself, its locally modified
versions, the provided source-code and parts of the server-side code.
Scope
• Subrosa Chat Application
◦ https :/ / subrosa . io /app
◦ Source-code provided by the Subrosa team
Test Chronicle
• 2014/05/16 - Penetration-Test begins
• 2014/05/17 - Standard XSS tests using malformed display name
• 2014/05/18 - Ongoing XSS tests, first Live-Reporting
• 2014/05/18 - Documented SR -01-001, SR -01-002, SR -01-004
• 2014/05/18 - WebSocket Debugging
• 2014/05/19 - Documented SR -01-003
• 2014/05/19 - Ongoing WebSocket Tests
• 2014/05/19 - JavaScript Source Code Audit
• 2014/05/20 - Analysis of login procedure
• 2014/05/20 - Analysis of crypto usage
• 2014/05/20 - Tested and verified XSS fixes in 0.16
• 2014/05/21 - Ongoing JavaScript Source Code Audit
• 2014/05/21 - Tests with rogue online status using api.emit() calls
• 2014/05/21 - Test for cross-site WebSocket hijacking
• 2014/05/21 - Analysis of WebSocket protocol
• 2014/05/21 - XSS Tests assuming server / TLS compromise
• 2014/05/21 - Added SR -01-005
• 2014/05/21 - Tested reliability of version check, added SR -01-006
• 2014/05/22 - Added SR -01-007, SR -01-008 and SR -01-009
• 2014/05/25 - Tested and verified XSS fixes in 0.17
• 2014/05/25 - Tested MitM capabilities for WebSockets
• 2014/05/25 - Tested against spoofed screen-sharing calls / phishing
• 2014/05/25 - Tests against extension of call duration / Info leakage
• 2014/05/26 - Security tests against website, FAQ and periphery
• 2014/05/26 - CSP compatibility tests, creation of SR -01-012
• 2014/05/26 - Tested array access security with users “constructor” and “__proto__”
• 2014/05/27 - Added SR -01-013
• 2014/05/29 - 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, which 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.
SR-01-001 XSS via unfiltered Display Name in Camera View Overlay (High)
There is an issue with the display name of a conversation partner in a video chat. Once
it is shown in the camera overlay that displays the incoming video stream, it is not being
escaped properly. This allows an attacker to inject arbitrary HTML and JavaScript
whenever a video conversation between two or more participants is being initiated.
Steps to reproduce:
1. Log in with user A
2. Log in with user B
3. Log in with user C (malicious display name)
4. Have user A, B and C start a video conference
5. JavaScript executes
Affected Code:
app-webrtc.js #62ff
var id = "panel" + Math.round(Math.random()*999999999);
$("body").append("<div id='" + id + "' class='videoPanel'><video></video><div
class='videoPanelActions'><div class='videoName'>" + (me ? "You" :
userdisplay)
+ "</div><div class='videoHangup'>End</div></div></div>");
var videoPanel = $("#" + id);
Result:
<div class="videoPanelActions"><div class="videoName"><iframe
onload="alert(1)">&lt;/div&gt;&lt;div
class='videoHangup'&gt;End&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;</iframe></div></d
iv>
It is recommended to fix the vulnerability by using the escapeText() method on the
userdisplay variable prior to echoing it:
$("body").append("<div id='" + id + "' class='videoPanel'><video></video><div
class='videoPanelActions'><div class='videoName'>" + (me ? "You" :
escapeText(userdisplay))
+ "</div><div class='videoHangup'>End</div></div></div>");
var videoPanel = $("#" + id);
In the long run, it should be considered to use a JS MVC framework with auto-escaping
to build the UI. A recommendation for a fitting and secure JSMVC framework is
mentioned in the conclusion.
Note: Following our report, this issue was fixed in Release 0.16.
SR-01-002 XSS via unfiltered Display Name in Call Notification (Critical)
There is no proper escaping of the display name after it has been show in the call
notification. An attacker can abuse this by first setting their own display name to be a
malicious HTML string, and, secondly, calling the victim. Then and there, HTML and
injected JavaScript will execute upon being rendered as part of the call notification.
Steps to reproduce:
1. Log in with user A
2. Login in with user B (malicious display name)
3. Have user B call user A
4. JavaScript executes
Affected Code:
app-view.js #1041ff
var icon = appcore.list[appcore.listHash[data.target]].avatar ||
"img/noavatar.png";
var name = appcore.list[appcore.listHash[data.target]].name ||
appcore.list[appcore.listHash[data.target]].displayname;
newNotification(icon, "Call from " + name, name + " is rining you..", 0, false);
startTitleAlert("CALL | Subrosa");
app-view.js #894ff
title = $("#htmlEscape").html(title).text();
content = $("#htmlEscape").html(content).text();
Result:
<div class="hide" id="htmlEscape"><svg onload="alert(4)"> is rining
you..</svg></div>
It is recommended to escape the value of the variable name using the global method
escapeText():
name = escapeText(name);
newNotification(icon, "Call from " + name, name + " is rining you..", 0, false);
Note: After we communicated this finding, the issue was fixed in Release 0.16.
SR-01-004 XSS via unfiltered Display Name in online Notification (Critical)
When pre-rendered for online-notifications, the display name is not being escaped
properly. This gives an attacker the possibility to execute arbitrary JavaScript in the
victim’s browser by simply going online. An obligatory condition is that the attacker is a
contact of the victim.
Steps to reproduce:
1. Log in with a user A
2. Make sure that a user B is a contact of the user A
3. Log in with the user B (malicious display name)
4. JavaScript executes
Affected Code:
app-view.js #1095ff
var icon = appcore.list[appcore.listHash["conv" + sortUID(data.uid,
appcore.uid)]].avatar || "img/noavatar.png";
newNotification(icon, data.displayname + " is online",
statusText[data.newStatus], 5000, true);
app-view.js #894ff
title = $("#htmlEscape").html(title).text();
content = $("#htmlEscape").html(co