Cloudflare 今天披露，其内部 Atlassian 服务器被一名疑似“民族国家攻击者”入侵，该攻击者访问了其 Confluence wiki、Jira bug数据库和 Bitbucket 源代码管理系统。

攻击者首先于 11 月 14 日获得对 Cloudflare 自托管 Atlassian 服务器的访问权限，然后在侦察阶段后访问该公司的 Confluence 和 Jira 系统。

事件详情

2023 年 11 月 23 日感恩节，Cloudflare 在我们的自托管 Atlassian 服务器上检测到攻击者。我们的安全团队立即开始调查，切断了攻击者的访问权限，并于 11 月 26 日星期日引入了 CrowdStrike 的取证团队来进行他们自己的独立分析。

昨天，CrowdStrike 完成了调查，我们将发布此博文来讨论此安全事件的详细信息。

我们想向客户强调，Cloudflare 客户数据或系统没有受到此事件的影响。由于我们的访问控制、防火墙规则以及使用我们自己的零信任工具强制执行的硬安全密钥，攻击者横向移动的能力受到限制。没有涉及任何服务，也没有对我们的全球网络系统或配置进行任何更改。这是零信任架构的承诺：它就像一艘船上的舱壁，其中一个系统的妥协不会损害整个组织。

从 11 月 14 日到 17 日，攻击者进行了侦察，然后访问了我们的内部 wiki（使用 Atlassian Confluence）和我们的bug数据库 (Atlassian Jira)。 11 月 20 日和 21 日，我们看到额外的访问表明他们可能已经回来测试访问以确保他们具有连接性。

然后，他们于 11 月 22 日返回，并使用 ScriptRunner for Jira 建立了对我们的 Atlassian 服务器的持久访问，获得了对我们源代码管理系统（使用 Atlassian Bitbucket）的访问权限，并尝试访问有权访问数据的控制台服务器，但没有成功,Cloudflare 尚未在巴西圣保罗投产。

他们通过使用一个访问令牌和三个服务帐户凭据来做到这一点，这些凭据已被盗取，但我们在2023 年 10 月的 Okta 泄露后未能进行更换。所有攻击者的访问和连接均于 11 月 24 日终止，CrowdStrike 已确认威胁活动的最后证据是在 11 月 24 日上午 10:44。

（本博文中所有日期和时间均为 UTC。）

尽管我们知道该事件对运营的影响极其有限，但我们非常严肃地对待这一事件，因为攻击者使用被盗的凭据来访问我们的 Atlassian 服务器并访问了一些文档和有限数量的源代码。根据我们与行业和政府同事的合作，我们认为这次攻击是由民族国家攻击者发起的，目的是获得对 Cloudflare 全球网络的持久和广泛的访问。

“红色代码”修复和强化工作

11 月 24 日，在攻击者从我们的环境中被删除后，我们的安全团队召集了全公司所需的所有人员来调查入侵事件，并确保攻击者已被完全不能访问我们的系统，并确保我们了解他们访问或尝试访问的内容的全部范围。

然后，从 11 月 27 日开始，我们将大部分 Cloudflare 技术人员（安全团队内部和外部）的精力转移到一个名为“Code Red”的项目上。重点是加强、验证和补救我们环境中的任何控制，以确保我们免受未来的入侵，并验证攻击者无法访问我们的环境。此外，我们继续调查每个系统、帐户和日志，以确保攻击者没有持续访问权限，并且我们完全了解他们接触过哪些系统以及他们试图访问哪些系统。

CrowdStrike 对攻击者活动的范围和程度进行了独立评估，包括寻找他们仍然存在于我们系统中的任何证据。 CrowdStrike 的调查为我们的调查提供了有用的佐证和支持，但没有揭示我们错过的任何活动。这篇博文详细概述了我们和 CrowdStrike 发现的有关攻击者活动的所有内容。

