提交需求
*
*

*
*
*
立即提交
点击”立即提交”,表明我理解并同意 《美创科技隐私条款》

logo

    产品与服务
    解决方案
    技术支持
    合作发展
    关于美创

    申请试用
      安全实验室 | 冰蝎3.0绕过HIDS原理分析
      发布时间:2020-08-28 阅读次数: 580 次

      最流行的WebShell客户端—冰蝎,于近日发布了最新版3.0。最新版一经发出便火速在安全圈广泛传播,究其原因是因为新版冰蝎较之前版本进行了大量修改,一举绕过了国内大部分HIDS等安全设备的检测。本期美创安全实验室将为大家深度分析新版冰蝎绕过HIDS的原理,同时探寻新环境下的防御方案。 


      HIDS防御老版冰蝎原理


      在弄清为什么新版冰蝎可以绕过HIDS之前,我们首先要了解HIDS防御老版冰蝎的原理。而这就要从冰蝎的工作原理讲起了。 冰蝎采用对称加密算法,工作过程一共分为3步:
      ❖ 密钥传递阶段:在这一阶段中冰蝎向服务端发送请求密钥,其密钥以明文形式存储,如下图;


      ❖ 算法协商阶段:在SSL握手时,冰蝎将一段Payload用不同的算法加密发送给服务器,如果服务器成功解密,那么接下来的通讯就都采用这种算法,如果算法不对那么冰蝎将换另一种加密算法进行尝试,直至成功。加密算法一般为AES128和异或;


      ❖ 正是通讯阶段:冰蝎使用①阶段的密钥和②阶段的加密算法加密通讯Payload,使用POST方法提交给服务端,服务端又以同样的加密方法将应答传回冰蝎。


      从冰蝎的工作原理我们可以发现以下的特征点:


      ❖ 密钥传递时URL参数时只有一个参数,且值一般为2~3位随机纯数字;


      ❖ 特殊的Accept字段:Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2;


      ❖ 可穷举的UserAgent字段,冰蝎内置了十余种UserAgent,每次连接时会随机选择一个;

      ❖ 密钥协商时密钥以明文形式传输。


      而这也恰恰是如今市面上绝大多数HIDS设备的工作原理,采用静态检测与动态监测相结合的方式来鉴别是否有类似WebShell的攻击流量,如下:


      ❖ 通过密钥协商的过程中的一些特征来检测:

      老版冰蝎工具在连接Webshell的时候会存在一个密钥协商的过程,这个过程是纯明文的数据交换,冰蝎存在这样的特征:发起一共两次的密钥协商,通过比较两次密钥协商的返回包中内容的不同部分来获取其中的密钥。      ❖ 通过Shell交互过程中的HTTP请求特征来检测:

      冰蝎在发送HTTP请求时存在一些特征,例如其工具中内置了17个User-Agent头,在用户没有自定义的情况下会随机选择一个发送。但是这些User-Agent头大部分是一些老版本的浏览器或设备。 ❖ 通过WebShell上传时的流量特征来检测:

      在真实的攻击场景下,攻击者通常是通过文件上传、文件写入等方式来写入冰蝎的Webshell,所以流量设备也可以通过检测攻击场景的数据包来发现冰蝎的存在。


      冰蝎3.0绕过HIDS原理


      通过冰蝎3.0与冰蝎2.0的对比我们能很清晰的看出HIDS为什么拦不住冰蝎3.0. 根据官方的说法,本次改动较大,主要体现在以下几个方面上:

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

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

      ❖ UI框架由awt改为javafx,重写了大量逻辑;

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

      从上面的描述我们可以看到,HIDS用来防御冰蝎最重要的一点,也就是密钥协商阶段被取消了。新版本的冰蝎不再有密钥协商过程了,这从原理上就直接绕过了大量的流量监测设备,如下图。但是虽然新版本移除了老版冰蝎的密钥协商逻辑,老版本的WebShell依然可以应用在新版本上。



      可能因为冰蝎自己也知道,以前版本的密钥协商过程全程明文传输,所有的HIDS都紧盯着这点不放,所以这次干脆直接放弃了密钥协商过程,采用一个写死的密钥在WebShell中,并且全程加密,这样总不会有人能检测的到我了吧。 最后我们再拿新老版本的WebShell做一下对比: 老版本的JSP-WebShell:


       新版本的JSP-Webshell:

       

      通过对比两个文件,我们可以看到:


      ❖ 新版WebShell在代码外新增了AAAAA、bbbb两个字符串,但这两个字符串并不影响冰蝎正常使用;

      ❖ 新版本WebShell去除了密钥协商过程,直接将一个字符串写死在WebShell中,作为AES密钥用来解密流量包;

      ❖ 实际执行代码的逻辑并没有修改,均采用defineClass的方式执行Java字节码。

      冰蝎3.0流量特征分析


      虽然新版冰蝎大幅度减少了流量中的特征,但仍然存在一些特征可以被检测:

      1. JSP-WebShell返回包首部和尾部会回显的AAAAA和bbbb字符串

      2. 固定大小的数据包:

      在冰蝎3.0的连接过程中,会存在几个大小固定的数据包,可以作为弱特征进行检测,如下,每次链接总共会发送5个数据包,其中第一个固定为531,接着的两个包大小虽然不固定但也就在1000+和12000+左右,最后的两个数据包固定为1789.


      3. User-Agent字段:

      跟冰蝎2.0类似,冰蝎3.0同样也是内置了16个UserAgent,每次连接前会随机选择一个,该特征属于弱特征,用户可以很轻易的修改,以下列举了冰蝎当中所有16个UserAgent头。

      Mozilla/5.0 (Windows NT 6.1; WOW64)AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.163 Safari/535.1

      Mozilla/5.0(Windows NT 6.1; WOW64;rv:6.0) Gecko/20100101 Firefox/6.0

      Mozilla/5.0(Windows NT 6.1; WOW64)AppleWebKit/534.50 (KHTML, like Gecko) Version/5.1 Safari/534.50

      Opera/9.80 (Windows NT 6.1; U; zh-cn)Presto/2.9.168 Version/11.50

      Mozilla/5.0 (compatible; MSIE 9.0;Windows NT 6.1; Win64; x64; Trident/5.0; .NET CLR 2.0.50727; SLCC2; .NET CLR3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C;Tablet PC 2.0; .NET4.0E)

      Mozilla/4.0 (compatible; MSIE 8.0;Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.3)

      Mozilla/4.0 (compatible; MSIE 8.0;Windows NT 5.1; Trident/4.0; GTB7.0)

      Mozilla/4.0 (compatible; MSIE 7.0;Windows NT 5.1)

      Mozilla/4.0 (compatible; MSIE 6.0;Windows NT 5.1; SV1)

      Mozilla/5.0 (Windows; U; Windows NT 6.1;) AppleWebKit/534.12 (KHTML, like Gecko) Maxthon/3.0 Safari/534.12

      Mozilla/4.0 (compatible; MSIE 7.0;Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C;.NET4.0E)

      Mozilla/4.0 (compatible; MSIE 7.0;Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C;.NET4.0E; SE 2.X MetaSr 1.0)

      Mozilla/5.0 (Windows;U;Windows NT 6.1;en-US) AppleWebKit/534.3(KHTML,like Gecko) Chrome/6.0.472.33 Safari/534.3 SE2.X MetaSr 1.0

      Mozilla/5.0 (compatible; MSIE 9.0;Windows NT 6.1; WOW64;Trident/5.0;SLCC2; .NET CLR 2.0.50727; .NET CLR3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C;.NET4.0E)

      Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.1(KHTML, like Gecko) Chrome/13.0.782.41 Safari/535.1 QQBrowser/6.9.11079.201

      Mozilla/4.0 (compatible; MSIE 7.0;Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C;.NET4.0E) QQBrowser/6.9.11079.201

      Mozilla/5.0 (compatible; MSIE 9.0;Windows NT 6.1; WOW64; Trident/5.0)


      新环境下针对WebShell的检测手段


      对于新版冰蝎来说,由于密钥协商过程的去除,进一步降低了攻击者的特征。对于甲方来说,检测冰蝎最重要的一个动态特征消失了,意味着以后要很大程度上依赖于静态检测,而静态检测则由会带来大量的误报告警。 为了尽可能降低误报带来的影响,未来针对WebShell的检测重点可能需要转移到以下几个方面:

      ❖ 加强流量监测设备对文件上传、文件写入等漏洞的检测;

      ❖ 加强服务端对于兼容冰蝎的WebShell检测;

      ❖ 加强对攻击者拿到WebShell以后的操作进行检测,比如命令执行、反弹shell等。

      免费试用
      服务热线

      马上咨询

      400-811-3777

      回到顶部