安全事件运营SOP：软件供应链投毒事件

在开篇《安全事件运营SOP【1】安全事件概述》中，介绍了安全事件的定义、分级、处置原则及处置流程。当发生某类安全事件时，该如何快速处置？以及如何保证不同人员处置的效果都达标？安全事件的种类虽然繁多，但是处理起来并非无据可循。为了解决上述两个问题，同时提升工作效率和降低安全风险。经过大量的运营处置实践，总结出以下常见的处置标准操作程序（SOP）。

本文将从基础概念、运营处置、自动化剧本和防御策略四个维度，对软件供应链投毒事件运营SOP进行阐述。由于作者所处平台及个人视野有限，总结出的SOP虽然经过大量重复的操作、总结及提炼，但仍会存在错误或不足，请读者同行们不吝赐教，这也是分享该系列实践的初衷。

01

—

基础概念

说起软件供应链安全，不禁让人想到：漏洞、投毒、合规、断供…一系列安全和合规的风险。此外，同样高频的词还有：供应链攻击、软件供应链投毒，它们之间有何异同？又有何关联呢？

1.1 供应链攻击

关于供应链攻击的概念，先看下百度百科的定义，其偏向于软件投毒攻击。

结合以往的工作经验和个人理解，不太赞同这个定义。比如在往年的国家级攻防演习中，某视频会议公司OA被攻击 à内网横向至连接客户侧的云端中控服务器 à通过服务下发指令反弹shell控制一大片客户，这是通过漏洞利用导致的供应链攻击。

所以除了针对软件投毒攻击外，还应该加上供应商的产品或服务被攻击导致被打的情况（为了找出区别，特意强调：直接打，没有通过篡改源代码等方式传递恶意程序去攻击目标）。继续搜了下相关资料，感觉这样来定义更为贴切：供应链攻击，指通过第三方软件、供应商或供应链关系，实现对目标企业的攻击。常见招式包括：硬件攻击、软件攻击、固件攻击和人员渗透。

从这个角度上来看，供应链攻击包含了部分软件供应链安全（由于投毒和漏洞导致的攻击），软件供应链安全包含了软件供应链投毒。

1.2 什么是软件供应链投毒

借用上面的概念，软件供应链投毒是指：攻击者将恶意程序注入到受信任的应用或软件系统中，在整个供应链中传播恶意软件。业界Google SLAS（Supply-chain Levels for Software Artifacts）框架从供应商的视角，非常完整的覆盖了以上攻击方式：

为了更好的理解，可以将这些攻击方式提炼为：源代码篡改、依赖包投毒、开发工具污染、攻击CI/CD基础设施和软件更新机制劫持等。

1.3 开源组件投毒有何招式

从甲方安全建设的视角来看，可以把软件投毒分为：内部研发基础设施和人员安全、外部软件和开源组件依赖引入安全。

在本章节将聚焦开源组件的依赖投毒，介绍以下常见的攻击方式：

• Typosquatting：攻击者注册与一些流行和广泛使用的包的名称相似的恶意包，诱导用户下载使用从而发起攻击；
• Ghost Package attack in Mirrors：当软件源中的软件包被包维护者或软件源管理员删除（大部分是恶意包）时，一些下游镜像站未能同步删除镜像站中对应的软件包，因此会产生大量的恶意软件包；
• Dependency Confusion Attack：攻击者通过在软件源发布与受害公司内部软件包同名但版本更高的恶意包，诱使用户下载安装；
• Package Use-After-Free Attack：PyPi、npm软件源允许包维护者删除已发布的软件包，并允许新的包维护者任意重用被删除的软件包标识符，这给了攻击者可乘之机；
• Package Maintainer Account Hijacking Attack：软件包维护者账号的绑定邮箱对应的域名可能已过期，使得攻击者可通过注册域名控制该邮箱，进而通过找回密码等方式取得目标软件包的控制权；
• Package Redirection Hijacking Attack：Github等代码托管平台允许转移项目控制权，并会自动在项目原地址和新地址之间创建跳转，攻击者可通过注册被删除的GitHub账号实现下载劫持;
• Case Sensitivity Confusion Attack：软件源支持软件包名称中的大小写，攻击者可利用镜像站的上述缺陷，在软件源中发布名称相同、大小写不同的恶意包从而发起攻击。

02

—

安全运营SOP

软件供应链投毒愈加在攻防实战中使用，尤其是pypi、npm等官方源维护比较松散也给攻击者带来了可乘之机。在真实的场景中，大多数公司基本是以威胁情报为主，在事后进行投毒的响应。在处置时可以参考以下流程：

2.1 IOC监控

当监测到开源软件包存在后门的情报时，一般也会提供IOC地址。若没有则继续加强关注相关情报源，或下载相关软件包进行分析自行提取。