攻击者可以使用被盗凭证访问的唯一生产系统是我们的 Atlassian 环境。通过分析他们访问的 wiki 页面、bug数据库问题和源代码存储库，他们似乎正在寻找有关我们全球网络的架构、安全性和管理的信息；毫无疑问是为了获得更深的立足点。因此，我们决定需要付出巨大的努力来进一步强化我们的安全协议，以防止攻击者在我们忽略日志文件中的某些内容的情况下获得立足点。

我们的目标是防止攻击者使用有关我们网络运行的技术信息作为重新进入的方式。尽管我们相信并后来证实攻击者的访问权限有限，但我们还是采取了全面的努力来更换每个产品凭据（超过 5,000 个个人凭据）、物理分段测试和暂存系统、对 4,893 个系统执行取证分类、重新映像并重新启动我们全球网络中的每台计算机，包括攻击者访问的所有系统以及所有 Atlassian 产品（Jira、Confluence 和Bitbucket）。

攻击者还尝试访问我们位于圣保罗的新数据中心（尚未投入生产）中的控制台服务器。所有获取访问权限的尝试均未成功。为了确保这些系统 100% 安全，巴西数据中心的设备已返还给制造商。制造商的取证团队检查了我们的所有系统，以确保没有获得任何访问或持久性。虽然什么也没找到，但我们还是更换了硬件。

我们还查找了尚未更新的软件包、可能已创建的用户帐户以及未使用的活跃员工帐户；我们去寻找可能留在 Jira 票证或源代码中的秘密，检查并删除了上传到 wiki 的所有 HAR 文件，以防它们包含任何类型的令牌。每当有疑问时，我们都会做出最坏的打算并做出更改，以确保攻击者能够访问的任何内容将不再被使用，因此对他们不再有价值。

我们鼓励团队的每个成员指出攻击者可能接触过的区域，以便我们可以检查日志文件并确定攻击者的访问范围。通过在公司范围内吸纳如此多的人员，我们的目标是不遗余力地寻找访问证据或为提高安全性而需要进行的更改。

直接的“红色代码”工作于 1 月 5 日结束，但整个公司围绕凭证管理、软件强化、漏洞管理、额外警报等方面的工作仍在继续。

攻击时间表

这次攻击于 10 月份随着 Okta 的泄露而开始，但攻击者直到 11 月中旬才开始使用 Okta 泄露的凭证来针对我们的系统。

以下时间线显示了主要事件：

10 月 18 日 – Okta被入侵

我们之前已经写过相关文章，但总而言之，我们（第二次）成为 Okta 系统被入侵的受害者，导致攻击者获得了一组凭据的访问权限。这些凭证本应全部更换。

不幸的是，我们未能更换在 Okta 泄露期间泄露的一个服务令牌和三个服务帐户（数千个）凭证。

其中之一是 Moveworks 服务令牌，它允许远程访问我们的 Atlassian 系统。第二个凭证是基于 SaaS 的 Smartsheet 应用程序使用的服务帐户，该应用程序对我们的 Atlassian Jira 实例具有管理访问权限；第三个帐户是 Bitbucket 服务帐户，用于访问我们的源代码管理系统；第四个帐户是 AWS无法访问全球网络且没有客户或敏感数据的环境。

一个服务令牌和三个帐户没有更换，因为人们错误地认为它们未被使用。这是不正确的，这就是攻击者首先进入我们的系统并持久使用我们的 Atlassian 产品的方式。请注意，这绝不是 AWS、Moveworks 或 Smartsheet 的错误。这些只是我们未能更换的凭证。

11 月 14 日 09:22:49 – 攻击者开始探测

我们的日志显示，攻击者从 11 月 14 日开始对我们的系统进行探测和侦察，寻找使用凭据的方法以及可访问哪些系统。他们尝试登录我们的 Okta 实例，但访问被拒绝。他们尝试访问 Cloudflare 仪表板，但被拒绝访问。

