警惕主动外联！云防火墙检测拦截勒索、Muhstik僵尸网络等 Log4j2漏洞利用

主动外联拦截超9800+起，有效遏制蠕虫传播

• 阿里云安全团队分析了 Apache Log4j2 远程代码执行漏洞常见的验证、利用方式及其原理，发现攻击者在试图利用该漏洞发起恶意行为过程中，均存在多次必要的服务器外联通信：
  • 在攻击者发送请求之后，命令执行阶段之前，受害服务器需要向攻击者所控制的带恶意载荷的LDAP/RMI服务器发起至少两次请求（请求Reference、加载class）；
  • 命令执行阶段当中，如果反连、反弹shell、后门植入等，则需要向DNS反连平台、黑客控制的服务器等发起外联。
• 通过主动外联管控，可以有效斩断该漏洞的验证和利用链，有效遏制恶意蠕虫和高级威胁传播。
• 截至目前，阿里云云防火墙已检测并阻断主动外联的Log4j恶意利用9800+起，涉及僵尸网络家族、团伙十余个，包括Tellyouthepass等勒索团伙，Kinsing、Muhstik、Mirai等挖矿和DDOS家族等。

Log4j漏洞原理——为什么要管控主动外联？

• Log4j漏洞的本质是一个JNDI注入漏洞。JNDI是Java的一个目录服务应用程序接口（API），它提供一个目录系统，并将服务名称与对象关联起来，从而使得开发人员在开发过程中可以使用名称来访问对象。
• JNDI支持LDAP、DNS、NIS、RMI、CORBA等多种协议，即使并非都能用于命令执行，但信息可以通过上述几种协议中任何一种被泄露，加之该漏洞相关源码存在递归解析，利用方式非常灵活，payload变化多端且漏洞入口多样化，目前行业中对该漏洞的防护缺乏完整的体系化思路。

漏洞利用灵活 防护掣肘

• 漏洞入口多样化：

  • web服务是Log4j漏洞利用的重要入口，但绝不是唯一入口，只要任意输入片段到达应用程序并通过Log4j2进行处理，就可能触发远程命令执行。如果在防御时只做入方向Web侧防护，很难彻底防御这一攻击；

• Payload变形多：

  • 灵活的利用方式导致流量检测/拦截等正面对抗手段存在较大的被绕过可能性。攻击payload并非一定通过明文方式到达Log4j2组件处理，中间处理阶段可能通过编码、加密等各个阶段，单字段拦截可能造成大量误报；

• 多种协议导致信息泄露：

  • 仅针对LDAP、RMI前缀进行检测和拦截很难防御信息泄露、木马后门等的影响。

• 服务器外联管控 斩断漏洞利用链条

  • 攻击者利用Log4j RCE漏洞进行远程恶意行为的步骤大致如下图所示：
  • 

• 攻击者部署带有恶意载荷的LADP/RMI服务器

• 向使用Log4j2组件的服务器发送带有恶意的JNDI payload的攻击请求

• 受攻击服务器中的使用Log4j2组件的服务调用lookup方法，向恶意LADP/RMI服务器发起请求，并从响应中获取返回的恶意Reference对象

• 服务器解析该恶意Reference对象，并进一步基于Reference中指定的codebase地址，加载并执行恶意class

• 实现命令执行后，攻击者将得以操控受害服务器去进行各种操作，包括但不限于反连验证、外带敏感信息、反弹shell、后门植入等

• 因为该漏洞本质是JNDI注入漏洞，攻击者要执行任意代码，受害主机必须进行至少两次主动外联：第一次是请求Reference对象，第二次是加载恶意class。

• 理论上来说，管控好服务器的主动外联行为，仅放行认识的域名/IP和协议，让它无法向陌生的、攻击者控制的域名/IP发请求，漏洞就无法利用成功了。

• 这是目前来看最难被绕过的防御方式之一。

来源

• https://mp.weixin.qq.com/s/zFPCuXSlQKH2gI_jAQ5IxA