Penetration Test Report (Cure53): pentest report remembear

Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Pentest-Report RememBear 08.2017
Cure53, Dr.-Ing. M. Heiderich, Dipl.-Ing. Abraham Aranguren, Dipl.-Ing. Alex Inführ, BSc.
Christoper Kean, Norman Hippert, Nadim Kobeissi
Index
Introduction
Scope
Identified Vulnerabilities
RMB-01-001 Mac/iOS/Android/Win: Faulty domain detection leaks password (High)
RMB-01-006 Android: Denial of Service issue in Login Model (Low)
RMB-01-007 Mac: RememBear app DoS via URL handler (Medium)
RMB-01-010 Mac/Windows: Denial of Service via RememBear Helper listener (Low)
Miscellaneous Issues
RMB-01-002 Mac: Insecure ATS configuration could lead to leaks/MitM (Info)
RMB-01-003 API: Timing Side-Channel on SRP Authentication (Low)
RMB-01-004 iOS: Copied login passwords are readable by other apps (Low)
RMB-01-005 Mac: RememBear and RememBearHelper are not sandboxed (Info)
RMB-01-008 Windows: Password save dialog uses wrong domain (Low)
RMB-01-009 Windows: DisposableString provides no added Protection (Info)
RMB-01-011 Rust: Passphrase Generation and Validation Recommendations (Info)
RMB-01-012 Public Key Protocol Recommendations for Browser Extensions (Info)
RMB-01-013 Custom TLS Protocol Recommendations (Info)
RMB-01-014 WebExtension: DOM Clobbering can influence Content Script (Info)
Conclusions
Cure53, Berlin · 11/17/17 1/14
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Introduction
This report documents the findings of a penetration test and source code audit against
the RememBear password manager. The project was carried out by Cure53 in mid-
August 2017 and yielded a total of fifteen security-relevant results.
It should be noted that this security assignment had a very wide scope. The project was
granted a time budget of twenty-five days, which was then split into six separate
modules described below in the “Scope” section. Besides auditing sources and
performing a classic penetration test, the Cure53 team engaged in a thorough
cryptographic review of the RememBear software. The latter was aimed at verifying
whether all cryptographic components can be assessed as well-written and working as
intended.
Based on the required expertise and skillsets, six members of the Cure53 team were
involved in the completion of this project. As for the approach, a white-box methodology
was chosen and the Cure53 testers received access to all relevant source code
materials as well as binary builds. Additional information and feedback was exchanged
quickly between the testers and the RememBear in-house team to ensure a good test
coverage. This was assisted by having a dedicated Slack channel, which ultimately
helped overcome arising technical issues in a prompt manner. A good communication
setup turned out indispensable, as the initial phase of the project needed to address
broken builds. After this slightly bumpy start, the tests proceeded smoothly and
efficiently.
As already indicated, the Cure53 testers managed to spot fifteen security risks. The
issues were further categorized into five vulnerabilities and ten general weaknesses. It is
important to emphasize that not a single finding warranted a “Critical” ranking in terms of
severity or impact, while only two problems were deemed to have a “High” level of
security implications. The report will now shed light on the detailed aspects of the scope,
particularly in terms of how six sub-modules were developed. It then proceeds to a case-
by-case discussion of each finding, offering technical descriptions and mitigation advice
when applicable. The closing paragraphs are devoted to concluding remarks and
impressions about the general security of the RememBear product.
Note: For this public version of the RememBear pentest report, several code snippets,
screenshots and attack examples have been removed, as requested by the TunnelBear
team.
Cure53, Berlin · 11/17/17 2/14
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Scope
• Module 1: OSX Client
◦ Code Audits and Penetration Tests against OSX Mobile App & available Sources.
Relevant code and binaries were made available to Cure53.
• Module 2: iOS App
◦ Code Audits and Penetration Tests against iOS Client & available Sources. .
Relevant code and binaries were made available to Cure53.
• Module 4: Android App
◦ Code Audits and Penetration Tests against Android Mobile App & available Sources.
Relevant code and binaries were made available to Cure53
• Module 5: Browser Extension
◦ Code Audits and Penetration Tests against Browser Extension & available Sources.
Both code and binaries were made available to Cure53.
• Module 3: Windows Client
◦ Code Audits and Penetration Tests against Windows Client & available sources.
• Module 6: Backend, API & Crypto
◦ Code Audits of the available Scala Backend Code & Rust Sources, API Tests.
Relevant code and binaries were made available to Cure53.
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. RMB-01-001) for the purpose of facilitating any
future follow-up correspondence.
RMB-01-001 Mac/iOS/Android/Win: Faulty domain detection leaks passes (High)
As any password manager, RememBear is evaluates each loaded URL and matches it
against stored vault items. If a user has saved a username and password combination
for the URL, the application offers a possibility to automatically fill and submit the
credentials. However, it was discovered that the currently deployed algorithm for URL
parsing is faulty. Specifically, the algorithm attempts to detect and remove top level
domains to extract the host part. This is because the current design treats subdomains
in the same way as the main domain.
It can be observed that since the algorithm is removing up to two top level domains, it
actually treats victim.co.uk, victim.com, victim.de and even test.victim.co.at as if they
were identical. By this logic, it proposes to autofill the same user-credentials for all these
Cure53, Berlin · 11/17/17 3/14
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
domains as if they were equivalent. This behavior could trick a user into revealing their
credentials, as they may end up submitting them to an attacker-controlled website.
The described behavior can be found on the Windows and Mac platforms in the Chrome
extension, as well as in the vault software. Moreover, it is also present in both the mobile
RememBear browser application and in the native browser.
In order to solve this problem, the entire hostname should ideally be used for the
process of credential storage matching. This is the simplest solution and would
completely eliminate attacks against the core logic employed in the hostname matching
algorithm at present. If this approach is not feasible, it is recommended to review the
domain validation process and ensure that the last two or three components of the
hostname are used, making the process dependent on the received value.
To clarify, some examples on handling the matter are specified next.
• If a domain like victim.co.uk or www.victim.co.uk is received, the entire three last
sections of the hostname should be used, i.e. victim.co.uk.
• If a domain like victim.com or www.victim.com is received, then the last two
sections should be sufficient, i.e. victim.com.
Finally, if neither of these approaches can be implemented, another option would be to
review the domain validation process and ensure that ccSLDs are detected properly.
Although there is no complete list of ccSLDs available, a good starting point can be the
publi