从脆弱到胜利:捍卫您的 CI/CD 管道

所有文章

自动化 CI/CD(持续集成/持续交付)管道用于加速开发。拥有触发器或调度来获取您的代码、合并它、构建它、测试它并自动发布它真是太棒了。然而,为了速度和易用性而构建意味着大多数管道在构建时并没有考虑到安全性。由于管道通常需要访问互联网来下载依赖项,并需要访问您的各种秘密才能上传到您的生产环境,这意味着一旦此类管道受到损害,攻击者就有多种选择来破坏您的操作或泄露信息或秘密。

本文中介绍的所有故事都描述了著名 CI/CD 工具中的违规行为。大多数公司依赖此类工具这一事实意味着,就像许多其他公司一样 软件供应链攻击,坏人所需要的只是突破单个目标以获得巨大的爆炸半径。
让我们看一下过去几年中的一些著名故事,这些故事展示了此攻击媒介固有的漏洞。在文章末尾,无论您使用什么工具,我都会确保提供强化和保护管道的建议。

CircleCI 漏洞

2023年XNUMX月,持续集成和交付平台CircleCI披露了 安全漏洞 这使得攻击者能够未经授权访问公司的基础设施。这次攻击是由一封网络钓鱼电子邮件发起的,该电子邮件诱骗员工共享其凭据,然后攻击者用这些凭据访问公司的系统。该员工正在使用 2FA,但一旦员工登录系统,攻击者就能够获取会话 cookie,从而允许他们冒充该员工并最终升级对 CircleCI 生产系统子集的访问权限。

攻击者访问了一些客户数据,包括姓名、电子邮件地址和账单信息。该公司报告称,没有代码或知识产权被访问,也没有客户报告任何未经授权的访问其帐户或数据的情况。

CircleCI 对此次泄露事件做出了迅速反应,进行了调查,并与执法部门和网络安全专家合作,以确定攻击的范围并修复导致攻击发生的漏洞。该公司还重置了所有员工和客户的凭据,并实施了额外的安全措施,例如加强对其系统的监控。

DevOps 中断:Argo CD 安全漏洞

Argo CD 是一种流行的开源工具,用于将应用程序持续部署到 Kubernetes 集群。 2022 年 XNUMX 月, Argo CD 中发现新漏洞 允许未经身份验证的用户访问有关该工具管理的 Kubernetes 应用程序的敏感信息。该漏洞是由 Argo CD 的 API 服务器配置错误引起的,该服务器允许未经授权的用户执行 API 请求并检索机密、配置和应用程序元数据等信息。只要攻击者有权创建或更新应用程序,并且知道或可以猜测包含有效 YAML 的文件的完整路径,他们就可以创建恶意 Helm 图表并继续使用 YAML 文件作为值,直到找到一条有趣的数据,通常是无法访问的。

该漏洞的 CVSS 评分为 7.5(高严重性),影响了 Argo CD 的所有版本,包括版本 2.1.4。 Argo CD在2.1.5版本中针对该漏洞发布了补丁,建议用户尽快升级至该版本。

该漏洞被认为特别令人担忧,因为 Argo CD 通常用于管理生产环境中的关键应用程序和基础设施。敏感信息的泄露可能使攻击者能够访问敏感数据或采取其他可能影响应用程序的可用性或安全性的恶意操作。

揭露 Codecove 漏洞:经验教训

Codecov 是一种在 CI/CD 管道内使用的代码覆盖率跟踪和分析工具,允许开发人员衡量和分析测试的有效性。正如 Codecov 中发布的 安全更新

“1 年 2021 月 XNUMX 日星期四,我们得知有人未经授权访问了我们的 Bash 上传器 脚本并在未经我们许可的情况下对其进行了修改。由于 Codecov 的 Docker 映像创建过程中出现错误,攻击者获得了访问权限,该错误允许攻击者提取修改我们的 Bash Uploader 脚本所需的凭据。”

客户使用 Bash Uploader 将代码覆盖率报告上传到 Codecove 平台。通过此访问权限,攻击者通过添加恶意代码来修改 Bash Uploader 脚本,这些代码在上传过程中从用户系统收集环境变量、身份验证令牌和其他敏感数据。然后,该数据被发送到攻击者控制的远程服务器。

据 Codecove 称,此次泄露影响了大约 1% 的客户群,其中包括技术、金融和医疗保健行业的主要公司。该公司确认,在此次泄露期间,没有客户代码或代码覆盖率报告被更改,但用户身份验证令牌和其他敏感信息可能已被泄露。

Codecove 立即采取行动删除恶意代码,并提醒受影响的客户重置其身份验证令牌并采取其他安全措施。该公司还对该事件展开了调查,并与执法部门和网络安全专家合作,以确定攻击的来源。

如何保护您的管道?

说明管道的图像

数据中心大楼内的冷却塔组。

