# Man in the middle using LoadBalancer or ExternalIPs services

Kubernetes kube-proxy allows MITM by creating LoadBalancer/ExternalIPs services targeting victim IPs, intercepting traffic to external, ClusterIP, pod, and localhost addresses.

- Payout: hidden
- Severity: medium
- Program: Kubernetes
- Found by (vendor credit): Etienne Champetier (@champtar) of Anevia
- Found by: champtar
- Disclosed: 2021-11-04
- CVE: CVE-2020-8554
- Write-up quality: 8/10
- Original: https://hackerone.com/reports/764986
- Library page: https://bugbountylibrary.com/r/h1%3A764986
- Tags: area:cloud domain:cloud impact:data-leak impact:internal-access kind:bounty platform:hackerone sev:medium tech:kubernetes technique:recon vuln:misconfiguration

**Target:** kube-proxy
**Root cause:** kube-proxy programs service VIPs without validating that LoadBalancer ingress IPs or externalIPs do not overlap with existing ClusterIPs, pod IPs, node IPs, or localhost, allowing an attacker to hijack traffic destined to those addresses.
**Steps:**
1. Deploy victim-client pod and echoserver pod.
2. Create LoadBalancer service `mitm-external-lb` with targetPort 8080/8443.
3. Patch service status: `kubectl proxy --port=8080 & curl -XPATCH -H 'Content-Type: application/merge-patch+json' http://127.0.0.1:8080/api/v1/namespaces/kubeproxy-mitm/services/mitm-external-lb/status -d '{"status":{"loadBalancer":{"ingress":[{"ip":"1.1.1.1"}]}}}'`
4. From node or pod, curl http://1.1.1.1 and observe traffic routed to echoserver.
5. Alternatively, create ClusterIP service with `externalIPs: [1.1.1.1]`.
6. Repeat for ClusterIP (e.g., kubernetes-dashboard 10.233.36.240), pod IP (10.233.115.2), and localhost (127.0.0.1) using LoadBalancer status patch or externalIPs (localhost blocked for externalIPs).
**How found:** Researcher hypothesized that kube-proxy might not validate service IP ranges, then systematically tested combinations of service types (LoadBalancer, ClusterIP+externalIPs) against various target IPs (external, ClusterIP, pod, localhost) across kube-proxy modes (IPVS, iptables) and GKE.
**Exploitation:** An attacker with permission to create or patch services can set a LoadBalancer ingress IP or externalIPs to a victim IP (external, ClusterIP, pod IP, or 127.0.0.1). kube-proxy then routes traffic destined to that IP to the attacker's pod, enabling interception of unencrypted or TLS traffic (if attacker can present valid cert or victim ignores TLS errors).
**Insight:** When assessing Kubernetes clusters, check if service creation/patching permissions allow setting arbitrary LoadBalancer ingress IPs or externalIPs; test if these can overlap with ClusterIPs, pod IPs, or localhost to intercept traffic.