此外，威胁参与者还访问了用于为 Cloudflare 应用程序市场提供支持的 AWS 环境。该环境被分段，无法访问全球网络或客户数据。访问此环境的服务帐户已被撤销，我们验证了环境的完整性。

11 月 15 日 16:28:38 – 攻击者获得了 Atlassian 服务的访问权限

攻击者于 11 月 15 日使用 Moveworks 服务令牌通过我们的网关进行身份验证，成功访问 Atlassian Jira 和 Confluence，然后他们使用 Smartsheet 服务帐户获取对 Atlassian 套件的访问权限。第二天，他们开始寻找有关我们全球网络的配置和管理的信息，并访问了各种 Jira 票证。

攻击者在 wiki 中搜索了远程访问、秘密、客户端秘密、openconnect、cloudflared 和令牌等内容。他们访问了 36 个 Jira 票证（总共 2,059,357 个票证）和 202 个 wiki 页面（总共 194,100 个页面）。

攻击者访问了有关漏洞管理、秘密更换、MFA 绕过、网络访问，甚至我们对 Okta 事件本身的响应的 Jira 票证。

维基搜索和访问的页面表明，攻击者对访问我们系统的各个方面都非常感兴趣：密码重置、远程访问、配置、Salt 的使用，但他们并不针对客户数据或客户配置。

11 月 16 日 14:36:37 – 威胁参与者创建 Atlassian 用户帐户

攻击者使用 Smartsheet 凭证创建了一个看起来像普通 Cloudflare 用户的 Atlassian 帐户。他们将此用户添加到 Atlassian 中的多个组中，以便在删除 Smartsheet 服务帐户时他们可以持久访问 Atlassian 环境。

11 月 17 日 14:33:52 至 11 月 20 日 09:26:53 – 威胁参与者暂停访问 Cloudflare 系统

在此期间，攻击者暂停了对我们系统的访问（除了明显地短暂测试他们仍然具有访问权限之外），并在感恩节前返回。

11 月 22 日 14:18:22 – 攻击者获得持久性控制

由于 Smartsheet 服务帐户具有对 Atlassian Jira 的管理访问权限，威胁参与者能够安装 Sliver 对手仿真框架，这是一种广泛使用的工具和框架，红队和攻击者使用它来启用“C2”（命令和控制），连接获得对安装它的计算机的持久和隐秘的访问。 Sliver 是使用 ScriptRunner for Jira 插件安装的。

这使得他们能够持续访问 Atlassian 服务器，并利用它来尝试横向移动。通过此访问，攻击者尝试访问我们巴西圣保罗数据中心的非生产控制台服务器，因为 ACL 未强制执行。访问被拒绝，他们无法访问任何全球网络。

第二天，攻击者查看了 120 个代码存储库（总共 11,904 个存储库）。在这 120 个存储库中，攻击者使用了 76 个存储库上的 Atlassian Bitbucket git 存档功能将它们下载到 Atlassian 服务器，尽管我们无法确认它们是否已被泄露，但我们决定将它们视为已被泄露。

这 76 个源代码存储库几乎都与备份的工作方式、全球网络的配置和管理方式、身份在 Cloudflare 中的工作方式、远程访问以及我们对 Terraform 和 Kubernetes 的使用有关。少数存储库包含加密的秘密，即使它们本身经过严格加密，也会立即更换。

我们特别关注这 76 个源代码存储库，以寻找嵌入的秘密（存储在代码中的秘密被更换）、漏洞以及攻击者可以利用它们发起后续攻击的方式。这项工作是整个公司的工程团队作为“红色代码”的一部分优先完成的。

作为一家SaaS公司，我们长期以来一直认为，我们的源代码本身并不像向最终用户分发软件的软件公司的源代码那么珍贵。事实上，我们已经开源了大量的源代码，并通过我们的博客公开谈论我们使用的算法和技术。因此，我们的重点不是有人可以访问源代码，而是该源代码是否包含嵌入的秘密（例如密钥或令牌）和漏洞。

