Penetration Test Report (Cure53): pentest report telekube

Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Pentest-Report Telekube 08.2017
Cure53, Dr.-Ing. M. Heiderich, M. Wege, N. Hippert, BSc. D. Weißer, MSc. N. Krein,
J. Larsson, Dipl-Ing. A. Inführ, M. Kinugawa
Index
Introduction
Test Coverage
Identified Vulnerabilities
TLK-01-001 Web: Copypaste XSS on MSIE/Edge due to missing Headers (Low)
TLK-01-002 Web: Arbitrary Redirect during Login allows Phishing (Low)
TLK-01-006 Web: Missing Login Rate Limiting allows for OTP brute-force (Low)
Miscellaneous Issues
TLK-01-003 Web: Login CSRF due to state parameter not validated (Low)
TLK-01-004 Web: Missing CSRF protection on logout endpoint (Low)
TLK-01-005 Web: CSP bypass with Angular bundled with Grafana (Info)
TLK-01-007 Web: Password reset link not invalidated after use (Info)
TLK-01-008 Web: Login CSRF on login endpoint (Low)
TLK-01-009 Web: Login CSRF on password reset endpoint (Low)
TLK-01-010 Web: Email enumeration via password reset (Info)
TLK-01-011 Web: Manipulation of installation links (Info)
Conclusions
Cure53, Berlin · 10/23/17 1/16
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Introduction
“Telekube combines a production hardened deployment of Kubernetes with Teleport, our
multi-region SSH server, so you can effectively manage multiple deployments of
Kubernetes applications across various regions, data centers and cloud providers.”
From http://gravitational.com/telekube/
This report documents the findings of a penetration test and source code audit against
the Telekube product. The assessment was completed by Cure53 over the course of
twenty days in late August and early September of 2017, overall yielding a total of eleven
security-relevant findings. The scope of the project encompassed multiple components
of the Gravitational Telekube software compound. More specifically, it included web
interfaces, CLI clients, the general Kubernetes and Docker integration, as well as the
particularities of the AWS/IAM integration. Also in scope were all sources warranting
audit and review.
Given the complexity and extensive scope of this assessment, Cure53 composed a
team consisting of nine testers, who were carefully selected to ensure that all skillsets
needed for a successful completion of this high-difficulty project can be benefitted from.
As a result, various methodologies could be employed for this test and audit. It is worth
noting that the Gravitational in-house team set up a test environment for Cure53. This
entailed granting testers SSH access, which can also be inferred from the links and URL
examples presented across different technical descriptions in this report. Further, all
relevant sources have been shared with Cure53 via Github. To assist verification,
Cure53 additionally made use of a cloud VM instance available to all testers. Expectedly,
this instance has been destroyed afterwards. It should be mentioned that some parts of
the scope overlapped with the items already investigated during a previous Cure53 test
against Gravitational Teleport, so the current assessment skipped through these
aspects. Finally, to facilitate and foster good communications between the testing team
and the Gravitational maintainers, a dedicated Slack channel has been used.
To briefly comment on the overall findings of this project, the Cure53 team noted that a
positive impression gained during the earlier Teleport pentest has persisted for this
extended assessment of Telekube. In spite of considerable efforts, Cure53 was unable to
find vulnerabilities with a security risk levels exceeding that of “Low”. This outcome
should be read as a very good sign of treating security as a key component of internal
operations and development. In the following sections, this report will first discuss the
coverage and scope in more details. Then, each finding is explored on a case-by-case
basis, alongside relevant mitigation and fix advice. Lastly, a concluding statement
expands on the overall security situation of the Gravitational Telekube software
compound.
Cure53, Berlin · 10/23/17 2/16
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Scope
• Telekube Web & CLI Clients
• Telekube Kubernetes / Docker Integration
• Telekube Architecture & Code Review
◦ http://gravitational.com/telekube/
◦ https://gravitational.com/docs/overview/
◦ https://github.com/gravitational/gravity (access was granted)
• Ops Center
◦ https://cure53.gravitational.io
◦ SSH access was granted
Test Coverage
This section lists different items of the Telekube project’s scope covered during the tests
performed by Cure53. The purpose is for the client to gain a better impression of the
investigated realms and correlate that information with internal testing routines and
documentation.
Furthermore, it is designed to facilitate requesting specific test items that might have not
been included in security assessments as of yet, but are still considered necessary
under the premise of achieving completeness.
• The web interface was extensively tested for weaknesses in the area of XSS,
CSRF, and other classic and novel web bugs. In addition, the code was
thoroughly audited. Documentation for all vulnerabilities and weaknesses spotted
in this phase can be found in this report.
• Cure53 analyzed the login routine of the CLIs to determine if they hold up against
the OpsCenter. No flaws were found in this realm.
• The testing team further investigated the packaging process, focusing on
whether certain elements can be used to influence or sabotage the process (e.g.
improper tmp-files and alike). There were no issues to report in this area.
• Cure53 also analyzed the same aspects for the installation process with no
negative results to report.
• Next on the list of items subjected to testing were the cluster communications
from within a container inside the same cluster. Two outside calls to Grafana and
AWS could be identified, but it was impossible to use them for malicious
purposes.
• The team further tried to manipulate the installation packages created to elevate
privileges. This has proven futile and no flaws were discovered.
Cure53, Berlin · 10/23/17 3/16
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
• Cure53 looked at the RBAC mechanisms and tried to gain more privileges with
an otherwise restricted user. No flaws were found in this realm.
• All the network interfaces for the Docker-containers and Kubernetes-pods were
mapped in order to analyze communications whit in the cluster infrastructure and
determine attack surfaces on each given host which could lead to the discovery
of security flaws. However, no flaws were discovered at this stage.
• Despite thorough testing, no flaws were found in the implementations for either
Kubernetes, IAM, docker or seccomp.
• Cure53 dedicated considerable research to all pods/containers for hardcoded
secrets and sensitive information. To the best of our knowledge and
understanding of the platform, no noteworthy findings emerged here.
• The test team further analyzed the cluster management component (i.e. gravity)
and checked for security issues or related flaws. For this aspect, once again
there were no significant findings.
• The security of applications deployed by customers within the cluster was not in
scope of this test and is limited to the security features provided by
kubernetes/docker.
Identified Vulnerabilities
The following sections list both vulnerabilities and implementation issues spotted during
the testing period. Note that findings are listed in a chronological order rather than by
their degree of severity and impact. The aforementioned severity rank is simply given in
brackets following the title heading for each vulnerability. Each vulnerability is
additionally given a unique identifier (e.g. TLK-01-001) for the purpose of facilitating any
future follow-up correspondence.
T