2021 年，我们发布了一个识别供应链安全薄弱环节的条目。面对记录在案的攻击激增，该条目概述了恶意行为者如何发现漏洞以进行滥用并利用以获得可能的收益和破坏。
在这篇文章中，我们专注于供应链的一个特定部分：开发人员本身。要找到适合开发人员的攻击模型，我们必须首先了解谁被认为是开发人员（因此也是目标）、他们的工作流程和他们的日常工具。我们还将重点放在开发人员及其各自的工具如何被滥用以危害供应链，以及了解这些威胁场景如何让开发人员和组织决定做出哪些权衡来保护他们的项目和他们自己。
谁是“开发商”？
我们可以使用字典定义，说明开发人员是开发计算机软件的人。在我们的理解中，一个写代码的人。这包括流行的编程或脚本语言，如 Java、JavaScript、TypeScript、Go、Python、C/C++ 和许多其他语言，包括基础设施或容器部署定义，如 Dockerfile、Kubernetes、Terraform HCL 等。仅从该描述来看，该定义涵盖了 IT 行业的各个部分，包括每个编写代码的人和安全研究人员，等等。
尽管工作流程本身可能因开发人员和公司而异，但很可能属于以下类别之一，具体取决于开发人员如何使用集成开发人员环境 (IDE)：
•本地 IDE：开发者在自己的机器上本地安装了 IDE。在这种情况下，开发者可以
–将代码拉取或推送到远程存储库，并在本地执行构建和调试，或者
–提交对远程存储库的更改，触发持续集成/持续交付 (CI/CD) 事件，并导致质量保证 (QA) 评估甚至部署到生产环境中。
•云 IDE：开发人员使用云服务托管的 IDE，例如 AWS Cloud9、Visual Studio Online、GitHub Codespaces 和当今可用的许多其他平台。在这种情况下，开发者机器就像网关一样工作，通常通过浏览器连接到 IDE，主要代码执行在云服务提供商内部的云 IDE 远程主机中执行。
由于开发人员定义涵盖多个职业，因此某些工作流程可能会从列表中排除某些项目。例如，研究目的的概念验证更有可能不会建立整个 CI/CD 管道。但是，大多数工作流将包括使用 IDE 进行开发。在这篇文章中，我们重点关注本地 IDE，因为我们在之前关于在线编码平台安全风险的文章中也讨论了特定平台。
本地 IDE 的用例
使用本地 IDE 时，其中一个用例是开发人员将代码拉到本地计算机。该代码被进一步编译成二进制格式以供执行。对以前贡献者编写的代码有一种隐含的信任，因为大多数开发人员认为代码库可能不会“脏”，因为它按预期工作。这种信任不仅体现在源代码本身，还体现在构建脚本、库、依赖项和其他包含的项目文件中。这将我们带到第一个威胁场景：将恶意操作注入项目文件或构建脚本。
作为开发人员，我们是否在执行之前拉取远程代码后阅读构建脚本？
我们通过在适用时向构建脚本或项目文件中注入恶意构建命令来测试各种流行的 IDE 和编程语言。这些是我们测试的 IDE 版本的结果：
•日蚀 2022-09
•阿帕奇 NetBeans 16
•PyCharm 2022.2.4
•IntelliJ IDEA 2022.03
•视觉工作室 2022
•视觉工作室代码1.73.1
当我们考虑通用威胁模型时，我们还必须包括每个非受控输入。这包括源代码、它的文件，以及它的构建前和构建后脚本和 IDE 扩展（如果适用）。我们之前在 2020 年的一篇文章中写过关于可能的恶意 IDE 扩展的危险。
图 1. IDE 威胁模型
我们为每个 IDE 定义了以下场景来验证我们的威胁模型：
•开发人员在线从不受信任的存储库中提取代码
•开发人员在 IDE 中打开一个项目
•开发人员尝试编译或构建项目
使用 Visual Studio Code
从 Visual Studio Code 1.57 版（2021 年 5 月发布）开始，代码编辑器引入了Workspace Trust的概念。此功能通过防止从不受信任的文件和存储库执行代码，帮助开发人员安全地浏览和编辑代码，而不管来源或作者。这可能是由于增加当时的第三方扩展漏洞数量，如果被滥用，可能会在打开不受信任的文件时允许远程代码执行 (RCE)。这个概念很简单：它不允许任何（构建/调试）任务或某些扩展功能运行，除非工作区是可信的。这将责任转移给开发人员，并提示他们信任或不信任下载的代码。
这里要强调 的是不要盲目相信每一个工作空间。
图 2. Visual Studio Code 工作区信任对话框
开发人员应该寻找什么并将其视为不应信任代码的可疑迹象？在其他情况下，应该在开发人员中引起危险信号的迹象包括：
•下载次数减少
•在论坛上共享的项目
•灰色地带
•通常未经证实的来源，和
•不知名的人
在执行 IDE 任务之前，应该验证.vscode/tasks.json文件，尤其是从未知来源下载时，通过审核项目目录中的文件是否存在可疑或恶意命令。
图 3. 恶意构建任务示例
恶意命令可以隐藏在tasks.json文件下并伪装成构建命令。当开发人员尝试构建上述先前盲目信任的项目时，开发人员机器将执行远程代码，这可能是恶意的。攻击者还可以通过在常规构建命令之间隐藏恶意命令来使有效载荷更加隐蔽。这将减少对开发人员的怀疑。
在我们的模拟中，我们通过 Pastebin 将脚本放在远程服务器上。这是一些威胁行为者滥用的一种方法，可将其恶意负载传送到受感染的机器中。这种技术对网络犯罪分子的好处是可以远程更改有效负载。例如，在成功感染后，可以将有效载荷更改为无害的东西。
使用Visual Studio
Visual Studio 是 Microsoft 用于 .NET 和 C++ 开发的专有 IDE，它没有 Workspace Trust 功能。因此，开发人员在加载不受信任的项目文件和执行构建时应格外小心。恶意的构建前或构建后任务可能会被注入到文件中，导致从构建开始就执行不需要的操作。
图 4. Visual Studio 项目文件预构建任务命令示例
图 5. 嵌入预构建 PowerShell 执行的概念验证示例
使用其他 IDE
在 Eclipse IDE 的情况下，构建命令的注入仍然是可能的。因此，文件不同。首先，必须在.project文件中指定ExternalToolBuilder的构建命令，引用.externalToolBuilders文件夹中定义实际执行命令的另一个文件。通过将多个构建命令链接在一起，我们可以实现与 Visual Studio Code 相同的多命令执行。
图 6. 链接构建执行规范的 .project 文件部分示例
图 7. 构建事件外部命令规范
由于使用外部构建工具的项目文件注入适用于基本 IDE 的范围，因此它仅适用于将实际代码编译为二进制文件的语言。这包括 Java 和 C/C++，但不包括 PHP 等语言，因为不执行构建。
NetBeans IDE 主要用于 Java 开发，但它也通过第三方扩展支持 PHP、HTML5、JavaScript 或 C/C++ 开发。Java 开发项目可以利用 Maven、Gradle 或 Ant 作为它们的依赖管理和构建自动化工具。因此，项目和构建定义可能不同。但是，所有这些工具都支持将第三方流程作为构建前或构建后的操作来执行。在这种情况下，攻击者可以注入恶意代码，并希望开发人员不会注意到并不情愿地执行。
对于 Ant，注入可以在nbproject/build-impl.xml文件中完成，方法是将以下代码片段添加到合适的目标标记之一：
图 8. Ant 注入点示例和触发构建时的命令执行
当开发人员使用 Maven 作为构建工具时，可以通过更改项目文件夹中的pom.xml来实现相同的目标。这一次，org.codehaus.mojo插件被用在构建标签中。使用的语法类似于 Ant 使用的语法。
图 9. Maven 第三方执行示例
对于 Gradle，Groovy语言脚本用于位于app/build.gradle文件内的构建定义，并且在所选任务内的字符串上调用execute() 函数将触发代码执行。
图 10. Gradle 第三方执行示例
尽管“打开项目”对话框有一个“信任项目构建脚本”选项，但其功能仅对 Gradle 项目有效。未选中时，它会阻止启动 Gradle 脚本，因此在加载项目时可以执行代码作为CVE-2020-11986的修复。尽管如此，当用户决定手动执行构建时，不会显示更多对话框并且构建被认为是可信的。
图 11. NetBeans 中的 Trust Project Build Script 复选框
IntelliJ IDEA 是另一个用于 Java、Kotlin、Groovy 和其他基于 Java 虚拟机 (JVM) 的语言开发的 IDE。它还支持 Ant 构建脚本。加载包含 Ant 构建脚本的项目会触发一个对话框，警告它可能会执行潜在的恶意代码，如果它不是来自受信任的源，则建议使用安全模式。当开发人员尝试在安全模式下执行构建时，IDE 会警告用户该操作只能在受信任模式下完成。
图 12. IntelliJ IDEA 显示潜在恶意构建脚本的警告
图 13. IntelliJ IDEA 构建安全模式构建警告
PyCharm 是用于 Python 开发的 IDE。Python 脚本通常不会在执行前编译。但是，开发人员仍然可以指定自定义运行/调试配置，允许在实际脚本执行之前执行第三方二进制文件。这可能用于脚本数据输入准备。
图 14. 运行执行前的外部工具
该操作在项目内部被引用。然而，实际的可执行规范存储在不同的地方，更具体地说是在~/.config/JetBrains/PyCharmXXXX/tools/External Tools.xml。正如我们所见，该文件存储在用户主目录中，保护它免受我们的威胁模型场景的影响，因为它需要修改本地文件系统。
图 15. 运行前任务参考
图 16. 运行前任务定义
结论
我们使用执行恶意构建脚本的威胁场景评估了所有已识别的 IDE。我们证明可以将恶意命令注入这些构建脚本。如上所述，一些 IDE 会明确警告开发人员恶意操作的可能性，除非项目配置将它们标记为明确可信，否则将不允许它执行任务。另一方面，一些 IDE 假设当开发人员打开一个项目或将其复制到他的工作区时，它会自动被信任并且不需要任何进一步的操作。
无论我们使用什么 IDE，总是需要在安全性和可用性之间进行权衡。开发人员不应盲目相信互联网上的每个开源项目。在执行任何构建操作之前，开发人员至少应了解他们可能成为攻击目标的可能性并审查构建脚本。
我们还想强调，所描述的威胁场景不仅限于本地 IDE，而且安全重要性在于所使用的工作流和工作区信任本身——无论开发人员执行实际构建/编译的情况如何在支持在线 IDE 的容器或 VM 中。一旦工作区被标记为受信任并且构建脚本被修改，它可能会在环境中触发不需要的代码执行和 IDE 可用的访问权限。为了使用所描述的威胁场景降低供应链受损的风险，开发人员可以牢记以下一些最佳实践：
•使用安全配置的 CI/CD 平台，并在具有适当的基于角色的访问控制 (RBAC) 的外部设备或服务上执行构建，只有授权人员才能更改构建脚本。
•在集成到项目之前检查外部源代码和构建脚本。
•避免在审计之前盲目地使用开箱即用的解决方案，尤其是当它们没有在社区内广泛使用或来自未经验证的来源时。
•定期跟踪更改并进行审查。
翻译自网络
原文始发于微信公众号（闲聊知识铺）：攻击供应链：开发商
