Penetration Test Report (RadicallyOpenSecurity): 2022 CodeReview Padlock password manager v1.2

Penetration Test Report
Padloc
V 1.2
Amsterdam, August 14th, 2022
Public
Document Properties
Client Padloc
Title Penetration Test Report
Targets Padloc App/PWA
Padloc Server
Padloc Browser Extension
Padloc Tauri App
Padloc Cordova App
Version 1.2
Pentesters Tillmann Weidinger, Fabian Freyer
Authors Tillmann Weidinger, Fabian Freyer, Stefan Vink, Tillmann Weidinger
Reviewed by Stefan Vink
Approved by Melanie Rieback
Version control
Version Date Author Description
0.1 May 27th, 2022 Tillmann Weidinger, Fabian Initial draft
Freyer
0.2 May 31st, 2022 Stefan Vink Reviewed
1.0 May 31st, 2022 Tillmann Weidinger, Fabian Final version
Freyer
1.1 August 10th, 2022 Tillmann Weidinger Retest
1.2 August 14th, 2022 Stefan Vink Reviewed Retest
Contact
For more information about this document and its contents please contact Radically Open Security B.V.
Name Melanie Rieback
Address Science Park 608
1098 XH Amsterdam
The Netherlands
Phone +31 (0)20 2621 255
Email info@radicallyopensecurity.com
Radically Open Security B.V. is registered at the trade register of the Dutch chamber of commerce under number 60628081.
Table of Contents
1 Executive Summary 4
1.1 Introduction 4
1.2 Scope of work 4
1.3 Project objectives 4
1.4 Timeline 5
1.5 Results In A Nutshell 5
1.5.1 Findings by Retest State 5
1.6 Summary of Findings 5
1.6.1 Findings by Threat Level 6
1.6.2 Findings by Type 7
1.7 Summary of Recommendations 7
2 Methodology 8
2.1 Planning 8
2.2 Risk Classification 8
3 Reconnaissance and Fingerprinting 10
4 Findings 11
4.1 PDL-001 — After Locking The Application Secrets Retain in Memory 11
4.2 PDL-008 — Email Template Injection 13
4.3 PDL-004 — Privacy Concerns for Password Audit 15
4.4 PDL-006 — PostgreSQL Certificate Validation Disabled 16
4.5 PDL-007 — HMAC Verification is not Constant Time 18
5 Non-Findings 20
5.1 NF-002 — HTML and Markdown Content is Properly Sanitized 20
6 Future Work 21
7 Conclusion 22
Appendix 1 Testing team 24
1 Executive Summary
1.1 Introduction
Between March 23, 2022 and May 27, 2022, Radically Open Security B.V. carried out a penetration test for Padloc
This report contains our findings as well as detailed explanations of exactly how ROS performed the penetration test.
1.2 Scope of work
The scope of the penetration test was limited to the following target(s):
• Padloc App/PWA
• Padloc Server
• Padloc Browser Extension
• Padloc Tauri App
• Padloc Cordova App
The scoped services are broken down as follows:
• Auditing application component: 8 days
• Auditing Cordova component of Padloc: 2 days
• Auditing Tauri component of Padloc: 2 days
• Auditing Web extensions: 4-5 days
• Project management, coordination and review: 2 days
• Retest and fix verification before publication: 1-2 days
• Total effort: 19 - 21 days
1.3 Project objectives
ROS will perform a penetration test of the Padloc Mono repository with Padloc in order to assess the security of the
scoped packages. To do so ROS will access the V4 branch of the Padloc repository (https://github.com/padloc/padloc/
tree/v4) and guide Padloc in attempting to find vulnerabilities, exploiting any such found to try and gain further access
and elevated privileges.
4 Radically Open Security B.V.
Public
1.4 Timeline
The Security Audit took place between March 23, 2022 and May 27, 2022.
1.5 Results In A Nutshell
Input sanitization issues were found in the invitation email system PDL-008 (page 13) , which could be used to trick
new and existing users to visit credential stealing phishing sites. Network adversaries would be able to intercept and
modify database changes PDL-006 (page 16) and could also play a role in the tracking of Padloc users PDL-004
(page 15) .
The architectural design choices of Padloc limit the capabilities for wiping secrets in the device memory PDL-001 (page
11) . This is a general constraint of web applications.
An issue regarding a possible timing oracle for session tokens from a previous security audit was found to be improperly
fixed PDL-007 (page 18).
1.5.1 Findings by Retest State
Resolved (3)
Accepted Risk (2)
40.0%
60.0%
1.6 Summary of Findings
ID Type Description Threat level
PDL-001 Incomplete Secret The password and master secret are kept in memory after Elevated
Removal locking the application.
Executive Summary 5
PDL-008 Improper Input It was found possible to inject arbitrary HTML into email Elevated
Sanitization templates sent for organization invites.
PDL-004 Information Disclosure The optional password audit feature has several privacy Moderate
implications which requires proper documentation or code
changes.
PDL-006 Improper Certificate The PostgreSQL connection is not validating TLS Moderate
Validation certificates, allowing for Machine in the Middle attacks.
PDL-007 Information Disclosure The HMAC verification function is not implemented in Low
constant time and leaks information through timing side
channel.
1.6.1 Findings by Threat Level
Elevated (2)
Moderate (2)
20.0%
Low (1)
40.0%
40.0%
6 Radically Open Security B.V.
Public
1.6.2 Findings by Type
Information disclosure (2)
Incomplete secret removal (1)
20.0%
Improper input sanitization (1)
Improper certificate validation (1)
40.0%
20.0%
20.0%
1.7 Summary of Recommendations
ID Type Recommendation
PDL-001 Incomplete Secret • Add documentation clearly stating the risk.
Removal • Investigate desktop application features for secure memory wipe and
secret storage.
• Consider removing this feature as it suggests false sense of security.
PDL-008 Improper Input • Sanitize username and organization before passing them into the
Sanitization email template.
• Reduce available characters for usernames and organizations.
PDL-004 Information Disclosure • Make this feature configurable. (has been implemented during the
engagement).
• Consider creating bloom filter based solutions.
• Inform the user about the data transmission to Cloudflare.
• Consider TLS pinning on the platforms that support it.
PDL-006 Improper Certificate • Set rejectUnauthorized to true .
Validation
PDL-007 Information Disclosure • Implement a double HMAC based string comparison.
Executive Summary 7
2 Methodology
2.1 Planning
Our general approach during penetration tests is as follows:
1. Reconnaissance
We attempt to gather as much information as possible about the target. Reconnaissance can take two forms:
active and passive. A passive attack is always the best starting point as this would normally defeat intrusion
detection systems and other forms of protection afforded to the app or network. This usually involves trying to
discover publicly available information by visiting websites, newsgroups, etc. An active form would be more
intrusive, could possibly show up in audit logs and might take the form of a social engineering type of attack.
2. Enumeration
We use various fingerprinting tools to determine what hosts are visible on the target network and, more
importantly, try to ascertain what services and operating systems they are running. Visible services are researched
further to tailor subsequent tests to match.
3. Scanning
Vulnerability scanners are used to scan all discovered hosts for known vulnerabilities or weaknesses. The results
are analyzed to determine if there are any vulnerabilities that could be exploited to gain access or enhance
privileges to target hosts.
4. Obtaining Access
We use the results of the scans to assist in attempting to obtain access to target systems and services, or to
escalate privileges where access has been obtained (either legitimately though provided credentials, or via
vulnerabilities). This may be done surreptitiously (for example to try to evade intrusion detection systems or rate
limits) or by more aggressive brute-force methods. This step also consist of manually testing the application
against the latest (2017) list of OWASP Top 10 risks. The discovered vulnerabilities from scanning and manual
testing are moreover used to further elevate access on the application.
2.2 Risk Classification
Throughout the report, vuln