11 月 23 日 – 发现和攻击者访问终止

我们的安全团队于 16:00 收到攻击者存在的警报，并在 35 分钟后停用了 Smartsheet 服务帐户。 48 分钟后，攻击者创建的用户帐户被发现并被停用。以下是发出第一个警报后为阻止攻击者而采取的主要行动的详细时间表。

15:58 – 威胁参与者将 Smartsheet 服务帐户添加到管理员组。
16:00 – 15:58 自动向我们的安全团队发出有关更改的警报。
16:12 – Cloudflare SOC 开始调查该警报。
16:35 – Smartsheet 服务帐户被 Cloudflare SOC 停用。
17:23 – 攻击者创建的 Atlassian 用户帐户被发现并被停用。
17:43 – 宣布内部 Cloudflare 事件。
21:31 – 制定防火墙规则来阻止攻击者的已知 IP 地址。

11 月 24 日 – Sliver被移除；所有攻击者访问均已终止

10:44 – 最后已知的攻击者活动。
11:59 – Sliver被移除。

在整个时间线中，攻击者尝试访问 Cloudflare 的无数其他系统，但由于我们的访问控制、防火墙规则以及使用我们自己的零信任工具强制执行的硬安全密钥而失败。

需要明确的是，我们没有看到任何证据表明攻击者可以访问我们的全球网络、数据中心、SSL 密钥、客户数据库或配置信息、我们或客户部署的 Cloudflare Workers、AI 模型、网络基础设施或我们的任何Workers KV、R2 或 Quicksilver 等数据存储。他们的访问权限仅限于 Atlassian 套件和运行 Atlassian 的服务器。

我们“红色代码”工作的很大一部分是了解攻击者可以访问什么以及他们试图访问什么。通过查看跨系统的日志记录，我们能够跟踪对内部指标、网络配置、构建系统、警报系统和发布管理系统的尝试访问。根据我们的审查，他们访问这些系统的尝试均未成功。 CrowdStrike 独立地对攻击者的活动范围和程度进行了评估，该评估没有揭露我们错过的活动，并得出结论认为威胁活动的最后证据是在 11 月 24 日上午 10:44。

我们相信，通过我们的调查和 CrowdStrike 的调查，我们完全了解攻击者的行为，并且他们仅限于我们看到其活动的系统。

结论

这是一起安全事件，涉及一位经验丰富的参与者，很可能是一个民族国家，他的行动方式深思熟虑、有条不紊。我们已采取努力，确保该事件的持续影响有限，并做好充分准备，抵御未来任何复杂的攻击。这需要大量 Cloudflare 工程人员的努力，并且在一个多月的时间里，这是 Cloudflare 的最高优先级。整个 Cloudflare 团队致力于确保我们的系统安全、了解攻击者的访问、修复当前的优先事项（例如大规模凭证更换），并制定长期工作计划，以根据领域提高我们的整体安全性在此过程中发现的改进。

我非常感谢 Cloudflare 的每个人，他们在感恩节假期期间迅速做出反应，进行初步分析并锁定攻击者以及所有为此做出贡献的人。我们不可能说出所有参与人员的名字，但他们长时间的工作和专注的工作使得我们能够对 Cloudflare 的安全性进行必要的审查和更改，同时保持我们的全球网络运行和客户服务运行。

我们感谢 CrowdStrike 能够立即进行独立评估。现在他们的最终报告已经完成，我们对内部分析和入侵修复充满信心，并发布了这篇博文。

威胁情报（IOC）

以下是我们从该攻击者处看到的威胁情报 (IOC)。我们发布这些信息，以便其他组织，尤其是那些可能受到 Okta 漏洞影响的组织，可以搜索其日志以确认同一攻击者没有访问其系统。

cloudflare发布的twitter

cloudflare发布的声明

blog.cloudflare.com

cloudfalre做得好是有原因的。