Penetration Test Report (Cure53): pentest report prometheus

Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Pentest-Report Prometheus 05.-06.2018
Cure53, Dr.-Ing. M. Heiderich, M. Wege, MSc. N. Krein, BSc. J. Hector,
Dipl.-Ing. A. Inführ, J. Larsson
Index
Introduction
Scope
Test Methodology
Part 1 (Manual Code Auditing)
Part 2 (Code-Assisted Penetration Testing)
Hardening Recommendations
General Security Recommendations
HTTP Security Headers
Content Security Policy & Beyond
Authentication / Authorization
Non-Idempotent Request Protection
Transport Security
Clients/metrics endpoint
API Endpoint
Admin GUI
Identified Vulnerabilities
PRM-01-001 Web: Prometheus lifecycle killed with CSRF (Medium)
PRM-01-003 Web: CORS header exposes API data to all origins (High)
PRM-01-005 Server: Clients can cause Denial of Service via Gzip Bomb (Medium)
Miscellaneous Issues
PRM-01-002 Client: Clients leak Metrics data through unprotected endpoint (Low)
PRM-01-004 Web: Parameters used insecurely in HTML templates (Low)
Conclusions
Cure53, Berlin · 06/11/18 1/18
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Introduction
“An open-source monitoring system with a dimensional data model, flexible query
language, efficient time series database and modern alerting approach.”
From https://prometheus.io/
This report documents the findings of a security assessment targeting the Prometheus
software compound and carried out by Cure53 in 2018. It should be noted that the
project was sponsored by The Linux Foundation / Cloud Native Computing Foundation.
In terms of the scope, the assignment entailed two main components as the Prometheus
project was investigated through both a dedicated source code audit and comprehensive
penetration testing. Following a brief, various items were included in the scope and a
detailed information on this matter can be found in the next Scope section. It should be
noted that a kick-off meeting with the in-house Prometheus team and the Cure53 testers
resulted in a shared document on the scope. This facilitated a clear delineation of the
envisioned focus and coverage.
Moving on to the resources and approaches, a team of six Cure53 testers was
comprised and allocated a total of eighteen days for the completion of the project. The
duration of the assessment was determined by a fixed budget provisioned by The Linux
Foundation/ Cloud Native Computing Foundation. White-box methodology has been
chosen as the best-fitting approach for this test and audit. Consequently, Cure53 had
access to the sources and all relevant technical information. What is more, under the
white-box premise, the testers and the in-house team at Prometheus maintained close
contact via Slack throughout this collaboration.
The tests proceeded on schedule and took place in late May and early June of 2018.
After spending the allocated eighteen days, the Cure53 believed to have reached a good
coverage of the agreed upon scope. As already noted, status updates were furnished to
the maintainers, yet no live-reporting of the findings was requested. Over the course of
the project, all communications were prompt and productive. Due to an excellent
preparatory phase, not many questions arose during the test. A clearly communicated
codebase and threat model were easy to understand and investigate for the Cure53
testers. At the same time, it was very much noticeable that said threat model that the
Prometheus team works with is quite unique. Specifically, Cure53 considers it rather
detached from what is usually found on web- and server-software in a similar category of
products.
Cure53, Berlin · 06/11/18 2/18
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
As for the findings, Cure53 discovered five security-relevant issues. Three were
categorized as actual vulnerabilities and two were classed as general weaknesses.
Among the discoveries in the realm of vulnerabilities, one was considered to be of a
“High” severity, as it related to a faulty and overly lax CORS configuration. The remaining
two flaws were assigned a risk-level of “Medium”. However, after several discussions
between Cure53 and the Prometheus team, several of the spotted issues were
ultimately flagged as “false alerts”. The maintainers argued that certain defenses,
considered by Cure53 as needed, were in fact not the responsibility of the Prometheus
project, but should rather be seen as tasks for other layers in the stack. Documentation
of the tickets affected by the discussions was accordingly updated to reflect these
changes.
In the following sections, the report first provides more details on the scope and points to
the code repositories that the Cure53 team relied on. Next, the documentation includes a
dedicated section on coverage, methodologies and general hardening
recommendations. A case-by-case discussion of findings then ensues. In the final
paragraphs of the Conclusion section, Cure53 shares some broader reflections about
the security posture of the Prometheus software compound. In addition, it addresses the
key issue of the unusual circumstance of this assessment, which led to an invalidation of
some discoveries. A general verdict taking the latter into account is offered at the end of
this report.
Scope
• Prometheus Clients
◦ Go Code-Base (audited with highest priority)
▪ https://github.com/prometheus/client_golang
▪ https://github.com/prometheus/client_golang/blob/master/prometheus/promhttp/h
ttp.go
◦ Python Code-Base (audited with lower priority)
▪ https://github.com/prometheus/client_python/
▪ https://github.com/prometheus/client_python/tree/master/prometheus_client
◦ Java Code-Base (audited with lowest priority)
▪ https://github.com/prometheus/client_java
• Prometheus Server
◦ https://github.com/prometheus/prometheus
Cure53, Berlin · 06/11/18 3/18
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Methodology
The following section describes the methodology that was used during this source code
audit and penetration tests. The test was divided into two phases with corresponding
two-fold goals and focal points with reference to the scope. The first phase concentrated
mostly on manual source code reviews. These reviews aimed at spotting insecure code
constructs marked by the potential a capacity of leading to memory corruption,
information leakages and other similar flaws. The second phase of the test was
dedicated to classic penetration tests. During this phase, it was examined whether the
security promises made by Prometheus in fact hold against real-life attack situations.
Part 1 (Manual Code Auditing)
A list of items below seeks to detail some of the noteworthy steps undertaken during the
first part of the test, which entailed the manual code audit against the sources of the
Prometheus software compound. This list attests that in spite of the relatively low
number of findings, substantial efforts were made and a great deal of attention was
given to the scope. In other words, a good level of coverage was achieved with a lot of
dedication. The steps taken and completed during the assessment are listed next.
• The source code of the Prometheus server was checked for potential sinks via
data parsing. As the application avoids the use of potentially insecure formats like
XML, no issues were discovered.
• The logic of the retrieval component relies on the standard HTTP Go client. As
this client exclusively supports standard protocols like HTTP/HTTPS, no issues
were uncovered directly in the code. It was discovered that the gzip compression
is supported and this was later confirmed in Part 2 of the assessment.
• The admin interface exposes multiple HTTP routes. The case of user-controlled
data being processed was thus investigated. The aim was to verify if a potentially
insecure function call could be reached. A possible path traversal had been
discovered but was ultimately dismissed in the second p