K8S-EXPOSED-ETCD
Kubernetes · etcd (Kubernetes control-plane key-value store, ports 2379/2380)
Résumé
Exposed etcd is a misconfiguration class in which the etcd key-value store backing the Kubernetes API server is reachable on its client port (TCP 2379, with 2380 used for peer traffic) without client-certificate authentication. etcd is the single source of truth for a cluster and stores the entire cluster state, including all Secrets, service-account tokens, credentials, ConfigMaps, and RBAC rules, so reading it bypasses Kubernetes RBAC entirely and writing to it lets an attacker alter cluster state and take over the cluster. etcd shipped insecure by default: it had no authentication before version 2.1 (July 2015) and client-certificate authentication remained off by default for backward compatibility, and its authorization model is effectively all-or-nothing once access is granted. In March 2018, researcher Giovanni Collazo demonstrated the scale by querying Shodan and finding 2,284 etcd servers exposed to the internet without authentication; a short script then harvested roughly 750 MB of data including thousands of passwords, hundreds of AWS access keys, and private keys. The root cause is an etcd endpoint listening on a network-reachable interface without TLS client-certificate authentication enforced.
Comment l’éviter dans votre code
- Never expose etcd (2379/2380) to untrusted networks; bind it to the control plane only.
- Enforce TLS client-certificate authentication and peer TLS for all etcd connections.
- Restrict etcd access with firewalls and NetworkPolicies to the API server alone.
- Encrypt Secrets at rest in etcd and rotate any credentials previously stored there.
- Audit internet exposure with Shodan/Censys and scan IaC for insecure etcd configuration.
Références
Vulnérabilités liées
Tout Infra →- CRITICALCONTAINER-EXPOSED-DOCKER-API
Exposed Docker API is a recurring misconfiguration class in which the Docker remote API (default TCP 2375 plaintext, 2376 TLS) is published to untrusted networks without TLS or authentication, granting anyone who reaches it full control of the daemon. Because dockerd runs as root and the unauthenticated API permits arbitrary container creation, an attacker can launch a privileged container that bind-mounts the host root filesystem and then chroots into it to escape to the host. The Commando Cat campaign, reported in 2024 by Cado Security and analyzed by Trend Micro (advisory dated 13 June 2024), abused exactly this exposure: it deployed a benign image (cmd.cat/chattr) generated by the open-source Commando project, then used chroot and volume binding of the host's root directory into the container to break out and run host-level payloads. The delivered payloads installed cryptocurrency miners, registered persistence and a stealthy backdoor (including DropBear SSH on TCP 3022), and exfiltrated host and cloud-service-provider credentials. Shell-script and command-and-control infrastructure overlapped with the TeamTNT cryptojacking group.
- HIGHCONTAINER-LEAKY-VESSELS-2024
Leaky Vessels was a set of container-escape vulnerabilities disclosed on 31 January 2024 by Rory McNamara of Snyk Security Labs, the headline flaw being CVE-2024-21626 (CVSS 8.6, runc 1.1.11 and earlier). It was an order-of-operations file-descriptor leak in runc's handling of the process working directory (WORKDIR / process.cwd). During container setup runc left an internal file descriptor referencing the host filesystem namespace open before all privileged descriptors were closed, so a malicious image or a build using a malicious Dockerfile or upstream FROM could set the working directory to that leaked descriptor via a path like /proc/self/fd/7. Because chdir occurred before the descriptor was closed, the container process gained a working directory in the host filesystem and could read and write host files, breaking container isolation and escaping to the underlying host. Related Docker BuildKit issues were disclosed alongside it: CVE-2024-23651 (mount cache race), CVE-2024-23652 (build-time arbitrary delete), and CVE-2024-23653 (GRPC SecurityMode privilege check bypass). The flaw was fixed in runc 1.1.12.
- CRITICALCLOUD-OMIGOD-2021
On 14 September 2021 Wiz disclosed OMIGOD, a set of four flaws in Open Management Infrastructure (OMI), an agent that Azure silently auto-deploys onto many Linux VMs via services such as Log Analytics, Azure Automation, Azure Diagnostics and Defender for Cloud. The flagship bug, CVE-2021-38647 (CVSS 9.8), gave unauthenticated remote code execution as root, while CVE-2021-38645, CVE-2021-38648 and CVE-2021-38649 were local privilege escalations. The agent ran as root and could expose a management port (5985, 5986 or 1270); because the authorization code left the AuthInfo struct at its zero-initialized default of uid 0 and gid 0, a request that omitted the Authorization header was treated as an authenticated root request, so a single crafted packet yielded root code execution. This was a provider-side flaw under shared responsibility that most customers did not know was installed and could not patch themselves. Unlike the other entries here it was exploited in the wild within days, with attackers scanning for exposed agents and dropping Mirai botnet and cryptominer payloads.
- CRITICALCLOUD-CHAOSDB-2021
On 25 August 2021 Wiz researchers Nir Ohfeld and Sagi Tzadik disclosed ChaosDB, a cross-tenant flaw in Azure Cosmos DB that let any customer retrieve the primary access keys, certificates and connection details of several thousand other customers' database accounts, enabling full cross-tenant read, write and delete. The chain abused the Cosmos DB built-in Jupyter Notebook feature, which had been enabled by default since February 2021. A notebook ran attacker C# code as root while Python ran unprivileged, giving container root, after which the attacker removed iptables rules to reach the WireServer (168.63.129.16) and Instance Metadata endpoints. Querying WireServer yielded roughly two dozen Microsoft certificates, including private keys for internal Cosmos DB and notebook services, which were used to authenticate to internal Service Fabric clusters, enumerate every customer's Cosmos DB instance and decrypt their stored COSMOSDB_ACCOUNT_KEY and notebook auth tokens. This was a provider-side flaw under shared responsibility that customers could not patch; it was found and reported by researchers with no evidence of exploitation in the wild.
- HIGHCLOUD-POWERAPPS-2021
On August 23, 2021, UpGuard disclosed that misconfigured Microsoft Power Apps portals exposed roughly 38 million records across 47 organizations, including American Airlines, Ford, J.B. Hunt, the Maryland Department of Health, the State of Indiana, New York City agencies, and Microsoft itself. Exposed data included names, email addresses, phone numbers, social security numbers, and COVID-19 contact tracing and vaccination appointment information. Power Apps portals surface list data through OData list feeds reachable at predictable URLs, and access to those feeds is gated by Table Permissions, but Table Permissions were disabled by default on every list. Because security was opt-in, any portal where a developer enabled an OData feed without explicitly configuring and enabling Table Permissions returned its records to any unauthenticated visitor querying the OData endpoint. This is an insecure-default access-control misconfiguration where the platform defaulted to anonymous read rather than deny.
- HIGHCLOUD-KUBELET-HILDEGARD-2021
On February 3, 2021, Palo Alto Networks Unit 42 reported Hildegard, the first known TeamTNT campaign targeting Kubernetes, detected in January 2021. The attackers gained initial access through a misconfigured kubelet: the kubelet read-write API on port 10250 was reachable and accepted anonymous, unauthenticated requests because it was configured with --anonymous-auth set to true and --authorization-mode set to AlwaysAllow, the insecure legacy defaults shipped by some self-managed clusters. Anyone who could reach port 10250 could call the kubelet run-command API to execute commands inside running pods with no credentials. The attackers used this to exec into pods, move laterally across containers, scan for more exposed kubelets, and harvest cloud access keys, SSH keys, Docker credentials, and service-account tokens from the environment. They then deployed the XMRig Monero miner for cryptojacking, using a tmate reverse shell and IRC for command and control and LD_PRELOAD injection to hide processes. The misconfiguration class is missing authentication caused by an insecure default on an internet-reachable management port.