qq3250845

一、什么是供应链攻击
供应链攻击是一种面向软件开发人员和供应商的新兴威胁。目标是通过感染合法应用分发恶意软件来访问源代码、构建过程或更新机制[1]。软件供应链可划分为开发、交付、运行三个大的环节，每个环节都可能会引入供应链安全风险从而遭受攻击，上游环节的安全问题会传递到下游环节并被放大。值得注意的是在供应链攻击中受到攻击的是上游厂商，受到威胁的则是上下游厂商。上游的代码风险问题，其实就是下游厂商需要注意的供应链问题。上游管理好软件开发过程中的风险有助于减少下游厂商面临的供应链攻击。代码风险平台能够解决的就是软件开发过程中发生的供应链攻击。

在Imperva 的博客中提及了五种典型的攻击方法[2]：

1. 利用供应商的产品进行注入（典型的如SolarWinds事件）

2. 利用第三方应用程序（如邮件/浏览器漏洞）

3. 利用开放源代码库中包含的漏洞

4. 依赖关系混淆

5. 恶意接管（担任社区项目维护者，注入恶意代码）

在以上五种攻击方法中，依赖关系混淆可以通过正确配置制品库进行阻止。利用第三方应用程序和利用开放源代码库中包含的漏洞，可以通过及时升级或者利用安全公司提供的补丁进行缓解，但是针对供应商产品注入和恶意接管方面并没有比较有效的通用方案。

Apiiro针对供应商产品注入和恶意接管提出了使用识别编译过程注入和利用算法识别恶意接管的方式来应对这两种攻击方式。针对软件开发过程中产生的漏洞则给出基于变更的风险视图来实现安全左移，在变更发生时评判变更中包含的风险等解决方案。

二、Apiiro的解决方案
Apiiro是业内首先提出代码风险平台的企业。Apiiro代码风险平台可以帮助客户在SDLC过程的早期进行有效的风险管理，加强应用程序的治理与合规性检测，同时防止针对CI/CD的高级攻击。Apiiro会分析整个开发过程中的数据，以帮助组织识别，确定优先顺序并补救有风险的重大变更。Apiiro通过提供跨应用程序、基础架构、开发人员的知识和业务影响的风险可见性，帮助组织构建应用程序风险计划[3]。


安全左移：识别变更中蕴含的风险并适时介入安全审查
针对软件设计和开发过程中的风险管理，Apiiro 使用基于时间点和风险维度的风险视图，根据提交的变化，开发人员的知识和行为，业务影响等提示用户变更中蕴含的风险[4]。

1. 建立所有产品的业务影响、是否为网络应用、代码组件、安全控制、数据模型、许可证、依赖项以及开发人员的知识、位置和行为的清单。例如：哪些产品和哪些组件（API、UI、后端、移动等）正在使用特定的库+谁对其进行了升级+何时+哪个开发人员更改了代码+他/她的知识+它在哪里部署等。

2. 确定所有代码组件的所有重大更改的历史审核跟踪。例如：在特定库中跨所有危险物料更改的历史记录进行实时过滤，以了解时间点和变更背景。

3. 仅针对关键代码组件（例如，关键业务逻辑汇款）中的风险重大变化自动触发上下文安全流程（例如，安全设计审查、安全代码审查、SAST和DAST）。

4. 针对每个提交、PR或发布，在图中的所有节点上创建统一的风险视图。这将帮助您做出明智的基于风险的决策。

5. 仅基于统一风险视图批准有风险的重大变更。

基于这种方式可以对项目种蕴含的风险有一个全局的风险视图，基于这个风险视图可以看到某个开发人员针对某个代码库的变更造成了哪些影响。并基于变更风险来批准有风险的重大变更。

同时仅针对关键代码组件中的风险重大变化自动触发上下文安全流程，有助于将安全审查力量集中在重要组件中，加快DevSecOps速度。

供应链安全：利用算法识别恶意接管
针对开发人员账户被窃取或者开源软件被恶意接管，Apiiro 使用UEBA和异常检测技术，根据用户的提交内容、提交时间和频率等来检测用户的提交是否偏离了正常用户的行为。并自动对可疑提交的PR进行评论。算法触发异常警报的一些指标包括[3]：

1. 提交与提交强度有关的近期活动不符

2. 提交时间与用户的预期活动日期和时间有出入

3. 贡献者偏离了他的同行在存储库中常见的模式

4. 提交信息与分析代码之间的重大差异

