Penetration Test Report (RadicallyOpenSecurity): 2023 The Tor Project Pentest Report 2023 1.0

Penetration Test Report
The Tor Project
V 1.0
Amsterdam, August 29th, 2023
Confidential
Document Properties
Client The Tor Project
Title Penetration Test Report
Targets Clients (Android, Tor Browser)
Exit relay (Tor core)
Exposed-services (metrics server, SWBS, Onionoo API)
Infrastructure compenents (monitoring & alert)
Testing/profiling tools
Version 1.0
Pentesters Dennis Brinkrolf, Stefan Grönke
Authors Dennis Brinkrolf, Marcus Bointon
Reviewed by Marcus Bointon
Approved by Melanie Rieback
Version control
Version Date Author Description
0.1 August 13th, 2023 Dennis Brinkrolf Initial draft
0.2 August 23rd, 2023 Marcus Bointon Review
1.0 August 29th, 2023 Marcus Bointon 1.0
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 5
1.1 Introduction 5
1.2 Scope of work 5
1.3 Project objectives 5
1.4 Timeline 6
1.5 Results In A Nutshell 6
1.6 Summary of Findings 7
1.6.1 Findings by Threat Level 9
1.6.2 Findings by Type 10
1.7 Summary of Recommendations 10
2 Methodology 13
2.1 Planning 13
2.2 Risk Classification 13
3 Findings 15
3.1 TOR-008 — onbasca – CSRF via GET allows adding bridges on production configuration 15
3.2 TOR-021 — metrics-lib – Denial of service in DescriptorImpl getRawDescriptorBytes
via descriptor file 17
3.3 TOR-022 — tor-android-service – Use of unmaintained third-party components 20
3.4 TOR-025 — Tor client – Off-by-one in read_file_to_str_until_eof 21
3.5 TOR-028 — sbws - HTTPS Downgrade Attack via HTTP redirects 23
3.6 TOR-002 — sbws – Limited File read/write due to missing permissions check via symlinks 24
3.7 TOR-003 — sbws – HTTPS enforcement can be bypassed with subdomains 26
3.8 TOR-004 — sbws – assert statements in code flow 27
3.9 TOR-005 — sbws – Arbitrary file read/write via symlinks due to time-of-check-to-time-of-use 28
3.10 TOR-009 — onbasca – No security headers set 30
3.11 TOR-012 — exitmap – Limited file write due to insecure permissions via symlinks 31
3.12 TOR-013 — helper-scripts – Newline injection in badconf-entry due to insecure fingerprint
validation 32
3.13 TOR-014 — helper-scripts – Limited file read in badconf-entry due to insecure fingerprint
validation via symlinks 34
3.14 TOR-016 — oonionoo – Potential denial of service on onionoo.torproject.org via search
parameter 35
3.15 TOR-024 — Tor client – Missing sanity checks in pem_decode 37
3.16 TOR-015 — Infrastructure - Missing .htaccess configuration on survey.torproject.org leaks data 38
3.17 TOR-017 — website – Outdated Jetty version on metrics.torproject.org 40
4 Future Work 42
5 Conclusion 44
Appendix 1 Testing team 46
Confidential
1 Executive Summary
1.1 Introduction
Between April 17, 2023 and August 13, 2023, Radically Open Security B.V. carried out a penetration test for The Tor
Project. 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 code audit was limited to the following targets:
• Clients (Android, Tor Browser)
• Exit relay (Tor core)
• Exposed-services (metrics server, SWBS, Onionoo API)
• Infrastructure compenents (monitoring & alert)
• Testing/profiling tools
The scoped services are broken down as follows:
• Code audit: 15-20 days
• Reporting: 2-4 days
• (Optional) retest: 2-5 days
• PM/Review: 2 days
• Total effort: 21 - 31 days
1.3 Project objectives
ROS's objective was to perform a code audit of software changes made during the grant's lifecycle to make the Tor
network faster and more reliable for users in Internet-repressive places. To do so, ROS will audit the code changes and
guide the Tor Project in attempting to find vulnerabilities, exploiting any such found to try to gain further access and
elevated privileges.
Executive Summary 5
1.4 Timeline
The security audit took place between April 17, 2023 and August 13, 2023.
1.5 Results In A Nutshell
During this crystal-box penetration test we found 1 High, 4 Moderate, 10 Low and 2 Unknown-severity issues.
The most severe issue is a high-severity CSRF vulnerability in the Onion Bandwidth Scanner (onbasca) TOR-008 (page
15). By exploiting this issue, pre-authenticated attackers can inject their Tor bridges into the database that may be
used to daemonize the hosted instance or to carry out further attacks. We noticed that no security headers are set in
TOR-009 (page 30), leaving a broad attack surface exposed for common client-side security issues.
ROS audited the Simple Bandwidth Scanner (sbws), a Tor bandwidth scanner that generates bandwidth files to be
used by Directory Authorities, and found 1 moderate and 4 low-severity issues. The moderate issue allows attackers
to perform an HTTPS downgrade attack to HTTP in TOR-028 (page 23), potentially allowing malicious exit nodes to
leak secret tokens configured only for some destinations. In TOR-003 (page 26), attackers can bypass the HTTPS
enforcement of the destination URL by using subdomains. In both cases, attackers can configure the destination URLs,
which is a limited attacker scenario, but that may change as the project evolves. We found two vulnerabilities in TOR-002
(page 24) andTOR-005 (page 28) that allow local attackers to read and write files with the privileges of the sbws
user if the attackers are in the same Unix group. In issue TOR-004 (page 27), we documented finding 92 assert
statements in the code, which open up a wide range of potential denial-of-service attacks.
We found only two issues while deep-diving the code of the publicly exposed services oonionoo.torproject.org
and metrics.torproject.org. The oonionoo service suffers from a potential DoS vulnerability due to its use
of the StringBuilder.append method, which can quickly cause the JVM to overconsume heap memory space
in TOR-016 (page 35). However, this is not exploitable due to the limited GET request URI length, making this a
low-severity finding. The metrics service runs on an outdated Jetty version from 2015 that suffers from publicly known
security vulnerabilities such as CVE-2021-28165 in TOR-017 (page 40). The impact of the known vulnerabilities
ranges from pre-auth DoS to remote code execution. Due to time constraints, this issue could not be followed up and
was consequently rated as unknown severity.
By accident, ROS came across the survey.torproject.org service. It quickly became evident that LimeSurvey
version 6.1.6+230703 was being used without htaccess support enabled on web server TOR-015 (page 38). Since
this service is out of scope, it was not feasible to follow this lead further, and the issue is rated unknown severity.
However, aside from already leaking information, attackers may achieve remote code execution by accessing the PHP
vendor folder located on the web root.
Much attention was paid to the Tor client and Tor Android browser modifications. In the Tor client, we found off-by-one
and out-of-bounds vulnerabilities. The off-by-one vulnerability in TOR-025 (page 21) was rated moderate, while
the out-of-bounds one was rated low in TOR-024 (page 37). In both cases, the likelihood that attackers can exploit
these vulnerabilities is minimal. The tor-android-service uses C code dating from 2012 from unmaintained third-party
vendors in TOR-022 (page 20). The tor-android-service is shipped with the Tor browser for Android, and a malicious
6 Radically Open Security B.V.
Confidential
application could exploit vulnerabilities within the tun2socks module to deanonymize the user or to run arbitrary code.
Due to the risk potential, this finding was rated as moderate.
The Tor project implemented a Java API fetching Tor descriptors from various sources like cached descriptors, Directory
Authorities, and mirror