Penetration Test Report (Cure53): pentest report opa

Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Pentest-Report Open Policy Agent 08.2018
Cure53, Dr.-Ing. M. Heiderich, M. Wege, MSc. N. Krein, BSc. J. Hector, Dipl.-Ing. A. Aranguren,
Dipl.-Ing. A. Inführ
Index
Introduction
Scope
Test Methodology
Part 1. Manual Code Auditing and Documentation Review
Part 2 (Code-Assisted Penetration Testing)
Identified Vulnerabilities
OPA-01-001 Server: Insecure Default Config allows to bypass Policies (Medium)
OPA-01-005 Server: OPA Query Interface is vulnerable to XSS (High)
Miscellaneous Issues
OPA-01-002 Server: Query Interface can be abused for SSRF (Medium)
OPA-01-003 Server: Unintended Behavior due to unclear Documentation (Medium)
OPA-01-004 Server: Denial of Service via GZip Bomb in Bundle (Info)
OPA-01-006 Server: Path Mismatching via HTTP Redirects (Info)
Conclusions
Introduction
“The Open Policy Agent (OPA) is an open source, general-purpose policy engine that
enables unified, context-aware policy enforcement across the entire stack. OPA is
hosted by the Cloud Native Computing Foundation (CNCF) as a sandbox level project.”
From https://github.com/open-policy-agent/opa
This report documents the results of a security assessment against the Open Policy
Agent (OPA) framework. The project, which entailed both a penetration test and a
source code audit of the OPA compound, was carried out by Cure53 in August 2018 and
yielded six security-relevant discoveries. It is crucial to underscore that the assessment
was sponsored by The Linux Foundation / CNCF and constitutes one of a growing
number of security-centric projects targeting the CNCF-related software and
commissioned by the funders to the Cure53 team.
Cure53, Berlin · 08/30/18 1/14
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
It needs to be noted that the OPA framework is almost entirely written in Go and this had
a bearing on the employed approaches and personnel resources. From the Cure53
team, six testers were tasked with the completion of the project. In terms of time, a total
of eighteen days were invested into the assessment and allocated primarily to testing
and auditing, as well as to reporting and documentation.
The Cure53 team investigated the OPA framework through a range of methods,
reviewing the scoped source code and pentesting a reference implementation made
available by the software maintainers. Notably, OPA can be deployed and used in two
different ways, either as daemon or as a library. With this knowledge, Cure53 honed in
on examining both deployment routes after receiving all necessary information from the
maintainers’ side. The white-box approach of this test relates to the fact that all relevant
OPA sources are available on GitHub so everything of note could be used for testing
and added to the scope. Nevertheless, one item - the control panel - was excluded from
the list of test-targets. While this item was not investigated, it was utilized for testing.
The tests generally proceeded on schedule and the Cure53 team strongly believes that
a good coverage has been reached on the scope. Throughout the assessment, the
communications were done on Slack and the OPA maintainers invited Cure53 into a
dedicated private channel. All emerging questions posed by the testers were answered
by the OPA team in a prompt, precise and comprehensive manner. Significantly, no live-
reporting was requested by the OPA maintainers, meaning that Cure53 only reported the
headlines of the findings during the test.
As far as the array of six findings is concerned, two problems were categorized as
security vulnerabilities and four as general weaknesses. On the one hand, one finding
was given a rather concerning “High”-severity ranking. On the other hand, most of the
spotted issues had lesser implications. Furthermore, not a single flaw has been recorded
as “Critical” in terms of impact and the overall number of findings should be seen as
acceptable.
In the following sections, the report will first elaborate on the scope and then offers a
dedicated, highly detailed section on the Test Methodology in order to enable tracking of
progress and coverage to the funders and maintainers alike. Next, each finding is
separately discussed together with its technical background and mitigation options.
Lastly, Cure53 delivers some broader conclusion notes in the closing section. In light of
the findings, the testing team comments on the security posture of the tested OPA
framework manifested during this assignment.
Cure53, Berlin · 08/30/18 2/14
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Scope
• Open Policy Agent
◦ https://github.com/open-policy-agent/opa
• Reference setup from OPA
◦ A setup with three hosts, reflecting a common deployment scenario and provided by
the OPA maintainers.
◦ Cure53 was given access to both possible ways of implementing OPA, full SSH
access was granted to allow better insights and efficient debugging.
Test Methodology
Part 1. Manual Code Auditing and Documentation Review
This section provides information about the process followed during the first part of the
test, highlighting some of the actions taken during the manual code audit against the
sources of the Open Policy Agent system. Below one can find a list which reflects the
significant efforts made during the assessment. This demonstrates that, despite the
relative low number of findings stemming from this test, various strategies and
approaches were systematically and creatively deployed against the items in the OPA
scope. Once again, it needs to be reiterated that a good level of coverage was achieved
by the Cure53 team during this project.
• The available documentation and deployment instructions were thoroughly
reviewed for possible weaknesses, any potential for misinterpretation, as well as
vulnerable examples. For instance, the provided sample apps/APIs were
checked to see whether there any common errors could might confuse OPA
when the app extracts request headers and forwards them. The solution
appeared robust enough and potential issues were discussed as highly
dependent on the configuration and deployment of the frontend.
• The OPA source code was reviewed to determine if URL path traversals could
lead to policy bypasses. This was checked on both the Go and Python examples
provided, although they were not exactly in scope. Still, these could demonstrate
errors that are typically made during writing of the frontend code.
• The application source code of OPA was reviewed for common data parsing
flaws, however the application uses JSON instead of XML, hence reducing the
attack surface substantially. An XSS issue inside the HTML template for the
index route via JSON parsing errors was eventually identified and documented
under OPA-01-005.
• The PAM setup was analyzed for MitM (Man-in-the-Middle) potential via
environment variables. It was found that PAM prevents that unless specifically
Cure53, Berlin · 08/30/18 3/14
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
told to use ~/.pam_environment. Similarly, as OPA allows to communicate with
the control panel via HTTPs, the code was checked for the presence of
InsecureSkipVerify, as this would indicate that a setting weakening the SSL
certificate parsing exists on the scope.
• The supplied codebase was also assessed for possible command execution,
evaluation of code, file handling and other similar pitfalls (i.e. via calls to os.*,
ioutils.*, etc.).
• The code related to authorization and authentication was reviewed for particular,
usual flaws in this application areas, resulting in OPA-01-003
• The available routes were audited to identify weaknesses in the provided built-in
functions of rego. For example, it was attempted to identify endpoints that might
be abusable via SSRF or when OPA is directly reachable or not bound to
localhost. This re