文章总结： 软件供应链安全问题在国家级攻防演习中频繁发生，供应商面临开源组件后门投毒、面向安全人员投毒、云端服务被攻击、开发流程投毒及产品自身漏洞五大风险。文章建议供应商应从产品漏洞修复、员工安全意识提升、开发流程安全加固和云端服务防护四方面进行安全建设，以提升整体供应链安全性。
综合评分： 88
文章分类： 供应链安全,漏洞分析,应急响应,安全建设,红队

软件供应商面临的攻防实战风险

原创

aerfa21

我的安全视界观

2023年12月4日 06:06
北京

软件供应链的安全问题越演越烈，在近几年的国家级实战攻防演习中频频发生。即使是在常态化，我们也在不断地帮客户（被供应链攻击的上游客户）应急或在自家环境中发现过此类事件。因此企业在防守难度上，又新增了一块高地。

作为安全产品的供应商，在瞬息万变的攻防态势下，正努力、主动地试图摸索出一条解决之道，提升产品的自身安全性以及到客户侧的整条链路安全性，以更好的服务客户。本系列文章将以供应商视角，介绍实战场景中遇到的软件供应链攻击，分享对应的常态化实践措施，以及在攻防演习前的大型集中战。

本篇章将通过国家级攻防实战演习中、或实际已发生的供应链攻击案例，对软件供应商面临的安全风险进行剖析，最终将梳理出作为供应商（仅从供应商角度）的企业安全建设重点。

—

开源组件后门投毒风险

去年的国家级攻防演习前夕，攻击队在github上发布了安全产品0day漏洞exp，实则为一个Python开源组件的投毒项目。作为一名安全从业人员，在下载工具后肯定都会查看下源码或放到沙箱分析。

记忆犹新的是当时仔细阅读了exp，并没有一眼能识别的C2、也没有看起来比较奇怪的编码，所以就直接去看漏洞原理。但是公司内部的其他安全人员/爱好者，难免会为此好奇的去下载到本地运行，由此可能会带来边界被突破的风险。

其次再来看下这个exp，在执行时会去拉取恶意包fake_useragant (正版包名字为fake_useragent)：

进一步查看fake-useragant-0.1.12源码，在urllib2.py文件中看到loads了一串base64编码的内容：

对编码部分进行解码，得到一个图片地址：

提取图片中的内容，大致可以看到shellcode的样子：

—

面向安全人员投毒风险

今年国家级攻防演习的第6天，有人在github上预告即将放出安全产品的pwn漏洞，并于次日上传了poc。没想到竟是一个jar包，夹杂着很多官方签名的dll文件。

于是我们快速从正反两方面进行验证，正向是直接找一台备用电脑运行poc，同时在测试的安全产品和电脑上抓包，发现仅连了一下该产品但实际没有其他动作，不过用于测试的电脑被反弹了shell；

反向是反编译poc，虽然有的代码被做了混淆，但大概也能看出代码中的有趣提示（poc中有段代码检测操作系统类型，若是windows则打印反弹shell成功，若是mac则打印放你们一马），以及发现了一串cs的shellcode。由此可以判断，这是一起针对安全人员或者安全爱好者的投毒。

更有趣的是，围观群众中不乏高手，直接提交issue说明poc有病毒。作者更是一位大师，义愤填膺的公开质疑提交人，不难看出他是很懂心理学和社工的。

—

产品云端服务被打风险

前年的国家级攻防演习期间，一家“云+端”的某解决方案提供商被用于供应链攻击。其使用的OA系统是国内某知名产品，由于对外开放到公网且存在已知高危漏洞，提前被攻击队拿下，继而摸到云端的中控服务，利用了一个0 day拿下该服务。

又特别巧的是该服务建立了一个VPN隧道与客户侧本地部署的服务打通，攻击者直接利用“云端与本地服务”的通道下发反弹shell的指令，将所有shell反弹到内部一台172的机器，从而实现大面积杀伤。

上面提到的巧合，其实都不是巧合，而是攻击队提前潜伏信息收集的必然结果。把中控服务的代码都拿来审计，内部网络关键服务及服务的架构都摸清楚了，要攻击的客户都弄明白了，所以“平时就是战时”的要求不只是口号。

