DevOps管道攻击日盛！如何绝地反击？

2017年年中，俄罗斯国家支持的攻击者在乌克兰金融软件包中安装了恶意蠕虫。当企业更新其软件时就会被成功感染。自此，NotPetya蠕虫病毒迅速传播，在全球造成数十亿美元的损失。白宫称其为“历史上最具破坏性和代价最高的网络攻击”。 三年后，与俄罗斯相关的攻击者劫持了另一款企业软件SolarWinds的Orion网络监控工具集的软件升级过程，无疑，这起事件再次造成了广泛且深远的影响。针对此事，全球网络安全咨询公司NCC Group的高级安全顾问Viktor Gazdag表示，“访问软件开发管道使攻击者有机会接触网络基础设施，并获得知识产权。”

针对DevOps管道的攻击正在增加

人们盲目地认为，这种类型的攻击只是孤立的，且依赖于高度专业和熟练的攻击者。不幸的现实是，DevOps管道不仅仅是国家行为体的攻击目标，同时也已成为网络犯罪团伙的热门目标。 根据Argon公司于1月份发布的一项研究显示，与2020年相比，2021年针对软件供应链的攻击增长了300%以上。常见的攻击策略包括，在流行的开源包中植入恶意代码或利用已存在的漏洞、破坏CI/CD管道工具，以及利用硬编码凭据和其他错误配置和安全问题。其中，开源组件通道是格外受欢迎的目标。 根据Sonatype公司于2021年9月发布的一项研究显示，与2020年相比，2021年针对开源软件供应链的攻击增加了650%。攻击面非常大。数据显示，超过3700万个组件和包位于Top 4开源生态系统中。2021年开源软件下载量达到2.2万亿次，与2020年相比增长了73%。

为什么DevOps管道易受攻击

软件开发人员通常具有较高的权限级别和访问权限。如果正在生产的软件是为外部使用而设计的，那么影响可能会大得多，攻击者也有机会在最终应用中站稳脚跟。 因此，DevOps管道应该具有更高级别的安全性。而不幸的现实是，它们存在很多薄弱的安全实践以及暴露的基础设施和凭据。例如，您使用Shodan搜索开发工具“Jenkins”，便可以在互联网上看到很多可用和可访问的Jenkins基础架构。 同样糟糕的是，很多时候，CI/CD基础设施也并未得到与企业其他领域同等程度的关注。而随着现代开发实践持续推进，情况正变得越来越糟。 Gartner分析师Dale Gardner解释称，“随着组织转向DevOps，出现了一种‘对开发的一些控制举措有所放松’的趋势。我们想要实现灵活性和敏捷性，而DevOps方法就是我们试图快速获取代码的产物。但人们认为限制和控制举措阻碍了这一点，因此出现了放松的趋势。”

针对DevOps管道的攻击类型

根据Linux基金会开源供应链安全主管David Wheeler的说法，针对DevOps管道最常见的三种攻击类型是依赖项混淆、误植域名和恶意代码注入。

依赖项混淆(Dependency confusion)

提及供应链攻击，就少不了要提“依赖项混淆”(也称为命名空间混淆)，特别是因为这种攻击的简单化和自动化特质，使其日渐受到攻击者的青睐。得益于在多个开源生态系统中发现的固有设计缺陷，依赖项混淆能够在攻击者端通过最小的努力甚至是自动化的方式发挥作用。 简而言之，如果您的软件构建使用私有的、内部创建的依赖项，而该依赖项在公共开源存储库中不存在，那么依赖项混淆就会起作用。攻击者能够在公共存储库上以相同的名称注册具有更高版本号的依赖项。然后，很大的可能是，攻击者创建的具有更高版本号的(公共)依赖项——而非您的内部依赖项——将被拉入您的软件构建中。 2021年2月，通过利用PyPI、npm和RubyGems等常用生态系统中的这个简单缺陷，道德黑客Alex Birsan成功地入侵35家大型科技公司，并为此获得了超过130,000美元的漏洞赏金奖励。在Birsan的研究成果披露几天后，数以千计的依赖项混淆模仿包开始涌入PyPI、npm 和其他生态系统。 解决依赖项混淆的方法有很多： 在攻击者之前抢先在公共存储库上注册所有(你的)私有依赖项的名称。 使用自动化解决方案，例如软件开发生命周期(SDLC)防火墙，以防止冲突的依赖项名称进入您的供应链。 开源存储库的所有者可以采用更严格的验证过程并实施命名空间/范围界定。例如，如果想要在“CSO”命名空间、范围下注册依赖项，那么开源存储库可以先验证注册的开发人员是否有权以“CSO”的名义这样做。

误植域名(Typosquatting)