5. 添加的代码与该存储库的模型预测的代码明显不同

Apiiro基于以上指标，利用机器学习和人工智能算法训练出用于检测恶意行为的模型。该检测模型基于行为和字符内容，与语言和平台无关。这是一种可用于开源软件监测或者内部开发检测的通用方式，可以用于公司内部监测开源软件的恶意托管，也可用于监测内部开发账户是否被窃取并用于提交恶意代码。

供应链安全：识别编译过程注入

SolarWinds供应链攻击示意图
针对SolarWinds事件，Apiiro 给出了一种可以检测源码和二进制文件是否匹配的方法。利用来自二进制文件的标实体关系图和从源代码中学到的相同数据图执行比较算法。当存在多个不匹配的风险因素时，表明该代码已被篡改。

以.NET二进制文件为例。Apiiro平台将对可执行文件进行解析并执行以下操作[3]：

· 了解所有可能的逻辑流程和符号

· 清除所有自动生成的编译器逻辑

· 调整运行时版本之间的预期差异等

当检测到编译的结果分析到的数据图和源码中分析到的数据图存在较多不一致的时候，就可以认为在编译过程中发生了编译过程的恶意代码注入。

这种解决方案针对的是在编译时注入代码的攻击方式。在恶意代码的注入前后对文件进行分析，并检测出是否包含编译时注入的风险。对于上游厂商来说，保证自己编译过程不被注入这是一种有效的方案。

对于下游受影响的厂商来说，由于编译过程注入是发生在上游厂商，在不能获得源码的情况下如果要检查上游产品中是否包含恶意代码，只能通过二进制检查来分析其中包含的风险，虽然二进制分析针对恶意代码的漏报误报显然不如从源码和二进制同时进行分析，但二进制分析的覆盖面更广。如果是在能获取到源码的情况下，使用SCA+SAST 配合上编译过程注入的检测方案，是能够确认上游提供的产品的安全性的。所以这种方式需要上下游厂商的合作才能确认自己的上游不被这种攻击方式影响。

代码风险平台如何应对供应链攻击
对于供应链安全来说，一方面是保证上游产品没有安全问题，另一方面是要保证自身产品全周期的安全问题。这就需要代码风险平台有对上游产品的检测和持续监测能力,并对自身产品Devsecops流程进行风险管控。

对于上游产品来说我们可以提供安全监测服务，针对可以获取代码或二进制文件的情况下提供安全扫描能力。同时对于恶意接管和软件/组件的公开漏洞提供安全监测服务。

对于自身产品开发周期的安全问题则需要对Devsecops 流程进行风险控制。需要我们协助软件开发组织排查Devsecops过程中每一个可能受到攻击的点，并对其进行持续的功能验证和配置核查。可以利用安全方面的知识协助软件开发组织排查Devsecops整个流程中潜藏的风险并提供一套整体上的Devsecops解决方案。这包含代码安全（SCA，SAST等）、代码库安全（恶意接管）、主机安全（SolarWinds事件是由于编译机被控制导致的）、制品库安全等。这需要代码风险平台结合Devsecops安全能力、传统安全能力结合自身安全能力来覆盖这些容易受到攻击的点。

最重要的是代码风险平台需要通过对项目中建立的全局风险视图的监测，来排查开发过程中包含的风险，实现安全左移。这需要代码风险平台将安全能力集中在一个平台且具有对数据进行综合分析的能力，对大量安全工具的不同种类的告警信息和开发过程中产生的数据进行分析，给出基于风险的统一视图。从而有效地帮助软件开发组织控制开发过程中的风险，应对供应链攻击。

绿盟科技供应链安全实践
自Gartner 2017年第一次提到Devsecops概念到今年，Devsecops一直在探索落地实践之路。2021年供应链安全类产品第一次获得RSA的沙盒冠军，说明Devsecops已经从概念转化为实践，找到了发展的方向。绿盟科技经过多年积累，即将推出绿盟代码安全审计系统（ SDA ），贯彻Devsecops理念思路，采用更加落地的方式来实现供应链安全中的一环。通过静态分析、成分组成分析和固件分析，在开发、测试、移交和发布阶段，全方位保证应用交付的安全。


独创性的固件分析模块，在没有源码的情况下，依然能够基于系统级别的扫描，完成漏洞与组件的分析。在成分组成分析方面除了物料清单梳理外，还能根据项目的安全生命周期进行跟踪；对于新发现的漏洞，能够快速排查受影响的项目。无论是上游供应商出现漏洞，还是影响了下游使用者，都能及时评估风险范围。