关于反弹shell部分，是客户侧值班人员发现后反馈给厂商。这更是说明安全运营做得好，就能在一定程度上优先发现供应链攻击。无论是在和防守成绩好的公司交流，还是在日常的安全运营工作中，这一点都多次被印证。

—

产品开发流程投毒风险

2020.12，攻击者将恶意程序注入到Orion的编译过程中，通过“合法”的制品将后门带到客户内网，从而发起对客户的敏感信息窃取。这是非常经典的针对流程投毒的攻击案例，轻松绕过了软件签名验签机制、手法更加隐蔽，为此米国的很多政府机构也都中招了，影响巨大。

关于软件供应链攻击的示意图，看起来可能不是那么清晰。故推荐欧盟网络安全部发布的《软件供应链安全局势》报告中的技战法，把ATT-CK迁移并应用到了软件供应链攻击中，以矩阵的方式来描述。如本次攻击涉及到的技战法：

在solarwinds案例中，最经典和难防的手法就是：攻击上游开发流程，在软件包中塞入后门程序；利用软件包升级的信任关系，实现对下游特定用户的攻击。

—

软件产品安全漏洞风险

安全产品自身的安全性建设起步相对较晚，高危漏洞及组合多，如RCE（后台Injection、硬编码）；演习中的关注度又相当高（演习规则有关，如集权类产品得分高），漏洞影响也被无限放大。故便有了以下的段子：

于是回过头来看，在安全产品供应商的安全建设工作中，最紧急和重要的还是产品的安全漏洞。

—

本章小结

综上所述，作为软件供应商应该以“服务客户、管好自己”为宗旨，以提供的产品或服务为中心进行威胁建模，从漏洞、人员、流程和云端服务四方面进行供应链攻击防范的安全建设：

产品漏洞：高危可以利用的漏洞是第一优先级，如前台未授权RCE及相关组合，但在近几年的对抗过程中，发现攻击者已经逐步放弃web漏洞转而挖掘二进制业务逻辑漏洞，在深度方面甚至超过了防守方，这说明防守方在web漏洞方面治理的成效，以及推动今后发力的细分方向；
公司员工：针对人员的攻击是最难防守的，尤其是安全公司的人员更是难上加难。除了常见的针对HR、客服等进行钓鱼，进阶点的针对开发人员进行社工，在安全公司还有一大批从事安全方向的同学，大家安全意识和水平高低不一，但经常做着客户侧样本传递、出于爱好本机样本调试等诸多高风险的操作，所以要做好终端必定失陷的准备来布防；
开发流程：不是从事研发或配置管理相关的同学，可能不太清楚产品研发流程的长度及分散度，或许大多公司都处于没有公司级统一管控、有统一管控缺少安全意识的水位，但这正中“真正的攻击者”下怀。类似于CDN域前置、云函数、hids用于远控等隐蔽手法，针对开发流程及其基础设施的后渗透相对隐蔽，早就是攻击者的高价值目标之一，更应该被纳入供应商安全建设的重点；
云端服务:产品对互联网的暴露面，通常由于其影响范围广而倍受攻击者的关注。这些服务对外提供的功能可能比较简单，但是也面临水坑攻击，如攻击者投毒一个恶意的样本给接收服务，通过传递到后端进行盲打。所以在进行风险分析时，应该要关注“出向”和“入向”，把服务的相关资产纳入重点清单中进行防御和监测。

长按识别二维码，和我交流

More…

——— 实战演习 ———

——— 安全运营 ———

——— 软件安全 ———****

——— 企业安全 ———****

——— 渗透测试 ———****

——— 安全开发 ———****

——— 个人体验 ———****

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：我的安全视界观 aerfa21《软件供应商面临的攻防实战风险》

Tags: 供应链安全安全培训安全建设安全开发安全运营应急响应渗透测试漏洞分析红队

你可能错过

网安别乱考证！5 本真正能帮你找工作的证书，分清刚需和智商税

数据安全风险评估系统已更新，可试用

【已复现】WordPress 未认证路径遍历漏洞，特定条件下可导致RCE

从 ZCode 到 Trae：AI 编程工具的偷传数据争议何时休