当前位置:首页 > Cms文章 > 正文

流量加密又怎样? 多种姿势检测“冰蝎”

11-16 Cms文章

冰蝎是当下最流行的WebShell客户端,它可以在HTTP明文协议中建立了加密隧道,以躲避安全设备的检测。对于工作于七层的IDS,北斗棋牌可以检测HTTP完整的双向内容,这样检测冰蝎并非难事。而对于传统的工作于四层的IDS,只能检测TCP层的单个“帧”,要想检测冰蝎,似乎难于登天。本文将总结冰蝎(v2.0.1)的通讯特征,并将特征落地为正则表达式,不管是传统的还是新型的IDS/WAF,都可用它检测冰蝎。(注:本文讨论的是webshell上传之后与冰蝎的通讯特征,属于事后检测。而不是正在上传webshell时的流量特征)

第二步,算法协商阶段。SSL握手时会把自己支持的加密算法列表明文发给对方,然而这样会暴漏更多的特征(JA3指纹),冰蝎很显然是考虑到了这一点,它很聪明的将一串payload用不同的算法加密发送给服务器,如果服务器成功解密,那么接下来的通讯便用这种算法。如果算法不对解密失败,那么响应为空,冰蝎继续更换另一种加密算法进行尝试,直到成功为止。加密算法一般为AES128和抑或。

第三步,正式通讯阶段。客户端使用上述密钥加密payload,POST给服务端,服务端解密后执行将结果又以加密方式作为Response Body返回给客户端。

第二步与第三步其实用的是同一个通讯接口,因此特征类似。

我总结了8个冰蝎的静态特征,这些特征可分为两类,一类是强特征,这类特征误报较低,可单独使用。另一类是弱特征,单独使用误报较高,但多个弱特征配合使用可降低误报,达到和强特征一样的效果。推荐弱特征与强特征搭配使用,进一步提升强特征的准确性。

密钥传递时,URI只有一个参数,key-value型参数,只有一个参数。Key是黑客给shell设置的密码,一般为10位以下字母和数字,很少有人设置特殊字符做一句话密码的(少数情况我们不考虑)。而Value一般是2至3位随机纯数字。

Accept是HTTP协议常用的字段,但冰蝎默认Accept字段的值却很特殊,我也没有想明白为什么要设置这么一个奇怪的值。这个特征存在于冰蝎的任何一个通讯阶段。

以下UserAgent列表是从冰蝎的jar包中提取的,可见大多是比较早的浏览器,现在很少有人使用。而且有些国产浏览器甚至精确到了小版本,众所周知,很多国产浏览器是默认自动更新,正常用户很少用过早的版本,因此可以作为强特征使用。

如果发现历史流量中同一个源IP访问某个URL时,命中了以下列表中多个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 BOpera/9.80 (Windows NT6.1; U; zh-cn) Presto/2.9.168 Version/11.5 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64;x64; Trident/5.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR3.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 CLR 3.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/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 CLR 3.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 CLR 3.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 SE 2.XMetaSr Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64;Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.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.20 Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64;Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729;Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E) QQBrowser/6.9.11079 Mozilla/5.0 (compatible; MSIE 9.0; WindowsNT 6.1; WOW64; Trident/5.0) 加密所用密钥是长度为16的随机字符串,小写字母+数字组成。密钥传递阶段,密钥存在于Response Body中,如图。

在加密通讯时,php/jsp shell会提交base64编码后的数据。用如下正则便可以很好的匹配。

注意这条正则最后的数字20,意思是指定的字符出现至少20个才会匹配。而要匹配这段数据长度至少有几K,在TCP层,如此长的数据不会一次性发送,而是拆分成若干“帧”,逐个发送。工作于4层的IDS只能检测“帧”,而“帧”的长度是不确定的(帧的长度是根据网络情况动态调整的),因此这里保守地只写了20。如果你的IDS工作于七层,可以拼接HTTP完整请求的话,这个值可适当增加,以减少误报。

如何用正则去匹配二进制数据呢?这里我使用的方法未必是最好的,仅供大家参考。二进制数据中必然有大量不可见的字符,当然也有不少可见字符,它们出现的位置是随机的。如果第一个位置是可见字符,那么之后的6个字符之内有很大概率出现不可见字符。匹配不可见字符使用零宽负行断言的方式,即不认识的字符即为不可见字符。为了增加准确性,本条策略里扩展了“不可见字符”的定义,这里认为的不可见字符,除了“无法显示的字符”之外,还加入了HTML/JSONP中不常见的字符

如果用户加载图片/视频等多媒体二进制文件的话也是会引发误报,因此我们再写一条策略,规定MIME类型为html。

这两条规则是“且”的关系。意思是如果发现text/html类型的文档是二进制的,那么它就是可疑的。

需要注意的是,并不是所有正则引擎都支持“断言”模型。在使用本策略之前,请确认你使用的正则引擎支持断言,并进行严格测试。

冰蝎通讯默认使用长连接,避免了频繁的握手造成的资源开销。因此默认情况下,请盛世棋牌求头和响应头里都会带有:

在大型互联网企业或者IDC中,出口流量动辄十几个G。即便某条规则的误报率只有百万分之一,由于分母巨大,出现的告警量也是相当可观的。为了进一步提高准确性,在“静态特征”生成的告警之上做“动态行为检测”。这一节不再是正则表达式能做到的,而是要靠开发人员编写脚本来实现逻辑上的检测。

如果同一个url或者源IP在数秒内内同时命中了这两种规则,那么可以非常肯定的确认是冰蝎了。注意,此处是同一个URL或者源IP,而不是同一个TCP会话,密钥传递和加密通讯未必是同一个TCP会话(源端口会变化)。

依照上面的方法虽然能够确定是冰蝎,但是不知道黑客在服务器上干了什么。因此要想进一步的调查取证,必须解密冰蝎。首先依据“密钥传递规则”匹配出的告警,提取密钥。再依据“加密通讯规则“提取出的加密后的内容进行解密。但是这里对IDS有一个较高要求,就是要提取全量的HTTP请求和响应,大概几K到几百K,中间不允许有截断,因为加密算法的”雪崩效应“,密文即便缺少一个字节也无法解密。

User-Agent:Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2;.NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC6.0; InfoPath.3; .NET4.0C; .NET4.0E)

以上总结的检测规则和方法,部分已经投入使用,并且表现良好。本文的不足之处,还望各位老师斧正。

版权保护: 转载请保留链接: http://lefkosaemlak.com/cms/60.html