详解六种最常见的软件供应链攻击( 三 )


同样,发布到Go软件包存储库的软件包以指向其GitHub代码存储库的URL命名,从而使得依赖项混淆攻击即使并非完全不可行,至少难度大大加大 。
4. 被盗的SSL和代码签名证书随着HTTPS网站不断增加,SSL/TLS证书现在无处不在,保护你的在线通信 。因此,SSL 证书私钥泄露可能会危及端到端加密连接为最终用户提供的安全通信和保证 。
2021年1月 , Mimecast披露其客户用于建立与Microsoft 365 Exchange服务连接的证书遭到了破坏,可能影响约10%的Mimecast用户 。虽然Mimecast没有明确证实这是不是SSL证书,但正如一些研究人员所怀疑的那样,情况似乎基本属实 。
虽然受攻击的SSL证书问题严重,但被盗的代码签名证书(即受攻击的私钥)会对软件安全产生更广泛的影响 。获得代码签名私钥的攻击者可能会签名其恶意软件,冒充由信誉良好的公司交付的真实的软件程序或更新 。
虽然Stu.NET仍然是一例典型的复杂攻击——攻击者使用了从两家知名公司窃取的私钥将其恶意代码签名为“受信任代码” , 但这类攻击早在Stuxnet之前就已盛行,甚至在Stuxnet之后多年仍在盛行 。这也解释了前面提到的HashiCorp的GPG私钥在Codecov供应链攻击中泄露这个例子为什么事关重大 。虽然目前还没有迹象表明HashiCorp的泄露密钥被攻击者滥用以签名恶意软件,但除非泄露的密钥被吊销,否则这类事件确实有可能发生 。
5. 攻击开发人员的CI/CD基础设施Sonatype最近观察到一起多管齐下的软件供应链攻击:不仅依赖向用户的GitHub项目引入恶意合并请求 , 还滥用了GitHub的CI/CD自动化基础设施GitHub Actions来挖掘加密货币 。GitHub Actions为开发人员提供了一种为GitHub上托管的代码存储库安排处理自动化CI/CD任务的方法 。
攻击包括攻击者克隆了使用GitHub Actions的合法GitHub代码存储库,对代码存储库中的GitHub Actions 脚本稍加改动,并向项目所有者提交合并请求,以便将此变更合并回到原始代码存储库中 。

详解六种最常见的软件供应链攻击

文章插图
图8. 攻击者(edgarfox1982)为合法项目的所有者提交合并请求,以合并更改后的代码 。
如果项目所有者随意批准更改的合并请求,供应链攻击就会得逞 , 而这甚至不是这里的前提 。恶意合并请求含有对ci.yml的修改,一旦攻击者提交合并请求,GitHub Actions 就会自动运行这些修改 。修改后的代码实际上滥用GitHub的服务器来挖掘加密货币 。
这种攻击可谓是一举两得:它诱使开发人员接受恶意合并请求,如果开发人员未接受,它就滥用现有的自动化CI/CD基础设施从事恶意活动 。
同样,研究人员之所以成功地闯入联合国域名,并访问了10多万条联合国环境规划署员工记录 , 主要是由于他们在这些域名上发现了暴露的Git文件夹和“git凭据”文件夹 。获得Git凭据访问权限的攻击者不仅可以克隆私有Git代码存储库,还可能在上游引入恶意代码以触发供应链攻击,从而酿成极严重的后果 。
对于想要阻止供应链攻击的那些人来说,注意力主要放在向开发人员推荐安全编码实践或在开发环境中使用DevSecOps 自动化工具 。然而,为CI/CD 管道(比如Jenkins服务器)、云原生容器以及补充性的开发者工具和基础设施确保安全现在也变得同样重要 。
6. 使用社会工程学投放恶意代码任何安全专业人员都知道,安全取决于最薄弱的环节 。由于人为因素仍然是最薄弱的环节 , 因此威胁可能来自最意想不到的地方 。最近,linux基金会封杀了明尼苏达大学的研究人员,起因是他们提议故意有缺陷的“补丁” , 而这些“补丁”进而在Linux内核源代码中引入了漏洞 。
虽然该事件被发现,现已得到了处理,但它表明了几个简单的事实:开发人员分散在各处,没有足够的能力来审核提交的每个代码或提议的代码变更,它们可能存在缺陷或完全是恶意的 。更重要的是 , 社会工程学可能来自最不受怀疑的来源——这里来自电子邮件地址使用“.edu”后缀的看似可靠的大学研究人员 。
另一个近期的例子包括任何为GitHub项目贡献代码的合作者在即便发布后都可以更改版本 。项目所有者以为,大多数贡献者真诚地为其项目提交代码 。但只要一个合作者不守规矩 , 就会损害许多人的供应链安全 。
在过去一年中,攻击者创建了误植域名和品牌劫持软件包,一再针对开源开发人员 , 在其上游构建中引入恶意代码,然后传播给众多使用者 。


推荐阅读