Typosquatting中的“typo”指的是人们在键盘上打字时可能犯的小错误。Typosquatting也被称为URL劫持、误植域名、域名模仿、毒刺网站或虚假URL，在这种网络犯罪形式中，黑客使用故意拼写错误的知名网站名称注册域名。黑客这样做是为了引诱不知情的访问者访问替代网站，通常为了恶意目的。访问者可能通过以下两种方式之一访问这些替代网站： 无意中将热门网站的名称错误输入到网络浏览器中，例如 gooogle.com 而不是google.com。 被作为更广泛的网络钓鱼攻击的一部分引诱到网站。 黑客可能会模仿他们试图模仿的网站的外观，希望用户泄露信用卡或银行详细信息等个人信息。或者网站可能是包含广告或色情内容的优化着陆页，为其所有者产生高收入来源。 最早且最著名的Typosquatting攻击示例涉及Google。2006年，网址劫持者注册了网站Goggle.com，用作钓鱼网站操作。多年来，Google名称的变体foogle、hoogle、boogle、yoogle(所有这些都是因为它们靠近qwerty 键盘上的字母“g”)都已经被注册，试图转移搜索引擎的一些流量。 此外，包括麦当娜、帕丽斯·希尔顿和珍妮弗·洛佩兹在内的名人也都沦为过Typosquatting的牺牲品。而在2020年美国总统大选之前，许多候选人也都被具有各种恶意动机的犯罪分子以他们的名义设置了Typosquatting域名。 对于组织来说，最好的防御策略是尽量保持领先于Typosquatting攻击： 先于网址劫持者注册您的域名的错别字版本。购买重要和明显的错别字域，并将这些重定向到您的网站。 使用ICANN (互联网名称与数字地址分配机构)的监控服务。网站所有者可以使用ICANN的商标清算所了解其名称在不同域中的使用情况。 使用SSL证书发出信任信号。SSL证书是表明您的网站合法的绝佳方式，它们会告诉最终用户他们与谁连接，并在传输过程中保护用户数据。 通知利益相关方。如果您认为有人冒充(或准备冒充)您的组织，请告知您的客户、员工或其他相关方注意可疑电子邮件或网络钓鱼网站。 关闭可疑网站或邮件服务器。

恶意代码注入

代码注入是指攻击者将恶意代码添加到合法开源项目中。他们可以通过窃取项目维护者的凭据并以他们的名义上传代码，或篡改开源开发工具来做到这一点。 2021年，明尼苏达大学的研究人员被踢出了Linux贡献群体，Linux内核社区也撤销了他们之前提交的所有Linux内核代码，原因在于他们故意提出有缺陷的“补丁”，而这些“补丁”又会在Linux内核源代码中注入漏洞。尽管该事件被积极制止，但还是证实了一个结论：开发人员分布广泛，并且没有足够的宽带来审核他们提交的每一个代码，这些代码可能是存在缺陷的或完全是恶意的。 更重要的是，社会工程学可能来自最不受怀疑的来源——在上述案例中，具有“.edu”后缀的电子邮件地址就看似来自可信的大学研究人员。 另外一个突出案例是，任何为GitHub项目做出贡献的合作者都可以在发布后更改版本。在此需要强调，GitHub项目所有者的期望是大多数贡献者都能真诚地提交代码到他们的项目之中。但正可谓“一个老鼠坏一锅汤”，只要一个合作者不规矩就会损害许多人的供应链安全。

如何保护软件开发管道

企业组织应该做些什么来保护他们的软件开发管道?它应该从教育和培训开发人员开始，建立最佳实践(两因素身份验证和代码审查)，并安装监控工具来标记可疑活动。

从开发人员入手

在代码开发和部署过程的安全性方面，内部开发人员和第三方软件商店都需要监督。 当使用第三方软件开发公司时，我们需要非常严格地审查他们，这包括审查他们的测试程序，以及他们在开发环境中实施的安全控制，以确保他们有适当的流程和控制措施，可以交付我们足够安全的东西。 而对于公司内部开发人员来说，最大的问题是不要使用可公开访问的代码存储库，因为它将允许威胁参与者访问你正在进行的任何事情。 此外，还可以通过对企业软件进行渗透测试来进一步提升开发安全性。事实上，在对企业软件进行渗透测试时，开发人员总是会要求参与测试并观看白帽黑客的工作，因为他们想要了解自己在做什么，并从渗透测试人员发现的漏洞中学习。它给了开发人员一种不同的思考方式。

使用适当的工具和控件

为了帮助公司的开发人员做出正确的决定并确保他们的安全，企业组织可以实施多项安全控制措施，例如，多因素身份验证有助于防止外人访问DevOps管道;使用私有代码库，以便开发人员可以从已经审查和批准的代码中进行挑选。 有条件的企业还可以组建专门负责修补系统的团队，定期扫描整个企业环境以寻找漏洞，同时确保部署的所有内容都是最新的。 此外，企业组织还可以部署其他措施来保护开发渠道，例如，为非生产暂存环境和生产环境设置单独的管道，并限制可以访问这两个系统的人员。为了进一步锁定访问权限，公司还应该使用企业级访问管理系统，例如Active Directory或LDAP。 最后，建议企业组织完全跟踪进入其软件的所有组件，尤其是开源库。开发人员倾向于在他们的软件中包含开源代码，但它可能存在错误和安全漏洞。

要求获取软件材料清单(SBOM)，但也要扫描漏洞

许多业内人士一直在推行和倡导软件材料清单(SBOM)。去年5月，拜登总统发布了一项行政命令，要求向联邦政府提供软件的供应商提供SBOM。两天后，云原生计算基金会发布了一份最佳实践白皮书，建议所有供应商在可能的情况下提供SBOM，并提供明确和直接的依赖项链接。 SBOM将帮助公司在其环境中找到易受攻击组件的实例，以做出明智的风险决策。例如，Log4j漏洞早在2021年12月份就进行了修补，但截至2022年2月11日，40%的下载仍然是易受攻击的版本。 有远见的软件供应商正开始将这些列表包含在他们的软件中，因为这是他们的客户希望看到的。当然，软件供应商还可以更进一步，提供有关他们的软件应该如何运行以及不应该如何运行的信息。 不过，无论SBOM是否会成为强制性的举措，企业组织都应该扫描他们的软件以查找已知漏洞和其他潜在的安全问题。Log4j漏洞问题的持续蔓延说明许多组织在保护代码方面落后了多远! 本文翻