攻击者通过被攻陷的分发系统，向数千台Linux服务器推送了伪装成cPGuard更新的恶意程序，并以root权限运行。
软件供应链中的漏洞再度暴露，此次攻击者将矛头对准了OpsShield的更新流程。
本周，威胁行为者利用窃取的凭证，向cPGuard客户推送了恶意更新。随后，他们访问了存储在该厂商服务器及其计费门户账户中的数据，并复制了至少三台OpsShield云服务器的内容。
该公司在一份安全公告中表示，已经"将攻击者从所有已知被入侵的系统中清除，并正在重建那些无法完全信任的系统"。公司同时发布了更新补丁，并敦促客户升级到cPGuard最新版本、修改密码、重新生成SSH密钥。
归根结底，此次未经授权访问的广度凸显出软件供应链持续存在的脆弱性，也暴露出安全工具自身同样存在风险这一事实。
攻击全过程解析
OpsShield专注于服务器保护和网站安全软件领域。其cPGuard产品是一套面向Linux网站托管服务器的安全套件，集成了恶意软件扫描和防火墙功能。
该公司披露，在11月1日至2日期间，攻击者未经授权访问了OpsShield的更新分发基础设施，并在大约70分钟内推送了一个恶意更新。
威胁行为者首先探测了OpsShield的计费门户，以虚假身份注册了一个客户账户，并申请了cPGuard的免费试用。随后，他们发送精心构造的请求，获得了在服务器上执行命令以收集数据的能力。他们利用窃取的访问密钥发布虚假更新，该更新以root权限（最高级别的管理员权限）运行，并借此复制敏感文件以及三台OpsShield云服务器的内容。
据OpsShield报告，约有2950台客户服务器运行了这一虚假更新，导致密码哈希值、root SSH密钥、MySQL root密码及shell历史记录等信息外泄。攻击者还访问了约7900个计费门户账户，其中包含客户姓名、地址、电子邮件及哈希密码。
OpsShield表示，目前仍在审查攻击者具体是通过何种请求获得访问权限的，并已修补了两个可能的入侵点，同时对相关厂商组件进行了逐行验证。公司已关闭攻击者账户，吊销被盗的更新存储密钥，以及"账户下所有的云API令牌和访问密钥"。
该公司还移除了攻击者的安全外壳（SSH）访问权限；删除了攻击者创建的服务器克隆及任何快照；启用了更强的登录保护机制，并替换了所有SSH密钥和密码；重置了所有计费门户登录会话并轮换了所有密钥；同时开始以更严格的PHP和防火墙设置重建其计费、授权及内部管理服务器。
该公司还发布了干净版本的更新：v5.88.26版本移除了隐藏的root shell；后续更新则清除了攻击者留下的计划任务。此外，公司开始重新签发所有cPGuard授权私钥和公钥，以使攻击者获取的密钥副本失效。
该公司建议管理员采取以下措施：
将cPGuard更新至最新版本，然后确认/etc/cron.d/i93677、/var/tmp/.i93677/以及/var/tmp/.cpg91511_sh等文件已被清除；若未清除，应手动删除；
修改root密码以及服务器上每个本地用户的密码；
生成新的root SSH密钥，并从所有信任旧密钥的服务器上移除旧密钥；在密钥更换完成前，应将相关服务器视为已被入侵；
修改MySQL root密码及任何数据库密码，并轮换root shell历史记录中存在的任何密码、API密钥或令牌；
重置OpsShield计费门户密码并启用双因素认证。
最后，公司表示："如果我们告知您攻击者曾手动登录过您的服务器，请使用11月1日之前的干净备份重建系统。"
OpsShield保持透明，但影响依然真实存在
Dickson Research的弗兰克·迪克森表示："坦白说，很少有厂商会如此坦诚地披露安全事件。OpsShield在这方面值得高度肯定。"
然而，他指出，最糟糕的攻击类型，恰恰是由安全工具本身引发的攻击。更新通道本就被刻意设置为开放状态，而安全工具之所以以root权限运行，是因为它们需要监控一切，"因此这个虚假更新也同样以root权限运行"。
对于一家托管服务提供商而言，一台服务器可能承载着数百个客户网站和数据库。一个MySQL root密码就能打开所有这些数据库的大门，一个root SSH密钥则能授予访问所有信任该密钥的其他服务器的权限。此外，shell历史记录中往往还包含手动输入的密码和令牌信息。
迪克森指出，下游客户可能受到的冲击最为严重，但他们对此却知之甚少，因为大多数网站所有者根本不知道自己的托管服务商运行的是哪款安全代理程序。每一台自动更新的服务器，实际上都在信任厂商的分发渠道。
迪克森表示，OpsShield将自身定位为一家向中小型托管商提供低价服务的小团队，而这恰恰揭示了供应链中一个令人不安的现实："你所面临的风险敞口，是由在你服务器上拥有root权限的最小厂商决定的，而非最大的厂商。"
Infotech技术顾问埃里克·阿瓦基安对此表示认同，他认为这次事件提醒人们，企业软件供应链的安全性，取决于其背后的系统、身份管理及流程的安全性。"即便你竭尽全力保护自身基础设施，仍可能因为一个你所信任的第三方供应商而遭到入侵。"
他指出，此次事件尤其令人担忧的一点在于，攻击者无需逐一攻破数千名客户，只需攻陷单一的分发机制，就能将厂商自身可信的基础设施，转化为攻击其客户的武器。
他表示，第三方会扩大风险敞口，而这一事实目前仍被企业所低估。"企业需要在第三方及供应链风险管理方面投入更多关注。"
零信任已成必备策略
阿瓦基安还指出，此次事件对下游客户的影响可能远不止于最初的入侵，因为被窃取的凭证还可能被用于发起进一步的攻击。企业应采取零信任方法，将软件供应商及其提供的更新也纳入零信任管理范畴。
他表示："即便某个更新来自可信来源，也不意味着你可以默认它是安全的。"企业应更仔细地审视供应商风险，保护特权凭证，并对软件完整性进行检查。此外，还应在更新完成后持续监控异常行为，一旦出现问题，要能够迅速隔离受影响系统。
他强调："你必须为'即便是可信供应商也可能遭到入侵'这种可能性做好预案，并需要将此类场景的应对演练，纳入定期的桌面推演项目中。"
迪克森建议企业首先从资产盘点入手，清楚掌握每一个以root或管理员权限运行的厂商代理程序，因为每一个这样的程序都是一条潜在的更新通道。客户应向供应商询问更新发布密钥存放在何处，以及这些密钥与面向客户的系统之间采取了哪些隔离措施，同时应监控服务器的出站流量，避免在shell历史记录中保留敏感信息，并将SSH密钥视为具有有效期的凭证来管理。下游客户应直接向其托管服务商询问是否使用了cPGuard，并应主动修改自己的密码。
他表示："你服务器上最危险的软件，或许恰恰是你所信任、用来自动更新自身的那款软件。选择这些供应商时应格外谨慎，因为它们实际上掌握着你系统的root权限。"