Penetration Test Report (RadicallyOpenSecurity): 2020 CodeReview COVID 19 notification app back end v1.1

Cryptographic Framework and
Back-end Security Evaluation
Ministerie van Volksgezondheid,
Welzijn en Sport
Dutch COVID-19 Notification App
V 1.1
Diemen, August 28th, 2020
Confidential
Document Properties
Client Ministerie van Volksgezondheid, Welzijn en Sport
Title Cryptographic Framework and Back-end Security Evaluation
Targets The cryptographic framework of the Dutch COVID-19 notification app
The code of the Dutch COVID-19 notification app back-end
Version 1.1
Pentesters Tim Hummel, Tillmann Weidinger, Stefan Marsiske
Authors Tim Hummel, Stefan Marsiske, Patricia Piolon, Marcus Bointon, Melanie Rieback
Reviewed by Marcus Bointon, Patricia Piolon, Melanie Rieback
Approved by Melanie Rieback
Version control
Version Date Author Description
0.1 July 15th, 2020 Tim Hummel Initial draft
0.2 July 17th, 2020 Stefan Marsiske Added generic GAEN
section
0.3 July 21st, 2020 Tim Hummel Conclude initial crypto
framework evaluation
0.4 July 23rd, 2020 Patricia Piolon Review
0.5 August 5th, 2020 Tim Hummel New Dutch crypto
framework documents
0.6 August 11th, 2020 Tim Hummel Initial back-end evaluation
0.7 August 14th, 2020 Tim Hummel Continued back-end
evaluation
0.8 August 19th, 2020 Patricia Piolon Review
0.9 August 19th, 2020 Tim Hummel New updates
0.10 August 20th, 2020 Marcus Bointon Review
0.11 August 20th, 2020 Patricia Piolon Review
0.12 August 21st, 2020 Marcus Bointon, Patricia Expected final Review
Piolon, Tim Hummel
0.13 August 26th, 2020 Tim Hummel Additional code and
documentation updates
1.0 August 28th, 2020 Marcus Bointon, Patricia Review
Piolon, Melanie Rieback
1.1 August 28th, 2020 Patricia Piolon Fixed status error
Contact
For more information about this document and its contents please contact Radically Open Security B.V.
Name Melanie Rieback
Address Overdiemerweg 28
1111 PP Diemen
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 6
1.1 Introduction 6
1.2 Scope of Work 6
1.3 Project Objectives 6
1.4 Timeline 6
1.5 Results In A Nutshell 7
1.5.1 Visual Overview 10
1.5.1.1 Code Review Findings by Status 10
1.5.1.2 Unresolved Code Review Findings by Threat Level 10
1.5.1.3 Unresolved Code Review Findings by Type 11
2 Abbreviations and Terms Used in This Document 12
3 The GAEN Protocol Overview 13
3.1 The Protocol 13
3.1.1 The GAEN Architecture 14
3.1.2 GAEN in a Nutshell 14
3.1.3 Metadata 15
3.1.4 Transmission and Reception 16
3.1.5 Reporting 16
3.1.6 Contact Tracing 16
3.2 GAEN Attacks 17
3.2.1 Implementation Level Issues, Closed-Source Vendor-Controlled Basis 17
3.2.2 False Alert Injection Attacks 18
3.2.2.1 False Positive Contact Attacks by Re(p)laying or Manipulating Beacons 18
3.2.2.2 Impersonating the Back-end 19
3.2.2.3 Access to be Able to Upload Keys 19
3.2.3 Tracking Attacks 19
3.2.3.1 Installation and Updates Require Non-anonymous Accounts 19
3.2.3.2 De-anonymization Attack of Infected People 20
3.2.3.3 Possible Identification of Sending Device Type Through TX Power Value in the Metadata 20
3.2.3.4 Contact Data is Stored on the Phone 21
4 Dutch COVID-19 Notification App Cryptographic Framework 22
4.1 Underlying Technology GAEN Contact Tracing 22
4.2 Non-GAEN TEK Life Cycle 23
4.3 Other Keys 24
4.4 International Diagnosis Key Exchange 25
5 Back-end Code Review 27
5.1 Limitations of a Code Review 28
5.2 Looking for Potential Back-doors 29
5.3 List of Findings 29
5.3.1 NLC-019 — Third Party Authentication Provider Used 30
5.3.2 NLC-013 — Health Authority Employees Can Check If Keys Were Uploaded 31
5.3.3 NLC-002 — Developer Options To Switch Off Security Features 32
5.3.4 NLC-004 — RollingPeriod Not Limited To One Day 33
5.3.5 NLC-005 — It Is Possible to Update Diagnosis Keys With Future Dates 34
5.3.6 NLC-007 — Decoy Traffic Is Not Efficient 35
5.3.7 NLC-014 — Authorization Token Included in GET Parameter 36
5.3.8 NLC-017 — Databases have Insufficient Privileges Separation 37
5.3.9 NLC-018 — Signing Components Imply Running as Local Administrator 38
5.3.10 NLC-020 — Health Worker Authentication Token Is Valid For Several Hours and Not Rate-
Limited 39
5.3.11 NLC-022 — HSTS Header Not Set 40
5.3.12 NLC-028 — Timing Oracle in Signature Comparison 41
5.3.13 NLC-029 — AuthorizationCode is weak 42
5.3.14 NLC-001 — Deviation Between (API) Design and Implementation 43
5.3.15 NLC-003 — Database Credentials in Components That Do Not Require Them 44
5.3.16 NLC-008 — Database Stores Upload and Phone Call Times Etc. 45
5.3.17 NLC-009 — Log Messages Store Sensitive Information 46
5.3.18 NLC-010 — API Exceptions Are Too Verbose 48
5.3.19 NLC-012 — JWT Token Not Properly Validated 49
5.3.20 NLC-015 — Database Provision Default Setting Is To Generate Example Content 50
5.3.21 NLC-016 — Decoy Keys Can Largely Be Distinguished From Real Diagnosis Keys 51
5.3.22 NLC-021 — IccBackend API Allows CORS Requests From Any Source 52
5.3.23 NLC-023 — JWT Token Needlessly Contains Employee Information 53
5.3.24 NLC-025 — Old Diagnosis Keys Are Not Deleted 54
5.3.25 NLC-026 — Diagnosis Key Publishing Time Can Reveal the Time of the Phone Call 55
5.3.26 NLC-027 — Database Can Retain Data after Deletion 56
6 Conclusion 58
7 Bibliography 61
Appendix 1 Testing team 64
1 Executive Summary
1.1 Introduction
Radically Open Security has been contracted by the Ministry of Health, Welfare and Sport (Ministerie van
Volksgezondheid, Welzijn en Sport) to peer-review the Dutch cryptographic framework and perform a code review on the
CoronaMelder back-end code. Both reviews were time-boxed.
This report contains our analysis as well as detailed explanations of any findings discovered.
1.2 Scope of Work
The scope of the penetration test was limited to the following targets:
The cryptographic framework of the Dutch COVID-19 notification app, specifically the "Covid-19 Exposure Notification
Cryptografie raamwerk" document retrieved from [30] (hereafter called 'the Dutch Crypto Framework document').
The code of the Dutch COVID-19 notification app back-end, retrieved from [32]
1.3 Project Objectives
There were two objectives for this evaluation:
Peer review of the cryptographic basis for the Dutch COVID-19 notification app. We checked if the claims made in
the Dutch Crypto Framework document can be supported by the document itself and the supporting documentation. We
point out potential gaps.
Code review of the Dutch COVID-19 notification app back-end. We carried out a code and documentation review to
verify the implementation against the design. We point out relevant security differences, potential back doors, and any
other security findings.
1.4 Timeline
The security audit took place between July 9th and August 25th, 2020.
Both activities were initially time-boxed to a combined 16 days including reporting. We were allocated an extension of
maximum 12.5 days, which we only partially used. This was needed because we were required to spend a significant
amount of time accommodating the ongoing documentation and code changes occurring during our review.
6 Radically Open Security B.V.
Confidential
1.5 Results In A Nutshell
We began our audit with a peer-review of the Dutch Crypto Framework document. It builds upon the Google/Apple
Exposure Notification (GAEN) system, which has well established attack vectors and risks, some of which are inherent to
the underlying technology. These have not been fully addressed by Google or Apple - and to the best of our knowledge,
GAEN's security has never been fully audited or verified by an independent party.
The Dutch Crypto Framework document is a work in progress, and there are several shortcomings and points that are
not (yet) defined. A clear choice has been made for a key upload process that, in theory, allows the health authority
to link uploaded diagnosis keys to other personal data. This is a trade-off in order to prevent non-infected people from
uploading their