最近的网络攻击利用了持续集成/持续交付 (CI/CD)管道和开发人员工具中的弱点,因此需要提高开发人员基础设施的安全性。值得注意的是,无论环境多么安全,Codecov 供应链攻击都警告所有人不要在 CI/CD 环境变量中存储机密。


通过破坏数千名开发人员使用的 Bash 上传器,Codecov 攻击者设法从客户环境中窃取凭据、密钥和 API 令牌,两个月内仍未被发现,据报道,此外,据报道还破坏了数百个受限制的客户网络。同样,对 Jenkins、GitHub Actions 和云原生容器化环境等自动化工具的攻击进一步促使公司探索和部署这些工具的有效防御措施。

以下是确保 CI/CD 管道保持安全的一些最佳实践。


1. 停止在 CI/CD 环境中存储机密

Codecov供应链攻击取得巨大成功背后的原因仍然是攻击者泄露的环境变量包含硬编码的秘密,包括密码、令牌和密钥。由于其中一些凭证让攻击者可以访问公司的私有 GitHub 存储库,因此这些私有存储库可能会发生进一步的数据泄露,其中包含本应保密的数据。 

 

尽管包括 HashiCorp、Twilio、Rapid7 和Monday.com在内的多个 Codecov 客户披露了供应链攻击的影响,但迄今为止曝光的最严重的数据泄露事件发生在日本电子商务巨头 Mercari。 在 Codecov 攻击之后,超过 27,000 条与 Mercari 客户的财务、商家、业务合作伙伴、公司员工、承包商和各种实体有关的记录暴露给未经授权的外部参与者。


诚然,这些攻击中的每一个都可能始于 Codecov 漏洞,有些人质疑为什么将客户财务记录等个人身份信息 ( PII ) 存储在私有 GitHub 存储库中。


存储在 CI/CD 环境中的HashiCorp 的 GPG 私钥也引起了类似的担忧。这是用于签署和验证 HashiCorp 发布的软件版本的密钥。在密钥被撤销之前,攻击者可能已经滥用密钥在恶意软件版本上伪造 HashiCorp 的签名。

“为什么没有人谈论 Vault 的制造商 HashiCorp 将他们的签名密钥存储为 ENV 的事实?亲爱的我......这让我对自己的生活感觉更好,”一位开发者在推特上写道。


组织需要重新考虑哪些机密可以存储在 CI/CD 工具、环境变量和私有 GitHub 存储库中。如果应用程序需要将凭证或令牌存储在这些位置,最好将凭证存储到具有最低权限的帐户或资源中,这正是完成任务所必需的 — 通常称为最小权限原则。这样,即使秘密确实在前所未有的攻击中暴露出来,损害也得到了控制。


2. 审查自动拉取请求和计划任务

GitHub Actions 等 CI/CD 自动化工具允许开发人员为其代码存储库设置计划任务,例如自动审查和处理传入的拉取请求。但是,如果向开源项目提出拉取请求的贡献者有恶意,会发生什么?


2021 年 4 月,GitHub Actions 被攻击者滥用,他们向数百个存储库发出自动拉取请求,目的是使用 GitHub 的基础设施挖掘加密货币。此次大规模攻击发生在 2 月初报告了 GitHub Actions 的“缺陷”之后。

至少,这些拉取请求可以滥用 GitHub 的服务器来挖掘加密货币或执行攻击者的恶意代码。如果项目所有者疏忽并合并这些拉取请求,他们现在已经将恶意代码引入到他们的存储库和更广泛的软件供应链中。5 月,GitLab报告称,攻击者滥用分配给新帐户的“免费分钟数”(配额),在其平台上解决了类似的加密货币挖矿攻击。


因为像 GitHub Actions 和 GitLab 这样的 CI/CD 自动化工具的本质是提供自动化关键任务的便利,所以守门成为一个挑战。在被威胁行为者滥用之后,原本可能是有意设计的功能很快就会变成安全漏洞。

GitHub 最近宣布了新功能,以防止加密攻击者滥用其 Actions 平台:“在任何 Actions 工作流程运行之前,来自首次贡献者的拉取请求将需要具有写访问权限的存储库合作者的手动批准。当首次贡献者打开拉取请求时,他们会看到一条消息,表明维护者必须在其 Actions 工作流运行之前批准其工作流程,”GitHub 产品经理 Chris Patterson 在一篇博客文章中说道。