2.2 IOC拉黑

在互联网边界先通过防火墙等安全设备将IOC禁用，禁止进出向的访问权限，及时阻断恶意外联。

2.3 影响范围排查

通过EDR、NTA等安全设备查询IOC的访问情况，将有访问记录的主机或PC纳入受攻击范围；通过SCA产品或组件库，根据软件及版本信息查询受影响的仓库或项目。

2.4 开展应急响应

对排查出的受影响服务器或终端PC开展应急响应，通过查询日志、流量分析攻击链路、后门检查与清除等。

2.5 推动整改及验证

对受影响的仓库或项目，通知其owner进行整改并跟进修复后的验证。

2.6 SOP流程图

2.1 – 2.5描述的内容，如下图所示：

03

—

IOC告警自动化处置

在上面的事件处置动作中，涉及到多个安全产品（EDR、HIDS、NTA、FW等），纯手工登录进行查询与分析的效率太低。当监测到IOC告警时，可以通过SOAR剧本调用EDR和HIDS对终端和服务器进行IOC外联查询。

3.1 IOC查询剧本

为了精准的识别被攻击的机器，在提取IOC信息后，继续确定访问IOC的进程并计算出hash，根据IOC访问记录+hash值匹配筛选出沦陷机器发送给相关人员处置。

3.2 IOC查询子剧本

收到ioc信息后，提取其中的IP地址并联动EDR和HIDS进行访问记录查询，流程进入两个子剧本中，解析访问过的IP地址并将结果通过邮件发送至安全运营人员进行后续处置。子剧本中的响应sop相同，均为：

• 查询EDR/HIDS日志，在时间范围内，提取访问IOC的进程路径并计算进程hash；
• 根据hash，对访问过IOC的IP进行统计并去重；
• 按照约定格式解析并返回结果给主剧本。

出于业务的连续性和员工感受考虑，未执行断网下线等处置动作。该部分可以在子流程中实现，如在EDR上查询到访问记录后，先通过IM发送通知给相关owner说明情况，再断网下线，最后返回结果给安全运营人员跟进处置。

04

—

软件供应链投毒防御策略

4.1 外购软件安全管控

在本系列文章《安全事件运营SOP：网络攻击》中，已经提到该部分。不过对于即将迎来的国家级攻防实战演习，有必要通知供应商进行一轮漏洞修复反馈和提供应急响应接口人。

4.2 开源组件安全管控

近来软件供应链安全的热度持续水高船涨，但真正在软件投毒方面，做得好的企业非常少。在国内，除了安全公司，已知只有极少数互联网大厂在做研究和输出(比如自建沙箱分析后门)，其他公司大多都是依赖于威胁情报做响应。针对开源组件的管控，从纯攻防的角度来看，需要同时关注投毒和漏洞，此处仅对投毒进行建议：

• 已知威胁检测：抓情报，做碰撞。仅需购买或关注威胁情报，成本低见效有限。
• 未知威胁检测：跑沙箱，看行为。需要基础设施建设和技术能力，投入成本大。

4.3 安全运营检测常态化

预防在发生安全事件之后，能够快速的监测和响应，是必要的安全能力。主要可以从两方面入手：

• 主机行为检测：基于行为监测，万事不离其宗，如果被投毒攻击的话，肯定会有一些异常行为，如应用程序执行系统命令、外发数据等；
• 网络流量检测：基于威胁情报，持续关注安全圈中的投毒情报信息或安全厂商情报，快速升级NTA产品情报库或执行手工检查。

4.4 软件供应链投毒攻击模拟

内部蓝军发起软件供应链投毒模拟，制作NPM、Java后门组件，拉取到不同服务器上运行，验证安全运营的检测能力、响应速度和处置措施。但是为了范围可控，仅蓝军内部成员进行模拟，存在后门的组件并未发布到公网GitHub或内部gitlab上。

目前内部蓝军已经开展过两次，由于后门动作和行为可控制，一般的安全检测措施难以发现。尤其是在安全意识层面，帮助其他安全同学发现了新大陆。

（npm投毒攻击模拟报告截图 - 团队成员番茄）

4.5 更多软件供应链投毒

尤其是业务安全建设能力方面，可以看以前的文章《浅谈企业级供应链投毒应急安全能力建设》。

05

—

参考文献

[1] 供应链攻击

https://blog.csdn.net/why123wh/article/details/129061012

[2] 开源生态中软件包相关的安全问题研究

https://tianwen.qianxin.com/blog/2023/01/06/Investigating-Package-Related-Security-Threats-in-Software-Registries

[3] Keeper关于供应链网络攻击的指南

https://www.keepersecurity.com/zh_CN/threats/supply-chain-attack.html