JetBrains TeamCity 严重缺陷被利用，1400 台服务器受到威胁

超过 1,400 台 TeamCity 服务器因漏洞利用而受到损害。

JetBrains TeamCity 的一个严重漏洞正被积极利用，在 1,400 多台服务器上创建数百个管理员帐户。

JetBrains TeamCity 是一个持续集成和持续开发 (CI/CD) 平台，用于自动化软件项目的构建、测试和部署。周一，JetBrains 修补并披露了一个严重缺陷（编号为 CVE-2024-27198），该缺陷允许绕过身份验证以获得对 TeamCity 服务器的管理控制。

LeakIX周三报道称，1,442 个 TeamCity 本地实例显示出“明显的流氓用户创建迹象”。LeakIX 是一个搜索引擎，可以对互联网连接服务进行索引，并提供有关易受攻击的服务和数据泄露的信息。

TeamCity 漏洞是由 Rapid7 发现的，该公司在周一发布的披露中表示，利用该漏洞将使攻击者“完全控制所有 TeamCity 项目、构建、代理和工件”，从而为潜在的供应链攻击奠定了基础。

JetBrains TeamCity 解决方案工程师 Daniel Gallo 告诉 SC Media：“我们开始收到一些客户的来信，他们在 Rapid7 充分披露漏洞利用示例以及随后的漏洞利用模块后不久就注意到他们的服务器遭到了入侵。” “第一次是在该信息在线发布后几个小时。”

本地 TeamCity 实例的所有管理器都必须升级到版本 2023.11.4，以防止利用 CVE-2024-27198。LeakIX 表示，任何运行有漏洞版本的用户都应该“做出妥协”。

TeamCity 用户应监控服务器是否有异常活动

Gallo 向 SC Media 提供了几条建议，供那些可能迟迟未打补丁或怀疑受到威胁的用户使用。加洛说，首先，用户应该让服务器离线，以将其与外部和内部网络隔离。

加洛解释说，应该检查服务器的“审核”屏幕是否有“创建或删除的未知用户访问令牌、创建的任何未知用户、登录操作等”等操作，这些操作可以通过“用户操作”类别进行过滤。

LeakIX告诉 BleepingComputer，攻击者已在受感染的服务器上创建了 3 到 300 个新用户帐户，其模式是使用八个字母数字字符作为用户名。

检查可疑活动的其他途径包括“teamcity-activities”日志文件，用户在其中检查未知的插件、项目或构建配置，以及主机操作系统上的事件日志，应检查外部进程记录的未知事件，加洛说道。

加洛说：“应检查主机服务器后台是否存在任何无法识别的进程，例如恶意软件、加密货币挖矿和其他未经授权的工具。”

如果检测到可疑活动，服务器应保持隔离，因为所有用户的凭据都会轮换。

“TeamCity 及其主机操作系统有权访问的任何外部服务也会有不同数量的凭证，例如存储库和连接（例如 Slack、AWS、Docker Registries 等）、TeamCity 数据库连接和网络驱动器，”加洛指出。“如果服务器已受到损害，则在此期间连接到服务器的任何构建代理也应被视为受到损害。”

Rapid7 首席安全研究员 Stephen Fewer 告诉 SC Media，任何有受到损害迹象的服务器都应该由事件响应团队进行审查，以揭示泄露的全部范围。

“最佳做法是重建该服务器，包括底层操作系统，这样攻击者所获得的任何持久性都将不再占上风，”Fewer 说。

据 X 帖子称， LeakIX 表示，截至周三，总共检测到 1,711 个存在漏洞的 TeamCity 服务器，低于周一发现的 2,000 个。

Shadowserver 基金会是一家在线跟踪漏洞和恶意活动的非营利组织，该基金会在 X 上表示，它于 3 月 4 日 22:00 UTC 首次检测到 CVE-2024-27198 的利用。截至周三，Shadowserver针对该漏洞的时间序列仪表板目前显示有 1,182 个易受攻击的服务器。

网络安全公司 GreyNoise观察到有 33 个针对 CVE-2024-27198 的恶意 IP 进行利用，其中在 3 月 5 日星期二检测到大量活动。

JetBrains 和 Rapid7 在披露时间上发生冲突

JetBrains和Rapid7都发布了导致关键身份验证绕过缺陷以及被跟踪为CVE-2024-27199 的高严重性路径遍历缺陷的事件时间表。

虽然时间表在接触日期和一般讨论内容方面基本一致，但它们揭示了双方披露理念之间的明显冲突。

JetBrains 于 2 月19 日首次接受 Rapid7 的报告，Rapid7 的时间表称他们于 2 月 15 日首次联系，四天后进行了跟进。

2 月 21 日，JetBrains 保留了这些缺陷的 CVE，并建议在发布修复程序几天后公开披露它们，同时向客户发送有关补丁的电子邮件。JetBrains 表示，这种方法符合其协调披露政策。

Rapid7 回复称，这种做法与其自己的漏洞披露政策相冲突，因为他们认为延迟公开披露是“无声修补”。在对披露政策和 Rapid7对静默补丁的定义进行更多讨论后，JetBrains 表示，它于 2 月 23 日决定不与 Rapid7 协调披露。

JetBrains 于 3 月 4 日发布了 TeamCity 的修复版本，初始版本没有披露安全缺陷，并且在发布版本之前也没有通知 Rapid7。该公司开始向客户发送有关该补丁的电子邮件，并在最初发布大约一个小时后发布了博客文章，披露了安全漏洞。

根据 JetBrains 的说法，在第二篇博文发布几分钟后，Rapid7 联系了 JetBrains，表示他们将在几个小时内发布他们的披露信息。Rapid7 的时间表显示，他们在第二篇博客文章发布之前联系了 JetBrains，称他们计划根据静默补丁政策在 24 小时内发布他们的版本。

Rapid7 关于这些漏洞的博客文章最终在补丁发布后大约五个半小时发布。

“我们最终不同意与 Rapid7 协调披露的原因是他们坚持在向我们的客户提供修复程序的同时发布完整的漏洞利用细节。这将立即为攻击者提供利用 TeamCity 服务器所需的工具，而我们的客户则没有机会应用缓解措施。”Gallo 告诉 SC Media。

“我们完全支持在发布修复程序时及时披露漏洞详细信息。但是，我们仅向客户提供必要的详细信息，以帮助客户了解漏洞的范围和严重性（例如 CVE 详细信息和攻击向量的描述），使他们能够采取适当的行动，而无需披露太多有助于直接利用的信息。”加洛补充道。

Rapid7 拒绝向 SC Media 回应 JetBrains 对其披露时机的批评。

然而，该公司之前在其时间表中引用的有关静默修补的博客文章指出，虽然延迟公开披露漏洞详细信息可以防止“临时攻击者”或“脚本小子”滥用它们，但“你也排除了大量的 IT 保护者。”

“最重要的是，您排除了补丁最重要的受众：常规 IT 管理员和经理，他们需要根据某些风险和严重性标准对传入的补丁流进行排序，并根据情况要求停机和更新计划该标准，”时任研究主任托德·比尔兹利 (Tod Beardsley) 在 2022 年发布的帖子中说道。