查看原文
其他

找到软件供应链的薄弱链条

Trendmicro 代码卫士 2022-04-06

 聚焦源代码安全,网罗国内外最新资讯!

编译:奇安信代码卫士团队

SolarWinds 软件供应链攻击事件人尽皆知,供应链攻击获得全球更多关注。攻击本身并不新鲜;实际上这类威胁已存在一段时间。和所有攻击一样,软件供应链攻击也演变为更为高级的形式。本文将讨论这类攻击案例,并且挖掘未来的攻击场景。


薄弱链条在哪里?


首先,我们为供应链确立了一种具体的定义。它的通用定义是“让产品触及客户的流程”。身处计算机世界,我们所说的产品是开发出的软件。因此我们首先关注软件开发流程本身。

不管软件开发人员使用了什么方法,他们都应当将复杂项目分解为更简单的任务,以便这些任务可以被定义且分配给具体的开发人员手中,之后开发人员编写代码,供后续测试并将修改推送到源代码管理 (SCM) 软件中。

编写的代码由持续集成和持续交付 (CI/CD) 管道处理,该管道将执行具体任务以便开展构建、测试或最终的项目部署。

在我们所定义的供应链流程中,每个步骤都具有自身的安全风险和影响。例如,某些安全事件可能始于恶意用户或问题追踪软件。这名用户可能是利用安全信息的愤怒的内部人员;也可能是使用漏洞利用的人员。虽然这些场景可能会发生,但由于该链条内还存在其它步骤,因此造成的影响可能较低。供应链的其它环节最可能受恶意任务影响。因此,我们不会在这种场景中耗费过多时间,不过认证场景是个例外。

由于整个供应链的强度由其最薄弱的环节确定,因此忽视安全最佳实践(如密码复用或缺乏正确的认证机制)意味着恶意人员能够获得对系统的访问权限,且暴露造成的影响更大。


开发人员和SCM


软件供应链上不可或缺的另一个环节是编写代码的开发人员。将人的因素列为弱点和很可能的安全风险很重要。我们并非提议用机器取代开发人员,而是教育他们了解所面临的风险。

最近已出现威胁人员攻击漏洞安全研究员的案例。从技术角度来讲,值得思考的事实是,这一威胁隐藏在 Visual Studio 项目文件中(预构建事件内部)并且攻陷了受 PowerShell驱动的 payload。这一场景存在两个值得注意的关联。第一个是“同行”之间的信任,第二个(最适用于开发人员)是更广的源代码采用和第三方项目集成之间的信任。我们应当关注它们所继承的源代码和项目。这就要求我们对代码、软件、插件或容器的来源进行验证。我们认为可以通过在线编程平台解决。

开发人员可以访问下一个环节,即 SCM。它涉及凭据,而由于一次访问就需要重复输入凭据的流程让人抓狂,因此被存储起来。凭据存储会带来凭据泄露问题,且所产生的影响要高于以未加密形式存储。

DevOps 社区的一种常见模式是,开发人员将凭据以未加密形式存储(例如基于文本的配置文件或环境变量),包括服务令牌、用户名和邮件地址。


尽管这些安全问题看似太多,但确实像老生常谈的那样,实际上软件供应链的安全取决于最薄弱的一环。因此,至少应当考虑降低风险的预防措施(例如使用密码管理器)。

从本质上来讲,开发人员不应当将硬编码的凭据推送给 SCM;例如,当使用基础设施即代码 (IaC) 时,应当考虑凭据存储问题。


CI/CD 管道


软件供应链的下一个环节是 CI/CD 管道。这是软件供应商之间竞争颇大的环节,比如 Jenkins、GitLab、TeamCity、Azure DevOps 等就是我们耳熟能详的名字。

CI/CD 软件中的管道可分为如下部分:

系统访问

从安全角度讲,访问这类系统必须受到限制且并非任何人均可访问。它应当隐藏在企业网络中,仅供具有某种特定角色的用户访问,即特殊访问权限。单是暴露到互联网就是一种安全风险,因为漏洞可能存在且被威胁行动者利用,此前就曾发生过这类案例。

