Penetration Test Report (Cure53): pentest report tuf

Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Pentest-Report TUF/Notary 05.-06.2018
Cure53, Dr.-Ing. M. Heiderich, M. Wege, MSc. N. Krein, MSc. N. Kobeissi,
Dipl.-Ing. A. Inführ, BSc. J. Hector
Index
Introduction
Scope
Test Methodology
Part 1. Manual Code Audit
Part 2. Code-Assisted Penetration Testing
Identified Vulnerabilities
TUF-01-001 General: Input manipulation permanently breaks collections (Medium)
TUF-01-002 General: Manipulated version permanently breaks collections (Low)
Miscellaneous Issues
TUF-01-003 Protocol: Effective security slightly reduced in some situations (Info)
TUF-01-004 Client: Path traversal in collection initialization (Info)
Conclusions
Introduction
“The Notary project comprises a server and a client for running and interacting with
trusted collections. See the service architecture documentation for more information.
Notary aims to make the internet more secure by making it easy for people to publish
and verify content.
We often rely on TLS to secure our communications with a web server which is
inherently flawed, as any compromise of the server enables malicious content to be
substituted for the legitimate content.”
From https://github.com/theupdateframework/notary
This report documents the findings of a security assessment targeting the TUF/Notary
software compound. The project, which comprised a source code audit and a classic
penetration test, was carried out by Cure53 in 2018 and yielded only four security-
relevant findings. It must be underlined that the assessment of the TUF/Notary scope
was requested by The Linux Foundation (TLF) / CNCF. In terms of resources, a budget
of eighteen days was allocated to the project, which was promptly completed by seven
Cure53, Berlin · 08/07/18 1/12
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
testers from the Cure53 team. Proceeding on schedule, the two components of the
dedicated audit and the more classic series of penetration tests took place in late May
and early-to-mid June of 2018.
As for the approach, this assessment relied on a so-called white-box methodology.
Under this premise, Cure53 could take advantage of all TUF/Notary sources. This was
the sole sensible path as the tested components of the TUF/Notary project are openly
available, so impersonating an attacker must account for this context. It is also quite a
standard operating procedure for this kind of projects for the Cure53 team to employ a
two-fold mixed-methods approach. This means that both a code audit and penetration
testing were incorporated to the assessment tasks in order to ensure reaching a
comprehensive and maximum coverage. In addition, Cure53 also set up a shared cloud
VM to work with and ran the software locally on various instances. Further, the available
documentation was studied in great detail, especially since the scope was rather
complex and often difficult to grasp. More details on the matters related to the steps and
methods can be found in the Test Methodology section.
While the Cure53 team was briefed on the scope as well as on the threat- and risk-
models applicable to the TUF/Notary project, the white-box premise also allowed for
open communications and a continued dialogue between the in-house team maintaining
the TUF/Notary project and the Cure53 testers. Throughout the project the exchanges
were done via email and a shared document was created and updated to guarantee that
mutual understanding of the project’s goals is maintained and any issues around
coverage are addressed “on the go”. As already noted, four security-relevant findings
were unveiled as a result of the Cure53 team’s efforts. The issues were documented
under separate categories of actual vulnerabilities and general weaknesses, with two
results assigned to each class. One of the issues may be seen as a duplicate since it
was already reported by NCC in 20151. The reason for its inclusion in this report is that it
is yet to be fully tackled on all affected entities. Nevertheless, to foreshadow the
conclusions, it should be said that the overall results mirror a rather positive impression
gained by Cure53 during previous assessments of various TLF/CNCF projects built on
top of the Go-codebase. In the following sections, the report will first elaborate on the
scope by supplying links for the audited Github repository contents (Notary, TUF and
TAPs). In the ensuing sections, first the test coverage notes are provided and then all
four spotted issues are discussed.
Finally, the Report closes with a conclusion, furnishing a broader verdict on the general
security posture of the TUF/Notary project in light of the Cure53’s findings.
1https://github.com/theupdateframework/notary/blob/mas...r_notary_audit_2015_07_31.pdf
Cure53, Berlin · 08/07/18 2/12
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Scope
• TUF / Notary
◦ https://github.com/theupdateframework/notary
◦ https://github.com/theupdateframework/tuf
◦ https://github.com/theupdateframework/taps
Test Methodology
This section describes the methodology used during the source code audit and
penetration testing of the TUF/Notary project. The test was divided into two phases with
specific two-fold goals and focal points in scope. The first phase concentrated mostly on
manual source code reviews. These reviews aimed at spotting insecure code constructs
with a capacity to lead to memory corruption, information leakage or other similar flaws.
The second phase of the test was dedicated to classic penetration tests which examined
whether the security promises made by TUF/Notary in fact hold in the real-life attack
scenarios.
Part 1. Manual Code Audit
A list of items below details the key steps undertaken during the first part of the test,
specifically the part which entailed the manual code audit against the sources of the
TUF/Notary software in scope. This is to underline that in spite of the relatively low
number of findings, substantial thoroughness characterized the completion of the
assessment and considerable efforts have gone into this test.
• The source code of the Notary client and server applications was checked for
any cryptographic implementation flaws. It was also examined in relation to the
general soundness of the design. The code was found to be of an exceptionally
high quality, boasting an impressively clear and complete documentation and a
comprehensive test suite.
• The threat model, security model and protocol documents for the Notary project
were reviewed. An issue was found in which the effective security of the Notary
deployments did not exceed that of the traditional TLS 1.2/TLS 1.3 deployments
in most use-cases. The problem stems from strong reliance on the Notary server
never being compromised, even just temporarily. This is a minor design note
which is already recognized by the developers in the existing threat model.
• The Notary application uses the gorm library to safely store the application in the
user-defined database. The library was installed locally and tested to discover
potential issues but no flaws were found.
Cure53, Berlin · 08/07/18 3/12
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
• The exposed HTTP Go routes of the Notary server were analyzed for potential
security issues regarding the handling of user-controlled variables. One potential
local file inclusion sink has been proven to be properly protected through a
verification of the passed variable’s validity.
• One of the root causes for TUF-01-001 seems to be the inability to retrieve the
root.json. This has been further investigated to determine whether the underlying
cause of the questionable behavior could have broader security implications.
This was driven by the fact that the root.json is a key component. However, the
root cause could not be identified and -given the limited time availab