新手入门

JetBrains Cadence备份遭入侵:换一个密码远远不够

|作者: QUASA 编辑团队|2 分钟阅读| 1
JetBrains Cadence备份遭入侵:换一个密码远远不够

截至2026年9月3日,JetBrains已结束对Cadence安全事件的调查。JetBrains更新后的事件通报 确认,攻击者利用TeamCity漏洞CVE-2026-63077攻破api.cadence.jetbrains.com,访问了2024年完整服务器备份;恶意活动始于8月8日,JetBrains于8月23日发现入侵,并在次日将服务器下线。

调查结束不等于用户侧处置已经完成。The Hacker News的独立报道 复核了备份、AWS IAM凭据和JetBrains账户内S3文件受影响的情况;因此,曾把外部凭据交给Cadence执行环境的团队应逐项撤销密钥并检查相应系统,而不能只修改JetBrains账户密码。

先区分确认受影响与预防性核验

团队依据2024年Cadence备份清单确认历史凭据和项目文件是否进入受影响范围

最明确的处置对象是JetBrains已经直接联系的Cadence用户。9月3日新增发现仍涉及同一批用户,没有识别出新的受影响用户;这一定义的是通知范围,并不意味着团队可以只检查当前项目配置。

确认事实包括:攻击者提取了用户名、真实姓名、邮箱、最后登录时间和最后访问IP等个人数据;访问了2024年服务器备份中的数据;多个用于Cadence的AWS IAM用户及相关凭据或秘密遭到破坏;JetBrains用于Cadence的AWS账户内有S3文件被访问。备份内的凭据、配置、制品和日志均须按可能暴露处理,即使它们后来已从当前配置删除。

团队可据此把范围分为三类:

  • 确认需要响应:收到直接通知,或者能够确认仍然有效的凭据曾存在于Cadence、同步的项目文件、环境变量、执行脚本、制品或日志中。
  • 需要预防性核验:曾通过PyCharm插件上传或同步项目,或让Cadence连接外部系统,但无法完整还原当时提供了哪些秘密。历史用户可以向JetBrains安全团队申请凭据清单,但该清单并非完整记录。
  • 不在本次Cadence范围内:从未使用Cadence、仅使用其他JetBrains产品。自行部署的TeamCity是否受同一漏洞影响,应作为另一项检查处理,不能仅凭Cadence事件推定其已经失陷。

按可造成的后果安排轮换顺序

团队按生产访问、云IAM、对象存储和发布链的风险顺序撤销旧凭据

Cadence插件连接服务所用的访问令牌已经失效,但这项措施不会撤销AWS、Azure、Google Cloud、GitHub、GitLab、Bitbucket、软件包仓库、容器注册表或部署平台自行签发的凭据。密码和这些外部令牌属于不同的授权边界,这正是“换一个密码”不够的原因。

以下次序是根据凭据可触达的资源和潜在后果整理的响应优先级,而不是官方公布的固定队列。若Webhook、软件包令牌或签名密钥能够直接触发生产发布,应把它提前到第一批。

  1. 先切断生产访问。立即禁用生产部署密钥、高权限服务账户、可修改基础设施的云密钥、SSH或部署密钥,以及可读写生产数据的令牌。确认旧凭据失效后,再签发权限更小的新凭据并更新自动化任务。
  2. 再处理云IAM与对象存储。检查AWS、Azure和Google Cloud中的用户、角色、策略、长期访问密钥及跨账户信任;同时核对S3等对象存储的列举、读取、下载、写入和策略修改活动。尚未确认客户存储桶被访问,不代表连接存储桶的凭据可以保留。
  3. 随后轮换代码与发布链凭据。处理GitHub、GitLab和Bitbucket的个人访问令牌、部署密钥及服务账户,再检查npm、Maven、NuGet、PyPI和容器注册表的发布凭据。
  4. 清理其余集成秘密。覆盖API令牌、Slack令牌、Webhook、证书和签名材料。若签名密钥可能被读取,还要按组织的吊销机制处理,并核验风险期间生成的制品,不能只创建新密钥。

轮换密钥后仍要审计外部活动

撤销凭据只能阻止它继续被使用,不能证明此前没有发生操作。审计窗口至少应从2026年8月8日开始,并延续到旧凭据被禁用;若平台仍保留更完整的历史记录,可用它建立正常访问基线,但目前没有公开证据表明攻击者在8月8日前已进入Cadence。

云平台应检查异常来源的认证、陌生API调用、新建服务账户、IAM角色或策略变化,以及对象存储的异常列举和下载。代码托管系统应核对仓库克隆、提交、协作者、部署密钥、Webhook和令牌变化;软件包与容器平台则要检查异常版本、被覆盖的发布物、陌生镜像和签名状态。

出现可疑活动时,应先保存云审计日志、仓库记录、构建日志、制品摘要和时间戳,再隔离相关凭据或执行节点。Cadence执行的输入与输出都被列为潜在不可信,由这些执行产生并进入后续流水线的制品也需要重新验证来源和完整性。

TeamCity出现陌生代理不一定是成功入侵

已修补的TeamCity通过日志识别被阻断的利用尝试并限制服务器访问

自行部署TeamCity的团队需要把已阻断的探测与成功利用分开。JetBrains的TeamCity支持说明 显示,安装安全补丁或升级至2026.1.3、2025.11.7后,代理列表仍可能出现名为scan-随机数字的未授权代理;若日志同时出现ForbiddenClassException且没有ConversionException,这一组合表示载荷已被拒绝。

符合上述特征的代理记录可以删除,但反复出现说明扫描流量仍能到达服务器,可通过VPN、防火墙、IP允许列表或反向代理缩小暴露面。若服务器在相关时间段没有修补,或者日志不符合阻断特征,就不能因代理迅速断开而判定安全,应保留记录并按潜在成功利用调查。

调查结束后仍有哪些边界

当前Cadence环境中的邮箱、项目源代码和凭据属于可能暴露:攻击者获得了可能触达相关存储的访问能力,但公开结论没有证明其中每一项数据都被提取。客户自有存储桶是否被访问同样没有得到确认;已经确认被访问的是JetBrains用于Cadence的AWS账户内S3文件。

截至9月3日,受影响服务器已经下线,Cadence插件访问令牌已经失效,调查已经结束,且没有新增受影响用户。攻击者身份、受影响记录总量以及客户存储桶的实际访问范围仍未公开。

因此,用户侧的完成标准不是“JetBrains密码已经修改”,而是所有曾进入Cadence执行路径且仍有效的秘密均已撤销或确认失效,对应的云、存储、代码与发布系统已完成审计,任何异常访问和不可信制品也已单独处置。

分享:

订阅我们的新闻通讯

将最新 Web3、AI 和加密货币新闻直接发送到您的邮箱。

0