简介
hw前夜,冰蝎发布3.0版本,主要做了一下改动
- 取消动态密钥获取,目前很多waf等设备都做了冰蝎2.0的流量特征分析。所以3.0取消了动态密钥获取
- 界面由swt改为javafx,这个没啥说,界面美观大方
下面主要分析一下冰蝎3.0变化
密钥生成
根据readme,aes密钥变为md5("pass")[0:16]
。全程不再交互密钥生成
shell.jsp 中代码如下
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"));
客户端的代码如下
我们可以看出,新增了无动态密钥交互。只有在无动态密钥交互失败后,才会进入常规的密钥交互阶段。
密钥生成可以看出,使用密码的md5结果的前16位
特征分析
下面我们随便截取一个冰蝎3.0请求包
虽然没有特征可言,但是还是可以找到些许强特征
1. content-type
在冰蝎3.0 的服务端,是通过如下代码读取post请求
request.getReader().readLine()
代码的意思是,直接读取post请求中body的内容。所以请求的http中,content-type一定为application/octet-stream
。否则就会出现非预期http编码的情况。
下面我们查看一下冰蝎3.0的客户端中关于发包的代码
可以看出,该请求头是冰蝎3.0中写死的部分,除非反编译,不然很难修改
下面我们来看一下application/octet-stream
的解释
- 只能提交二进制,而且只能提交一个二进制,如果提交文件的话,只能提交一个文件,后台接收参数只能有一个,而且只能是流(或者字节数组)
- 属于HTTP规范中Content-Type的一种
- 很少使用
根据上面的结论,Content-Type: application/octet-stream
属于强特征
2. user-Agent
该特征属于弱特征。普通用户很容易就可以修改。但是我们也分析一下。
冰蝎3.0 每次请求都会随机选择一个user-Agent。但是如果用户默认不提供ua头,则从系统中随机选择一个ua头。我们来看一下冰蝎3.0默认的ua头都有什么
冰蝎3.0内置的默认16个userAgent都比较老,属于N年前的浏览器产品。现实生活中很少有人使用。所以这个也可以作为waf规则特征。附内置的16个ua
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 CLR 3.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 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/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 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.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 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.201
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.201
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
3. Accept&Cache-Control
这几个http 请求头,属于java默认的设置。下面我们来分析一下代码
冰蝎3.0 通过sun.net.www.protocol.http.HttpURLConnection
实现与服务器的交互。下面我们来分析一下sun.net.www.protocol.http.HttpURLConnection
中关于请求的部分
sun.net.www.protocol.http.HttpURLConnection#writeRequests
可以看出,如果请求没有设置accept,Cache-Control,Pragma,User-Agent。则会设置默认为
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Cache-Control: no-cache
Pragma: no-cache
User-Agent: java/1.8
当然,在冰蝎3.0中,默认只会设置ua请求头,而其他三种一般不会设置。而且正常用户访问,也不会设置的如此简单。尤其是accept头
4. 请求中content-length
冰蝎3.0虽然对请求的内容加密,但是被加密的内容中,并没有随机填充的部分。下面我们以无密钥交互为例子,分析一下冰蝎的流程
在冰蝎中,任何请求,最终都会调用Utils.getData
函数,对请求的参数加密。对于上传文件,命令执行来讲,加密的参数不定长。但是对于密钥交互,获取基本信息来讲,payload都为定长,且无随机padding。
缺点:这个不一定准,需要自行判断
结论
属于冰蝎3.0的强特征
- content-type
- Accept&Cache-Control
- 内置16个ua头
- content-length 请求长度
蓝队可以根据业务方的需要,自行判断需要封禁什么请求,以求误报与漏报之间的平衡