国内企业目前已逐步往Devops的开发模式进行迁移，CI/CD流程越来越完善。为了适应敏捷式的开发模式，绿盟代码安全审计系统（ SDA ）提供灵活的接口，采用非入侵的方式，轻松接入到企业已有的Pipeline中，不增加原有安全管理流程。

类似Apiiro的上下文风险分析，绿盟代码安全审计系统（ SDA ）采用针对全生命周期统一的缺陷风险评估标准，结合历史提交记录、漏洞修复方式和人工审核结果，自动评估出漏洞修复优先级，以风险最小化为前提，加速应用版本的发布。

qq3250845

..........

qq3250845

.............

qq3250845

...............

qq3250845

............

qq3250845

............

qq3250845

一、OPSEC之基础设施
OPSEC（Operational Security，即操作安全），类似“红蓝对抗”，也源自现代军事对抗实践，指审视己方操作中可能被敌方利用的关键信息，评估风险，并采取有效应对措施的过程。简单的说，蓝军作战期间同样须要有自己的安全生产标准和规范，以规避行动暴露、被阻断以及被溯源等安全风险。

作战基础设施是为了支撑保障完成攻击全生命周期而存在的体系化辅助工具，可以理解为攻击者的阵地战壕，需要有绵亘正面和一定纵深的特点，在当作防线掩体的同时又可以用来灵活调整战术和作战状态。所以搭建一个好的基础设施也是完善OPSEC的关键一步。C2作为基础设施中的重型作战通道，一般会出于两个基础目的使用前置技术对其进行保护，首先前置会保障C2不被定位到真实的网络地址，其次防守方在进行攻击源封堵时，前置地址可以被用来当作C2的“替死鬼”，因为比较轻量可以快速进行攻击出口的切换以降低攻击者重新部署C2或切换C2网络地址的成本。当然一个更好的C2前置技术还可能具备绵亘、伪装、监控等特点。那如何搭建一个高质量的C2攻击前置的基础设施，是我们接下来要重点探讨的内容。

二、CDN or FaaS
域前置（Domain Fronting）技术在诞生之日起就被大量的用于攻击基础设施当中，因为其滥用CDN服务加速了原本不存在的可信根域名的子域名，在保障真实C2地址不被定位的同时，可信根域名又增加流量来源的可信度，并且数量众多的CDN节点任意一个都可作为前置来转发攻击流量。而在防守方视角遇到这种情况首先会发现恶意通信地址不是固定的，被控机器会随机与一些CDN节点完成通信，所以封禁少量CDN节点地址是解决不了问题的，大面积封禁CDN节点又可能会影响正常业务，从而陷入两难境地。国际上的一些知名CDN服务商早已对域前置进行了限制，而在国内因为近两三年的红蓝对抗中蓝军也大量使用该技术，一些规模较大的CDN服务商也已做出逻辑校验来限制服务被滥用的情况。

另外，常规的CDN业务也可用于攻击前置，而与Domain Fronting相比唯一的区别是所使用域名是攻击者自己注册的或者控制的，而不是被滥用加速实则不存在的可信子域名。总的来说两种方法都能很好的满足C2保护的前置需求，如果非说有哪些不足的话，可能包含：

所使用的域名是最显性的特征可被防守方用于标记拦截攻击流量
在防守方进行探测溯源攻击基础设施的时候，无法很好的进行监测、伪装和反制
域前置被CDN厂商进行限制
……
相对CDN前置的技术，近两三年随着各大云厂商推广各种形式的Serverless服务，攻击者又转而对其中一种称之为云函数（FaaS，Function as a Service）或函数计算的服务进行滥用，比如微软云Azure Functions、亚马逊云AWS Lambda，国内阿里云函数计算FC、腾讯云云函数等。云函数是一段运行在云端的、轻量的、无关联的、并且可重用的代码。无需管理服务器，只需编写和上传代码，即可获得对应的数据结果。使用云函数可以使企业和开发者不需要担心服务器或底层运维设施，可以更专注代码和业务本身，也可以使代码进一步解耦，增加其重用性。简单来说就是云厂商提供了一个供代码运行的容器方便开发者便捷部署并运行应用程序，而攻击者则利用其编写了代码对攻击流量进行了转发，完成攻击前置的目的。滥用云函数作为攻击前置的方法早在2018年就被提出，2020年底又在国内火了一把，主要原因有两点，一是云函数作为一种Serverless的服务，会有一个API网关触发器配合进行使用，该网关提供了一个厂商备案过的特定域名，具备高可信度的同时又具备IP不唯一的特点；二是云厂商在推广Serverless服务时，免费提供了一定的运行空间和请求次数。但同样也因此有一些不足，比如：

