Cluster and cloud DNS compromise¶

Attack pattern¶

Inside a Kubernetes cluster, name resolution is a service like any other, and CoreDNS reads its configuration from a ConfigMap that lives in kube-system. Write access to that object redirects resolution for every pod at once. There is no exploit in it: a forward directive pointing somewhere else, or a rewrite rule for one hostname, is a single line that reads like ordinary cluster configuration in a diff. Managed cloud resolvers work the same way one level up, where Route 53 resolver rules, Azure Private DNS zones and Cloud DNS records are API objects that answer to whoever holds the credential rather than to whoever owns the name. Everything downstream inherits the answer, including the image pull that resolves the registry by name before it fetches a layer.

1. Cloud/SaaS Exploits [OR]

    1.1 Kubernetes DNS Compromise [OR]

        1.1.1 CoreDNS / Etcd cache poisoning [OR]
            1.1.1.1 API server compromise
            1.1.1.2 ConfigMap manipulation
            1.1.1.3 Plugin vulnerability exploitation

        1.1.2 NetworkPolicy Bypass [OR]
            1.1.2.1 Privileged pod escape
            1.1.2.2 Node-level network access
            1.1.2.3 Cross-namespace traffic interception

        1.1.3 Service Mesh Exploitation [OR]
            1.1.3.1 Istio/Linkerd DNS redirection
            1.1.3.2 mTLS certificate theft
            1.1.3.3 Sidecar proxy manipulation

    1.2 Serverless Abuse [OR]

        1.2.1 DNS Tunnelling [OR]
            1.2.1.1 Lambda TXT record exfiltration
            1.2.1.2 Cloud Functions DNS over HTTPS
            1.2.1.3 Azure Functions private resolver abuse

        1.2.2 Resource Exhaustion [OR]
            1.2.2.1 DNS query burst attacks
            1.2.2.2 Recursion depth exploitation
            1.2.2.3 Cache saturation attacks

        1.2.3 Cloud Integration Attacks [OR]
            1.2.3.1 AWS Route 53 resolver hijacking
            1.2.3.2 Google Cloud DNS API abuse
            1.2.3.3 Azure Private DNS zone poisoning

    1.3 Container Registry Attacks [OR]

        1.3.1 Image Pull Manipulation [OR]
            1.3.1.1 DNS spoofing for registry redirection
            1.3.1.2 MITM attacks on image downloads
            1.3.1.3 Cache poisoning for malicious images

        1.3.2 Supply Chain Compromise [OR]
            1.3.2.1 Malicious library injection via DNS
            1.3.2.2 Dependency confusion attacks
            1.3.2.3 Package manager DNS hijacking

One ConfigMap from the whole cluster¶

CoreDNS takes its configuration from a ConfigMap. Write access to it redirects resolution for every pod in the cluster, with nothing exploited along the way.
A forward or rewrite directive is one line, and it reads as routine cluster configuration to anyone reviewing the change.
Cluster DNS is often outside whatever NetworkPolicy exists, and a good many clusters run without one at all.
Managed resolvers are API objects rather than infrastructure. A credential with the right verb rewrites internal name resolution without touching a host.
An image pull resolves the registry by name like anything else, so redirecting the name is enough to serve the layers.
Internal package names that also resolve publicly let the public answer win. Dependency confusion is that behaviour, wearing a DNS hat.