系统配置

安全风险的另一种来源和相关问题是配置不当问题。某些配置仅适用于某种具体环境。例如,企业要求多名用户访问系统,但每个人的角色是不同的。在这种情况下,应当配置基于角色的安全。然而,这些配置中存在一些陷阱。随着软件变得越来越复杂和配置选项的增多,强烈建议测试常见的软件配置不当问题。

获取源代码

我们可将其分为两种模式:

SCM 被集成到 CI/CD 中,如 Azure DevOps 服务器案例。SCM 运行在不同的环境中;因此访问令牌或凭据必须存储在系统内部。

软件存储源代码凭据的方式很重要,因为一旦暴露可能导致源代码遭恶意修改。然而,值得注意的是,我们发现CI/CD 软件中使用不安全的实践并且发现第三方扩展中存在未加密的凭据存储漏洞(如 Jenkins 插件事件)。

构建环境配置

这里的安全问题和通过的凭据有关。通过未加密凭据和以 build 工件形式存储存在风险。从本质来讲,某些配置前提含有可能在 build 后被遗留的敏感信息。

构建

这是将实际源代码编译到目标二进制形式的一个步骤。我们已经在 SolarWinds 事件CCleaner 事件中见到过该步骤。攻击者在这个阶段实施攻击的逻辑原因有多种。首先,由于它是供应链中的最后步骤之一,这意味着之后不会有太多的验证步骤。第二,所生成的可执行二进制一般是数字签名,这意味着发生在代码签名之后的任何代码修改都缺少有效的数字签名。二进制的哈希无法匹配,而且由于由私钥加密,因此无法在不觉察的情况下生成有效的哈希。这就是为何构建进程成为供应链攻击目标的原因所在。然而,并非所有软件都带有数字签名。

当提到数字签名时,我们必须强调使证书私钥保持机密状态的必要性。私钥暴露意味着攻击者可以随心所欲地对证书进行数字化签名,因此必须将其撤销。


部署或产品交付


CI/CD 链条可包含的最后一个环节是部署。首先,部署流程可在 CI/CD 软件中指定并通过成功的构建或测试进行触发。因此,架构信息在这里和凭据和其它敏感信息一同出现,强调了对它们进行正确管理的必要性。

攻击者最简单的办法是替换整个软件产品。恶意的代码注入也会被使用且适用于某些应用(未数字化签名)。例如,WordPress 网站遭代码注入攻击就是攻击者利用漏洞或弱点插入恶意代码片段。

攻击者也可能使用可执行的二进制代码注入方法,但更和所编译的二进制以及攻击者的技能相关;而且如果该二进制被数字化签名,则攻击易被发现,因此效率不高。简单的二进制替换是更方便的攻击方法。然而,入侵存储二进制的交付服务器(允许用户下载实际软件产品的服务器)并不容易而且要求具有重要资源。相反,攻击者常用钓鱼攻击、欺诈活动或 DNS 欺骗攻击活动滥用已知的软件品牌(甚至是安全厂商)来交付恶意或灰色 payload。


结论


本文概述了和供应链安全相关的基本问题。这类攻击的问题太过复杂,因此无法在一篇文章中说清楚。它是一个亟待解决的问题,因为预计到2021年年末,企业将在云上运行大多数工作负载。也就是说,作为对健康危机的响应,很多组织机构在未完全了解完整的安全影响范围就随意使用了新软件。





推荐阅读
开源组件XStream 修复11个漏洞并公开 PoC
GitHub谈软件供应链安全及其重要性



参考链接

https://www.trendmicro.com/vinfo/us/security/news/vulnerabilities-and-exploits/identifying-weak-parts-of-a-supply-chain?utm_source=trendmicroresearch&utm_medium=smk&utm_campaign=0221_schainWK



题图:Pixabay License


本文由奇安信代码卫士编译,不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。



奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的

产品线。

    觉得不错,就点个 “在看” 或 "” 吧~



您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存