如上所述,CI/CD 管道是为了速度和自动化而构建的,不一定是为了安全性。 3 家受人尊敬的大公司都成为某种攻击的受害者,可能会暴露其客户的信息,这一事实表明了您自己的管道和数据的脆弱性。
无论您使用什么工具或 CI/CD 平台,您都可以采取一些措施来提高安全性并减少恶意行为者设法访问您的管道或网络时可能造成的损害。

  • 威胁建模 – 威胁建模是一种结构化方法,用于识别系统或应用程序的潜在安全威胁,并设计适当的对策来减轻这些威胁。作为练习,想象有人可以访问您的管道。他们现在可以访问哪些环境?他们可以看到和使用哪些秘密和密钥?他们可以修改你的代码吗?影响测试?从网络上提取文件或运行反向 shell?即使您认为您已经清理了管道并正确分段了网络访问,想象一下然后进行检查以便您了解最坏的情况也没有什么坏处。您可能会对管道平台或工具内隐藏的秘密和访问选项感到惊讶。
  • 网络分段 – 网络分段是将较大的网络划分为更小、更安全的子网或段的做法,每个子网或段都有自己的安全控制和策略。网络分段的目的是通过限制潜在安全漏洞的范围并最大程度地减少攻击的潜在影响来提高整个网络的安全性。将网络分成更小的部分可以限制攻击者的横向移动,并降低未经授权的访问或数据泄露的风险。
    随着网络钓鱼攻击的日益流行,您的任何开发人员或其他员工都可能成为此类骗局的受害者 - 我们都是人。假设您的开发人员的凭据可能被恶意行为者使用,这意味着您需要确保绝大多数开发人员不应拥有允许他们单枪匹马窃取秘密、在生产映像中植入恶意代码的访问权限,或者只是毫无争议地推出他们自己的生产代码版本。确保每个人拥有工作所需的最少访问权限非常耗时,而且只授予每个人管理员访问权限并完成它的诱惑很大。不要被黑暗面所诱惑——遵循零信任和最低特权的规则。
  • 监控和警报 – 从最后一点开始,即使您已经彻底训练您的开发人员对网络钓鱼和其他社会工程诈骗感到厌倦,违规行为仍然可能发生。你不知道何时或如何,但你至少应该准备好了解它。由于大多数管道环境都是短暂的,这意味着一旦工作完成,就无法找到有关所发生事件的证据,除非您自己创建此类跟踪。
    确保记录管道中、每个 PR、合并、构建和测试完成时发生的所有事情。确保用户的信息也被记录下来,以便在出现问题时需要进行此类检查。对配置文件或环境本身的任何更改也应该记录下来。这里的目标是能够对违规行为进行清晰的事后分析,以便能够了解发生了什么以及如何发生。提前确定哪些事件需要发出警报,并确保正确的人员收到警报。不要让人们被无用或错误的警报淹没——这会导致警报疲劳,从而导致他们忽视警报或比建议的时间晚得多。显然,这些日志都不应该包含任何公开的秘密或密钥——这导致了下一个要点:
  • 秘密管理 – 确保您使用某种秘密管理工具。至少,如果确实发生泄露,它会让你更容易轮换你的秘密和密码。它还应该完成从系统上完成的任何日志记录中编辑在管道中找到的公开秘密和访问密钥的工作。任何未经授权的人都不得访问此类信息,并且绝对不能更改这些信息。
    随着组织越来越依赖基于云的服务、容器化应用程序和其他需要跨不同系统和应用程序安全共享和管理机密的分布式环境,机密管理变得越来越重要。
  • 使用RBAC原则结合最小权限 – 基于角色的访问控制 (RBAC) 的原则是根据组织内用户分配的角色或工作职能提供对系统资源的访问。在 RBAC 中,为用户分配角色,定义他们对各种系统资源(例如文件、文件夹或应用程序)拥有的权限和访问权限。另一方面,最小权限原则是授予用户执行其工作职能所需的最低级别的访问和权限的做法。这意味着用户只能访问执行特定任务所需的资源,而不能访问更多资源。 RBAC 和最小权限通常一起用作补充安全原则。在 RBAC 中,用户被分配角色,这些角色对执行其工作职能所需的资源具有适当的访问级别,最小权限原则确保用户只能访问执行其特定任务所需的最低级别的资源。这些原则共同有助于维护安全且管理良好的系统,并将未经授权的访问或数据泄露的风险降至最低。作为额外的安全措施,您可以对其进行设置,以便系统中的关键操作需要多个用户授权才能完成。应谨慎采用此方法,因为它有可能显着减慢开发工作的速度。但是,对于关键更新,例如删除主分支或修改依赖项列表,您应该确保至少两个具有适当访问权限的人需要批准它。

展望

没有人会停止使用 CI/CD 和其他自动化工具来加快工作速度。我们生活在一个不断追求更快的代码更新的世界。我们只需要确保以安全意识的方式进行操作,并且在此过程中不会损害我们的代码和生产环境。

您可以做的最重要的事情之一就是考虑一下如果未经授权的人获得访问权限会发生什么。一旦您意识到危险以及管道和网络中易受攻击的不同位置,我相信您将能够采取正确的步骤来堵住潜在的泄漏。

Scribe 是一家软件供应链安全公司,其平台旨在为您提供开发流程和管道中发生的情况的透明度。了解有关 Scribe 如何帮助您保护管道的更多信息 点击这里联系我们.

此内容由领先的端到端软件供应链安全解决方案提供商 Scribe Security 为您提供 - 为整个软件供应链中的代码工件以及代码开发和交付流程提供最先进的安全性。 了解更多