Penetration Test Report (Cure53): pentest report CoreDNS

Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Pentest-Report CoreDNS 02.-03.2018
Cure53, Dr.-Ing. M. Heiderich, M. Wege, MSc. N. Krein, BSc. J. Hector, J. Larsson,
Dipl.-Ing. A. Inführ
Index
Introduction
Scope
Test Coverage
Identified Vulnerabilities
DNS-01-003 Cache: DNS Cache poisoning via malicious Response (Critical)
Miscellaneous Issues
DNS-01-001 Rewrite: Overlong Domain Names bypass Logging (Medium)
DNS-01-002 Secondary: Denial-of-Service via endless Zone Transfer (Info)
DNS-01-004 Denial-of-Service through large Queries (Info)
Conclusions
Introduction
“CoreDNS is a DNS server. It is written in Go.
CoreDNS is different from other DNS servers, because it is very flexible; it chains
plugins. Each plugin performs a DNS function, such as Kubernetes service discovery,
Prometheus metrics or rewriting queries.
We aim to make CoreDNS fast and efficient. We strive keep things as simple as
possible and have sane defaults. CoreDNS integrates with Kubernetes or directly with
etcd.”
From https://www.coredns.io
This report documents the findings of a security assessment against the CoreDNS
project. Cure53 was commissioned to conduct this security-centered investigation by the
Linux Foundation. The investigation, which encompassed both a source code audit and
a penetration, was completed over the course of several weeks and concluded in March
2018. Four security-relevant findings, including one at a “Critical” level, were revealed to
affect the CoreDNS software tested by the Cure53 team.
Cure53, Berlin · 03/13/18 1/11
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
As already mentioned, the Linux Foundation sponsored the test with the necessary
budget. In order to provide satisfactory coverage under the specific premise, six testers
from the Cure53 were executing this test with the use of a white-box methodology. This
approach means that all necessary information was available, including and the software
maintainers shared insights and details as to particular tasks and focus. It has to be
mentioned that the majority of the CoreDNS project sources can be attained online and
are publicly available. In other words, the CoreDNS itself and its major DNS support
library can be acquired from Github.
The actual testing was preceded by a dedicated meeting between the Cure53 project
team and the CoreDNS maintainers. This was useful to determine which aspects or
areas were possibly sensitive or crucially important for the overall development of the
CoreDNS project. Consequently, Cure53 could be responsive and selective in their
coverage. It was decided for the test to be split into two phases: first entailing a classic
source code audit, and the second signifying a penetration test against several running
instances of the CoreDNS set up by the Cure53 testers. Unlike in the majority security
assessment conducted at present, the communications for this test were done via email
messages. Normally, an absence of a dedicated live-exchange channel may impede the
pace of the assessment, especially in face of commonly emerged technical barriers, yet
the real-time communication was not needed for this test. In particular, there was no
intermediate action required from the development team, so the turnaround times
accomplished with email messages proved unproblematic.
The aforementioned four security-relevant findings were all identified during the second
stage of a penetration test component. The manual code audit yielded nothing of
relevance, as is to be expected from modern environments like the used Go framework.
Among the discoveries, one “Critical” problem warrants immediate fixes, while the rest
constitute rather minor flaws, suitable as recommendations to deploy more defense-in-
depth fixes and approaches.
It needs to be emphasized that the scope of this CoreDNS test was quite extensive and
ranged from manual auditing to attacking the software from many angles and in a variety
of configurations, all the while using the source code as a reference. Under this broad
premise, the report will now further elaborate on the scope of the test in greater detail. In
the following sections, it furnished a discussion of the coverage and presents all findings
alongside relevant remediation advice. Finally, the document closes with a broader
verdict and notes on the state of security matters at the CoreDNS compound in light of
this Cure53 assessment.
Cure53, Berlin · 03/13/18 2/11
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Scope
• CoreDNS DNS Server Software
◦ https://github.com/coredns/coredns
▪ Release 1.0.6, master/83b5eadb4e4af8698bb5aed9e243fc024f34296b
◦ https://github.com/miekg/dns
▪ Release 1.0.4, master/5364553f1ee9cddc7ac8b62dce148309c386695b
Test Coverage
This section comments on the test coverage reached by the testing team in the given
timeframe. These explanations are necessary for the next steps in any project with an
extensive scope.
The system was initially built and installed with different configurations, ranging from a
plain binary via a simple container to the Kubernetes orchestration. In the background, it
was additionally all working around small, release-related incompatibilities. The source
code was scouted for different areas of isolatable concern and separated assessment
responsibilities were delineated. This test structure was compliant with the particular
requests from the development team during the kickoff meeting. It was relatively quickly
concluded that a manual static code analysis can yield very little and such an approach
was therefore dismissed. Nevertheless, the sources were checked in particular areas for
common mistakes like external command execution. This was done along with file and
input handling exported by the system and used by the respective integration within the
software. Special care was given to the core/coremain/request components before
moving on to the plugins deemed exposed, i.e. template, whoami, file, cache, health and
hosts.
Moving onto more dynamic penetration testing, while still comparing the implementation
source code with the observations made, the correct functioning of the specialized string
parsers was analyzed. As these are responsible for dealing with domains, subdomains,
ports, etc., they were probed for unexpected behavior. Various tests were undertaken in
relation to specific problems with common configurations. They covered the domains of
reflection, amplification and DoS/SYN-flooding attacks, yet none of them were fruitful. A
number of attempts was made to poison the DNS cache, with one configuration actually
succeeding to do so. The problems talked about CNAME and A entries being corrupted,
additional records added and specific domain rules in the configuration permuted.
Certain operations were performed on the overly long subdomain and domain names
with a focus on the rewrite module. This led to a mere logging evasion.
Cure53, Berlin · 03/13/18 3/11
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Non-terminating and data starving zone transfers were successfully executed but only
yielded DNS-inherent problems. Although length fields in the DNS requests were
corrupted, they were correctly handled by the software. Additional inroads were made on
the recursion implementation and the parsing of the HTTP requests was attacked with
verve. Additional focus was given to the field of transaction ID generation and
verification. Several DNS-related tools were adopted to facilitate further investigation of
the potential corruption issues. Very little made the software budge and only minor flaws
were found.
The Kubernetes setup was run in IPv6-only mode and checked for fragmentation and
addressing problems. Several DoS vectors, long TXT records, DNSSEC-throttling and
various IP-header spoofing and randomization attempts were