本篇章将通过国家级攻防实战演习中、或实际已发生的供应链攻击案例,对软件供应商面临的安全风险进行剖析,最终将梳理出作为供应商(仅从供应商角度)的企业安全建设重点。
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。由此可以判断,这是一起针对安全人员或者安全爱好者的投毒。
03
—
前年的国家级攻防演习期间,一家“云+端”的某解决方案提供商被用于供应链攻击。其使用的OA系统是国内某知名产品,由于对外开放到公网且存在已知高危漏洞,提前被攻击队拿下,继而摸到云端的中控服务,利用了一个0 day拿下该服务。
又特别巧的是该服务建立了一个VPN隧道与客户侧本地部署的服务打通,攻击者直接利用“云端与本地服务”的通道下发反弹shell的指令,将所有shell反弹到内部一台172的机器,从而实现大面积杀伤。
关于反弹shell部分,是客户侧值班人员发现后反馈给厂商。这更是说明安全运营做得好,就能在一定程度上优先发现供应链攻击。无论是在和防守成绩好的公司交流,还是在日常的安全运营工作中,这一点都多次被印证。
04
—
2020.12,攻击者将恶意程序注入到Orion的编译过程中,通过“合法”的制品将后门带到客户内网,从而发起对客户的敏感信息窃取。这是非常经典的针对流程投毒的攻击案例,轻松绕过了软件签名验签机制、手法更加隐蔽,为此米国的很多政府机构也都中招了,影响巨大。
在solarwinds案例中,最经典和难防的手法就是:攻击上游开发流程,在软件包中塞入后门程序;利用软件包升级的信任关系,实现对下游特定用户的攻击。
05
—
于是回过头来看,在安全产品供应商的安全建设工作中,最紧急和重要的还是产品的安全漏洞。
06
—
-
产品漏洞:高危可以利用的漏洞是第一优先级,如前台未授权RCE及相关组合,但在近几年的对抗过程中,发现攻击者已经逐步放弃web漏洞转而挖掘二进制业务逻辑漏洞,在深度方面甚至超过了防守方,这说明防守方在web漏洞方面治理的成效,以及推动今后发力的细分方向; -
公司员工:针对人员的攻击是最难防守的,尤其是安全公司的人员更是难上加难。除了常见的针对HR、客服等进行钓鱼,进阶点的针对开发人员进行社工,在安全公司还有一大批从事安全方向的同学,大家安全意识和水平高低不一,但经常做着客户侧样本传递、出于爱好本机样本调试等诸多高风险的操作,所以要做好终端必定失陷的准备来布防; -
开发流程:不是从事研发或配置管理相关的同学,可能不太清楚产品研发流程的长度及分散度,或许大多公司都处于没有公司级统一管控、有统一管控缺少安全意识的水位,但这正中“真正的攻击者”下怀。类似于CDN域前置、云函数、hids用于远控等隐蔽手法,针对开发流程及其基础设施的后渗透相对隐蔽,早就是攻击者的高价值目标之一,更应该被纳入供应商安全建设的重点; -
云端服务:产品对互联网的暴露面,通常由于其影响范围广而倍受攻击者的关注。这些服务对外提供的功能可能比较简单,但是也面临水坑攻击,如攻击者投毒一个恶意的样本给接收服务,通过传递到后端进行盲打。所以在进行风险分析时,应该要关注“出向”和“入向”,把服务的相关资产纳入重点清单中进行防御和监测。
原文始发于微信公众号(我的安全视界观):软件供应商面临的攻防实战风险
- 左青龙
- 微信扫一扫
- 右白虎
- 微信扫一扫
评论