cPGuard 更新通道被劫持：5.88.12 至 5.88.19 带后门，32 台服务器数据已被取走

作者

11 月 2 日 02:06 UTC，有人用一组窃取来的凭证登进了 cPGuard 的更新系统，把一段恶意脚本当成正常更新推给客户。cPGuard 是一款面向 Linux 主机的安全加固工具，主要装在跑网站和面板的服务器上，受影响版本为 5.88.12 至 5.88.19。脚本做了两件事：装后门，以及把服务器的密码哈希、数据库配置和 SSH 密钥打包外传。

事件概述

厂商 OPSSHIELD 在公告中给出的时间线是：02:06 UTC 攻击者取得更新系统访问权，随后受影响版本开始下发；12 小时内发现问题。目前攻击者身份未确认，凭证如何泄漏仍在调查。厂商已清理自身基础设施凭证、切断脚本继续下发的路径，并发布 5.88.25 及更高版本清除后门与残留文件。

关于损失规模，OPSSHIELD 在 11 月 2 日晚些时候（UTC）估算，攻击者已从其中一台服务器取走 32 个文件，每个文件对应一台客户服务器。这个数字只统计了”确认被取走”的部分，不等于受影响服务器的总数——服务器是定时轮询更新的，部分设备可能根本没跑到这段脚本。

技术细节

脚本取走的东西很具体，也很致命：

  • /etc/shadow 与 /etc/passwd：前者是单向哈希，弱口令、常用口令、历史泄露过的口令可以离线撞出来
  • root 的 MariaDB / MySQL 配置 my.cnf：里面通常明文写着数据库口令
  • root 的 shell 历史：命令历史里散落着各类 token、连接串、临时密码
  • root 的 SSH authorized_keys 与 known_hosts

注意对比：/etc/shadow 里的东西至少有哈希挡一层，而 my.cnf 和 shell 历史里的密钥是明文，拿到即用。这也是本次事件比一般”更新被投毒”更严重的地方——外泄物里含大量可直接复用的凭证。

外传路径同样值得记录：脚本把打包结果上传到 OPSSHIELD 自己的授权（licensing）服务器，用的是被攻陷的账号，攻击者事后再去取。攻击者没有另建外连域名，而是借用了厂商现有的、白名单内的基础设施，这让出口流量检测基本失效。

留在机器上的痕迹有四个，厂商已公开文件名：

cpguard-v58812-i91511.sh        # 恶意脚本本体
/var/tmp/.cpg91511_sh           # 后门 shell
/var/tmp/.cpg91511              # 收集目录
/var/tmp/.cpg91511/loot.tgz     # 打包后的外传归档

不过 5.88.25 的更新会删掉后门和收集目录，所以”文件不存在”不能证明脚本没跑过。真正可靠的判断依据是更新日志：

grep 'Successfully updated' /opt/cpguard/logs/install_log

只要日志里出现 5.88.12 至 5.88.19 中任一版本，就说明这台机器装过受影响更新。日志缺失或不完整同样不能排除，需要联系厂商确认。另外厂商还在补发一个预防性更新，用于移除此前添加到服务器上的厂商支持访问公钥——这说明 support access 功能会给 root 的 authorized_keys 追加一把厂商公钥，而那把私钥是否在本次事件中泄露，厂商尚未说明。

影响评估

受影响的是”已经装了安全工具”的服务器，这批机器往往承载多个站点，一旦 root 失守就是横向起点。截至目前厂商称除数据收集与后门外未发现其他恶意行为，但明确表示该结论不是最终结论。已经外传的凭证在升级后依然有效，这一点必须单独处理。

修复建议

  • 每台机器执行 cpgcli update --start，再用 cpgcli --version 确认版本为 5.88.25 或更高；失败或版本偏低直接找厂商支持。
  • 在可信的恢复环境中重置 root 及所有使用密码的本地账号口令；同一口令在其他系统复用过的一并改掉。
  • 轮换数据库口令、S3 访问密钥、云主机 API Token，以及 root shell 历史里出现过的全部密钥。
  • 替换 /root/.ssh 下的私钥，并从所有信任方删除对应的旧公钥。
  • 厂商目前不建议一律重装系统，但如果能确认脚本跑过又找不到完整日志，按”已被入侵”处理更稳妥。

参考来源