阿里云安全的log4j分析文章写的很棒

up:: [[ 专题 Special Topic ]]-log4j

  • 警惕主动外联!云防火墙检测拦截勒索、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

Notes mentioning this note