Penetration Test Report (Cure53): pentest report bitwarden

Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Pentest-Report Bitwarden Password Manager 11.2018
Cure53, Dr.-Ing. M. Heiderich, Dipl.-Ing. A. Inführ, MSc. N. Kobeissi, N. Hippert, M. Kinugawa
Index
Index
Introduction
Scope
Identified Vulnerabilities
BWN-01-001 Extension: Autofill only checks top-level domain (Medium)
BWN-01-006 Desktop/Web: RCE/XSS via login URL (Critical)
BWN-01-007 Crypto: Inadequate parameters for master password (High)
BWN-01-008 Crypto: Bitwarden obtaining encryption keys for organizations (Critical)
BWN-01-010 Crypto: Master password change ineffective after device theft (High)
BWN-01-011 Crypto: Integrity checks can be skipped (Critical)
Miscellaneous Issues
BWN-01-002 Desktop: Electron nodeIntegration flag enabled in renderer (Info)
BWN-01-003 Desktop: Missing contextIsolation security-flag for Electron (Info)
BWN-01-004 Desktop: Bypassable CSP rules in place (Info)
BWN-01-005 Backend: XSS on cdn.bitwarden.com via attachments (Info)
BWN-01-009 Crypto: PBKDF2 iteration count configuration unnecessary (Info)
Conclusions
Cure53, Berlin · 11/08/18 1/17
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Introduction
“The easiest and safest way for individuals, teams, and business organizations to store,
share, and sync sensitive data.”
From https://bitwarden.com/
This report documents the results of a security assessment targeting the Bitwarden
compound. Carried out by Cure53 in autumn 2018, this project yielded eleven security-
relevant findings.
In scope of this project were several components of the Bitwarden password manager.
Specifically, Cure53 was tasked with investigating the core application, browser
extension, Electron application, web application and selected related libraries. These
items have been examined through a range of approaches, namely a penetration test, a
source code audit, and a connected review of the cryptographic premise. More to the
point, the methodology chosen for completing this test was white-box, meaning that
Cure53 had access to everything of relevance for reaching good coverage. It needs to
be noted that the all of the software’s code is available as open source, thus making
white-box the natural choice.
In terms of resources, five members of the Cure53 were involved in this project, which
took place in late October and early November of 2018. The testing team was allocated
a time budget of sixteen days of assessing the security of the Bitwarden scope which, as
already noted above, entailed clients (web app, Electron app, browser extension), the
backend code and the implemented cryptographic scheme.
The project progressed in a timely and efficient manner. During the assessment, the
communication between Cure53 and the Bitwarden maintainers was done on a shared
Slack channel. It must be underlined that the Bitwarden team handled test-related
requests from Cure53 in a professional and prompt way, leading to the test’s productivity
and good coverage. In addition, as the quality of the code - in terms of readability and
easy of assessment - was exceptional, Cure53 found it simple to accomplish the
project’s goals in the time available.
All discoveries were live-reported to make it possible for the Bitwarden team to pose
questions and receive feedback prior to the write-up process. As already mentioned,
eleven findings have been documented by the Cure53 team. These could be divided into
a category of vulnerabilities (with six issues) and more general weaknesses (further five
findings). Initially, three issues were ascribed with the highest-possible “Critical” ranking.
Two of those originated from the crypto audit and one was a classic Remote Code
Execution (RCE) that tends to be found in numerous Electron-based applications.
Cure53, Berlin · 11/08/18 2/17
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Following a discussion with the in-house team at Bitwarden, it was established that one
of the cryptography-related “Critical”-ranked issues was actually a false alert. Taking this
into consideration means that two issues marked as “Critical” remain as viable threats
that need to be addressed as a matter of urgency.
In the following sections, the report will first comments on the details regarding scope
and then discusses all findings on a case-by-case basis, furnishing both technical
descriptions and relevant advice on mitigation strategies going forward. In light of the
findings, Cure53 issues a broader verdict pertaining to the security posture found on the
investigated Bitwarden items in scope.
Scope
• Bitwarden Open Source Password Management
◦ Bitwarden Core Application, written in C# & SQL
▪ https://github.com/bitwarden/core/tree/v1.25.0
◦ Bitwarden Browser Extension, written in TypeScript & JavaScript
▪ https://github.com/bitwarden/browser/tree/v1.33.3
◦ Bitwarden Electron-based Desktop Application, written in TypeScript & JavaScript
▪ https://github.com/bitwarden/desktop/tree/v1.9.0
◦ Bitwarden Web Application, written in TypeScript & JavaScript
▪ https://github.com/bitwarden/web/tree/v2.4.0
◦ Bitwarden TypeScript Library, written in TypeScript & JavaScript
▪ https://github.com/bitwarden/jslib/tree /
2f6426deb470b71838b51c52587929ac64d428bf
◦ Several accounts were provided so that Cure53 could get access to Bitwarden’s paid
and organization-linked features as well.
◦ Further, Cure53 was furnished with detailed documentation about the threat model
and security promises to make sure the testing can be executed in full alignment to
these.
Cure53, Berlin · 11/08/18 3/17
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
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. BWN-01-001) for the purpose of facilitating any
future follow-up correspondence.
BWN-01-001 Extension: Autofill only checks top-level domain (Medium)
The Bitwarden WebExtension implements an “Autofill” feature for domains which have
credentials stored in the vault. It was discovered that the current design only checks the
top URL but factually auto-fills forms in iframes as well. This takes place even if they are
hosted on a different domain. As a consequence, the credentials of the top domain are
leaked to third-party domains which can store and abuse them.
Steps to reproduce:
1. Submit a form on example.com.
2. Store the credentials in the vault.
3. Open another HTML page on example.com in a way that iframes example2.com.
4. Note that example2.com has the same form as example.com.
5. The Autofill feature will enter the credentials present for example.com in the form
belonging to example2.com.
The content script injected in example2.com sends a collectPageDetailsResponse
message to the background script, with the latter containing a tab property. Additionally,
it specifies a details property, which hosts information about the current document, for
instance including data on its URL (e.g. example2.com/test.html). The Autofill service
handling this message does not use the URL of the detail object but instead checks the
tab URL. As the tab URL is pointing to “example.com”, the credentials are retrieved but
then sent to the content script in the iframe.
File:
src/content/autofill.js
Code:
chrome.runtime.onMessage.addListener(function (msg, sender, sendResponse) {
if (msg.command === 'collectPageDetails') {
var pageDetails = collect(document);
var pageDetailsObj = JSON.parse(pageDetails);
chrome.runtime.sendMessage({
command: 'collectPageDetailsResponse',
Cure53, Berlin · 11/08/18 4/1