领先的 CI/CD 解决方案和 DevOps 平台可以效仿 GitHub,添加一些安全检查,以阻止恶意行为者大规模滥用其基础设施。

3. 强化并定期审核您的云原生容器

没有什么比遵循标准最佳实践更好的了,例如确保正确配置生产容器并针对常见的攻击媒介进行加固。这包括保护您的管道配置。

然而,简单的错误配置错误有时很难被人类发现。那么问题来了,您的基于 Docker 的环境是否没有漏洞?这就是为什么定期对容器的弱点执行安全审计,扫描容器镜像和清单文件以发现常见的安全问题仍然很有帮助。

建议投资可靠的云原生容器安全解决方案,以实现大部分自动化。每年报告的大量安全漏洞使得人类几乎不可能跟踪它们。

此外,随着公司采用 Kubernetes 框架和 Docker 容器来部署其应用程序,具有内置 Web 应用程序防火墙的容器安全解决方案可以及早检测和阻止可疑的网络流量。这有助于防止更大的危害,即使攻击者能够渗透容器并获得初始访问权限。

4.集成深度代码扫描,自动化代码质量检查

在代码提交进入生产环境之前,拥有工具来自动发现代码质量问题、安全漏洞以及诸如内存泄漏或竞争条件之类的错误,是从一开始就保护 CI/CD 管道的有效策略。尽管重点似乎主要是防止网络攻击,但无害的错误也可能产生大规模影响。我们最近在全球Fastly 中断中看到了这一点,该中断使世界各地的主要站点脱机。

GitHub 代码扫描器或 Sonatype 的Lift [完全披露:Sonatype 是我的雇主]等解决方案无缝集成到您现有的编码工作流程中,并免费为开发人员提供基本的保护措施。最终,组织的目标应该是支持其开发人员尽其所能地工作,同时尽可能地防止在应用程序中引入错误或安全漏洞。这需要发生,同时尽量减少开发和安全团队之间的摩擦。在这里,实时通知提醒开发人员在编写代码时可能出现疏忽,可以节省每个人的时间并从一开始就保护整个 CI/CD 工作流程。 

5. 尽早修补最新的 CI/CD 工具漏洞

2021 年 3 月,攻击者使用名为z0Miner 的加密挖掘僵尸网络在易受攻击的 Jenkins 和 ElasticSearch 服务器上挖掘门罗币 (XMR) 加密货币。通过利用面向 Internet 的服务器中的远程代码执行 (RCE) 漏洞,攻击者试图感染并接管自动化基础设施以进行他们的恶意活动。

同样,正如去年报道的那样,攻击者可能会利用Jenkins 服务器来迅速造成分布式拒绝服务 (DDoS)。这是由 UDP 放大反射 DoS 漏洞引起的,跟踪为 CVE-2020-2100,它影响低于 Jenkins v2.219 和低于 2.204.1 的 Jenkins LTS 版本。

一旦发现这些严重漏洞,立即针对这些严重漏洞修补自动化工具和管道对于确保 CI/CD 基础架构的安全性仍然至关重要。 

6. 在应用更新之前验证更新的完整性

应用最新的更新和补丁是合理的建议,但您确定您收到的更新没有被篡改吗?在SolarWinds 供应链攻击之后,几十年来一直是安全专业人士的口头禅的坚持不懈地“更新到最新版本”的建议受到了挑战。

在 SolarWinds 事件中,对 Orion IT 产品进行的恶意更新使攻击者能够向下游向18,000 多个客户分发恶意代码。再一次,Passwordstate 密码管理器的“就地升级功能”已被破坏以向 Passwordstate 用户分发恶意更新。因此,盲目应用产品更新是一个坏主意。

在 Codecov 的案例中,简单的完整性检查导致发现长达两个月的违规行为。一位客户注意到托管在服务器上的 Bash 上传器的校验和(哈希)与 Codecov 的 GitHub 存储库中列出的合法校验和之间存在差异,立即联系 Codecov 解决了问题。 

因此,纵深防御方法保证任何更新、补丁和下载的完整性都得到验证,从而排除来自复杂供应链攻击的风险。