云函数地址及请求响应包header中包含大量特征，可被标记检测的同时也存在被溯源的可能性
云函数的免费请求次数乍一看是降低了成本，但其本身并不具备请求控制的能力，所以成本是不可控的。如果有防守方再遇到直接用云函数进行攻击前置的攻击队，这里建议您可以对准该函数地址进行CC攻击
……
三、CDN and FaaS
基于以上所述的一些问题，我们尝试利用CDN结合函数计算搭建攻击前置，希望能有1+1>>2的效果，基本结构如下。


我们以国内某云厂商之前的版本为例简单阐述搭建步骤以验证效果，过程中间存在一些不完美的地方，读者可自行进行研究完善。

首先创建服务和函数


修改触发器



编写函数代码完成请求响应转发功能



invoke执行测试


或者使用vscode插件进行远程部署


访问返回的服务url即可重定向到我们的C2服务，云函数具备多出口IP，但URL特征极为明显，这里再通过自定义域名加上CDN服务做域前置进行优化。


请求测试，功能正常，但是返回头中含有云函数的一些特定内容，继续优化，可以在阿里云CDN中设置缓存配置过滤返回头无关内容。



删除以下HTTP响应头


对于C2 WEBServer中不存在的资源的访问，中转请求肯定会报404，但阿里云函数自身异常处理有问题，返回会报50x错误，我们针对此情况在CDN配置自定义页面即可，同时可增加一部分伪装性。


C2使用自定义的C2 Profile还可以用CDN的UA控制进行访问控制。


最后效果


四、总结
CDN结合云函数作为攻击前置存在哪些优势呢，我们总结如下：

两次转发保护，多重隐蔽性
存在绕过厂商限制添加域前置的可能性
避免C2请求地址是函数地址，过滤请求header头中带有的云函数特征
对非C2流量及潜在攻击流量进行过滤（例如针对云函数服务的DOS攻击）
在CDN上定义响应状态码跳转进行基础设施保护
特殊路径可通过CDN和其他服务结合的方式进行请求分发跳转，增强基础设施在伪装性、探测监控及溯源反制等方面的能力
随着攻防对抗形势的白热化发展，对抗升级的过程愈发对OPSEC提出了更高的要求，而云的高速发展为业务数字化转型提供便利的同时，也方便了攻击者滥用其能力去完成高隐蔽和持续性的攻击。本文所述部分方法在截止本文发出时已被个别云厂商所修复，此次分享旨在为蓝军技术研究人员拓展思路，而云上其他各类型服务根据场景依旧存在被滥用的可能性，值得攻防研究人员和云厂商跟进关注。

qq3250845

............

qq3250845

UDP反射放大攻击是近几年最火热，被利用最多的DDoS攻击方式之一。UDP数据包是无链接状态的服务，攻击者可以小代价的利用UDP 协议特性攻击目标主机，使其无法响应正确请求，以实现拒绝服务。

那么，我们应该如何应对UDP反射放大攻击？以下几点仅供参考：

1.      指纹学习算法：学习检查UDP报文中的Payload，自动提取攻击指纹特征，基于攻击特征自动进行丢弃或者限速等动作。

2.      流量波动抑制算法：产品通过对正常的业务流量进行学习建模，当某类异常流量出现快速突增的波动时，自动判断哪些是异常从而进行限速/封禁，以避免对正常流量造成影响。

3.      基于IP和端口的限速：通过对源IP、源端口、目标IP、目标端口的多种搭配组合进行限速控制，实现灵活有效的防护策略。

4.      服务白名单：对于已知的UDP反射协议，如DNS服务器的IP地址添加为白名单，除此之外，其他源IP的53端口请求包，全部封禁，使UDP反射放大攻击的影响面降低。

5.      地理位置过滤器：针对业务用户的地理位置特性，在遇到UDP反射攻击时，优先从用户量最少地理位置的源IP进行封禁阻断，直到将异常地理位置的源IP请求全部封禁，使流量降至服务器可处理的范围之内，可有效减轻干扰流量。

qq3250845

............