冰蝎，从入门到魔改(4)

在”冰蝎”的默认流量中，会有两次通过GET形式的请求获取密钥的过程，这点比较奇怪。

此处也可作为一个检测点。

我们来看下代码实现：

这一步是将密钥存入rawkey_1变量中。

再次获取的密钥存到rawkey_2变量中，之后rawkey_1和rawkey_2进行了异或操作，通过异或结果来判断，从而结束循环条件，最多尝试获取10次密钥。实话说这块代码没太看出来作用，实际是大部分情况2次就OK了，3次获取密钥的情况都不太多。个人感觉这块是为了校验获取到的密钥是否可用以及控制获取密钥的次数。

修改思路：

删掉多次获取密钥的过程，可以改成一次获取密钥。或者直接把密钥写到webshell里，省去获取密钥的过程。

修改后的效果：

在获取密钥时，密钥返回是直接以16位字符的形式返回到客户端。这时会有比较大的破绽，我们来看下常用的检测规则：

[a-z0-9]{16}$

和

Content-Length: 16

检测内容是：以两个 完整换行加上16位字母小写+数字组合为结尾，再配合Content-Length:16 为规则一起检测。

我们来看下客户端代码对于密钥的匹配规则：

源码只匹配了16位的字母a-f大小写+数字，hah~ 这是因为啥呢？？？

原因在”冰蝎”默认自带的webshell里：

因为webshell生成的密码算法为md5，md5输出结果显示是16进制，所以只有0-9a-f。

修改思路：

GET形式访问时，可以加入一些混淆的返回内容，或者将密钥变型。

修改后的效果：

可以先从视觉效果上隐藏起来：

流量侧：

这里只是简单的加了一些内容作为演示，实战时可以根据情况混淆。

因为”冰蝎”默认自带的webshell中的key在将密钥返回客户端后，会将密钥保存在Session中。而SessionId在第一次客户端请求时作为Cookie发送给了客户端，所以Cookie也是作为我们一个重要检查点。

Cookie中的问题是”path=/”这部分。在访问服务器时，服务端将Cookie以Set-Cookie的response头中的形式返回，其中Path是该Cookie的应用路径。

举个例子：

Cookie1; Path=/

Cookie2; Path=/admin/

当浏览器访问网站 “/” 路径时，只会携带Cookie1。当访问 “/admin/”路径时，会同时携带Cookie1和Cookie2。

在正常浏览器访问下，path是不会作为Cookie本身的一部分发送到服务端的。

来看下客户端代码：