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

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

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

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

01

—

开源组件后门投毒风险

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

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

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

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

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

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

02

—

面向安全人员投毒风险

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

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

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

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

03

—

产品云端服务被打风险

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

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

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

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

04

—

产品开发流程投毒风险

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

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

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

05

—

软件产品安全漏洞风险

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

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

06

—

本章小结

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

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