跳到主要内容

某云平台GitHub信息泄漏导致 GET SHELL

GitHub 泄露往往是攻击链的起点，一个配置文件的暴露可以升级为完整系统接管。 代码仓库中直接存储的明文凭证、数据库密码、API 密钥，每一项单独看都是局部风险，但攻击者可以将它们串联成一条完整的攻击链：从邮件账号到数据库，从数据库到 API，从 API 到数千台云主机的管理权限。本文记录的 UCloud 案例完整呈现了这条路径。

1 漏洞入口​

自动化监控工具可以在漏洞被恶意利用前发现泄露，这是防御时间窗口的关键。 GSIL 监测到一处敏感信息泄露，涉及 UCloud 的设计运营系统、通用计算平台运营系统、UGC 平台运营管理系统等多个系统的代码仓库。

https://github.com/s*******g/***

2 信息泄露​

代码中直接存储明文凭证，说明开发阶段缺乏 secrets 管理规范，这是泄露的根本原因。 泄露的仓库中包含邮件账号密码、数据库账号密码及其他配置信息，这些凭证一旦进入代码历史就很难彻底清除，即便删除文件，git 历史依然保留完整记录。

send_account := "***-noreply@ucloud.cn"
send_password := "U**********3"
host := "smtp.qiye.163.com:25"

邮件凭证泄露意味着攻击者可以以平台官方身份发送邮件，这对用户的信任是直接威胁。验证测试确认账号可用：

数据库账号密码及其他配置信息同样包含在泄露代码中，这构成了进一步扩大影响的基础：

3 扩大影响​

源码泄露后，静态代码扫描可以快速定位更多隐藏漏洞，攻击者同样可以做到这一点。 通过 Cobra 扫描泄露的源码，发现了几处 SQL 注入。入参直接拼接 SQL，而且未做任何权限认证，任何人都可以直接查询数据库：

http://106.\*\*\*.\*\*\*.\*\*\*:\*\*\*/query?q=show%20databases;
http://106.\*\*\*.\*\*\*.\*\*\*:\*\*\*/query?q=select+\*+from+nginx_request+limit+200&db=nginx

SQL 注入加上无权限认证，意味着数据库内容完全暴露。 这与邮件凭证泄露形成双重突破——前者可以发送钓鱼邮件，后者可以直接读取业务数据。

4 再次扩大​

注释掉的代码同样构成风险，这是静态扫描必须覆盖注释内容的原因。 Cobra 扫描报告中发现了三对公私密钥，其中两对被注释，但仍然在代码历史中保留。通常这类密钥被认为只限内网调用，但进一步检查发现密钥对应的 API 变量 COMMON_API_URL = "https://api.ucloud.cn/?" 是外网地址，经 UCloud API 文档 确认该接口确实可以从外网调用。

var (
	//      吴**
	//      PublicKey  = "mq0fPub*************************OVK98eW+vNYrNQ=="
	//      PrivateKey = "f7a576d87fc2***********4083f78f"

	//      孙**
	//      PublicKey      = "D/ze2*********************************yer0YOAFPg=="
	//      PrivateKey     = "de17af******************************12ab6a1dadd"

	//      ucvd 公用
	PublicKey  = "7vt40gcKGnT************************DF1ETwgsDt0hZgg=="
	PrivateKey = "3c45fd62b9*********************16d1117"

	COMMON_API_URL = "https://api.ucloud.cn/?"
)

公私钥泄露直接导致云主机管理权限完全失控，这是从代码泄露到基础设施接管的关键跳板。 通过使用公私钥构造 UCloud API 接口调用（Python 版本 SDK），验证得到以下信息（公私钥已失效，图片不做打码处理）。

单个 Region 就有数千台云主机可被枚举：

可以跨地区管理数千台云主机：

公有云上的服务器同样在权限范围内，北京节点测试结果可以管理数千台机器：

挑了几个不影响业务的接口做验证测试：

获取 VNC 密码：

创建一台新主机：

发送短信：

理论上可以修改主机密码直至登录服务器、关机使所有服务中断、获取数据库权限拿到全部数据，并管理镜像、容器、监控、CDN 等所有关联产品。 为避免影响，验证到此为止，不做进一步渗透。

5 修复方案​

应急处置需要先切断访问路径，再评估影响范围，顺序颠倒会给攻击者更多时间。 具体步骤：

  • 查看仓库 Clone 情况，判断泄露内容已被多少人获取
  • 删除仓库，并清理 git 历史中的敏感信息
  • 立即重置泄露的公私钥、数据库密码和邮件账号密码
  • 排查是否已遭到他人恶意利用，包括种马、异常登录记录
  • 修改测试中获取的 VNC 密码，删除测试创建的云主机
  • 修复 SQL 注入并对相关接口增加权限认证

工程层面的防御需要从源头介入，而不只是事后修复。 将 secrets 检测工具（如 truffleHog、git-secrets）集成到 CI/CD 流程，确保包含明文凭证的代码无法通过 PR 合并。同时建立定期 GitHub 扫描机制，覆盖组织内所有仓库和员工个人账号的关联提交。API 密钥应遵循最小权限原则，不同系统和不同环境使用独立的密钥，避免一个密钥泄露导致所有系统暴露。

漏洞已报告给CNCERT/乌云/补天或厂商且已修复完成，感谢厂商的重视及现金奖励。

本章内容大纲