Penetration Test Report (Cure53): VIT 01 report

Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Pentest-Report Vitess 02.2019
Cure53, Dr.-Ing. M. Heiderich, M. Wege, MSc. N. Krein, MSc. D. Weißer, J. Larsson
Index
Introduction
Scope
Test Methodology
Phase 1. Manual Code Auditing
Phase 2. Code-Assisted Penetration Testing
Miscellaneous Issues
VIT-01-001 MySQL: Comparison of Auth Token allows timing Attacks (Info)
VIT-01-002 MySQL: Timing attacks due to plain-text password auth (Low)
VIT-01-003 PII: Not all SQL values covered by SQL redaction (Low)
Conclusions
Introduction
“Vitess is a database clustering system for horizontal scaling of MySQL”
From https://vitess.io/
This report documents the results of a security assessment targeting the Vitess software
database scaler. Funded by the CNCF / The Linux Foundation, this project was carried
out by Cure53 in February 2019 and revealed only three miscellaneous findings.
In terms of resources, the test was completed by six members of the Cure53 team who
worked within a time budget of eighteen days. The testers are considered very
experienced in their respective fields and have considerable expertise in regard to
system complexity, cloud infrastructure, source code auditing, operating system
interaction, low-level protocol analysis and multi-angled penetration testing.
Prior to the assessment, a CNCF-typical setup was requested by the testers and
provided by the development team. Besides furnishing Cure53 with a Kubernetes-based
cluster, locally installed systems were also used for testing. Access to all relevant code
and documentation was granted. While the first project meeting provided the basis for
the audit, a more ad-hoc kick-off meeting ensured that no major hurdles emerged. A
Cure53, Berlin · 03/08/19 1/9
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
dedicated instant messaging channel was used for arising questions and further
inspiration for the test.
An initial assessment of the interfaces and the system architecture, supported also by
additional exchange with the development team, revealed a rather limited attack surface.
This observation was later confirmed as the subsequent phases of the test ensued.
While the results of this assessment are few and far between and may suggest some
kind of test limitations, they in fact prove that the Vitess team delivers on the security
promises they make. In Cure53’s view, there is a clear intention and follow-through on
providing a secure system for scaling MySQL databases. This was achieved by keeping
the attack surface minimal and selecting the language suited for this implementation.
The auditors managed to reach wide-spanning coverage of all aspects pertinent to the
main repository of the Vitess software system. The most likely avenues for exploitation
were chosen and verified for resilience.
In the following sections, the report first defines the scope of the test and then moves on
to explaining the employed test methodology. Subsequent phases and details relevant
for the test are covered next and clarify which aspects were investigated during this
February 2019 assessment. Later in the document, each of the individual findings is
discussed, with technical backdrop, illustrations of wider circumstances, and examples
with code snippets. Finally, this document ends with some broader conclusions and a
general impression that the Cure53 team gained about the Vitess scope system under
scrutiny.
Scope
• Vitess
◦ The publicly available main repository at https://github.com/vitessio/vitess was used
as the codebase to be verified.
▪ branch master commit 092479406b27ae61a8fcd146a0e08af2d51a7245
◦ Furthermore, the minimal reference client https://github.com/vitessio/messages was
used as additional illustration of use-cases.
▪ branch master commit 7d2ac2189573a7d26cf0f42e17df749673e3d16f
◦ The testers received unencumbered access to a Kubernetes test cluster hosted on
Amazon Web Services, which was provided as a reference of an installation typical
for a general Vitess deployment.
Cure53, Berlin · 03/08/19 2/9
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Test Methodology
This section describes the methodology that was used during this source code audit and
penetration tests. The test was divided into two phases. Each phase had goals that were
closely linked to the areas in scope.
The initial phase (Phase 1) mostly comprised manual source code reviews, in particular
in terms of the API endpoints, input handlers and parsers. The review carried out during
Phase 1 aimed at spotting insecure code constructs. These were marked whenever a
potential capacity for leading to buffer corruption, information leakages and other similar
flaws has been identified.
The secondary phase (Phase 2) of the test was dedicated to classic penetration testing.
At this stage, it was verified whether the security promises made by Vitess in fact hold
against real-life attack situations and malicious adversaries. This included watching out
for disclosure of personally identifiable information (PII), particularly in rarely
encountered error cases. Additionally, the deployment infrastructure was further
investigated for generalizable problems in their instrumentation of the Kubernetes
environment.
Phase 1. Manual Code Auditing
The following list of items presents the noteworthy steps undertaken during the first part
of the test, which entailed the manual code audit of the sources of the Vitess software in
scope. This is to underline that, in spite of the almost nonexistent findings, substantial
thoroughness was achieved and considerable efforts have gone into this test. The
completed tasks are listed next. Note that a given realm yielded no results unless
otherwise indicated with a specific link to a finding.
• A comprehensive list of all accessible API endpoints was enumerated and
checked for visible defects. This entailed the functionality exposed by vtlctld and
the same functions that are also reachable via vtctlclient.
• Despite this being only an administrative functionality, a typical example for such
functions interacting with the file system would be ExecuteHook. This item was
analyzed in depth to see if it is by any means possible to inject API commands.
The overarching goal was clearly to achieve injection of the OS-level commands.
The filter implemented for this particular endpoint protects the function sufficiently
and no path traversal instructions can be submitted via the hook’s name.
• The monitor and debug web interfaces were analyzed for common vulnerabilities
like SQL injection or XSS. However, in all encountered cases the user-input was
found to be correctly sanitized, in particular due to the Angular framework’s
proper handling of parameter-supplied values.
Cure53, Berlin · 03/08/19 3/9
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
• The cryptographic and authentication-related aspects were analyzed for potential
general bypasses but no flaws allowing for such circumvention were found.
• A potential timing issue pointed out by the development team was investigated
in-depth but revealed no readily available exploitation paths. The reason behind
the secure premise is that the attacker would need to obtain the hashes
contained in the user-table prior to the attack. A minor issue was filed as VIT-01-
001 to describe the exact circumstances.
• As requested, plenty of additional effort was invested into discovering leaks of
personally-identifiable information, for example during the extensive logging of
executed queries. The redactor was checked for flaws allowing for the exfiltration
of unredacted or incompletely redacted values. The minor issue was filed (see
VIT-01-003) but the real-world impact, as with most information leak issues in
general, would need to be considered as low.
• The configuration of the Kubernetes cluster deplo