Agent内存马的自动分析与查杀(二)

简介: Agent内存马的自动分析与查杀

解决非法字节码

接下来我遇到了一个比较大的坑,通过sa-jdidump下来的字节码是非法的

在对ApplicationFilterChain类分析的时候,会报如下的错

69ef9c1d7df1167ca2f606bfbceba789_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png


起初我怀疑是自己用了最新版ASM框架:9.2

于是逐渐降级,发现降级到7.0后不再报错,但ClassReader不报错,在分析时候会报错

经过对比,发现是以下的情况

d6af3b37d994d5fd8d85c687f06c33ca_640_wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1.jpg

不报错版本

b61d95d724c99fdc6e18568952f11e0d_640_wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1.jpg

稍微分析了下,发现是ApplicationFilterChain类包含了LAMBDA

不止这个类,不少的类都有可能会包含LAMBDA

4b22f7894c6cd06f0aec5d9188bf0977_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png


发现通过sa-jdi获取的字节码在存在LAMBDA的情况下是非法字节码,无法进行分析

这时候如果还想进行分析,只有两个选择:

  • 自己解析CLASS文件做分析(本末倒置)
  • 改写ASM源码使跳过LAMBDA


根据Java基础知识可以得知:LAMBDAINVOKEDYNAMIC指令相关,于是我改了ASM的代码

(这里不解释为什么这么改了,是经过多次调试确定的)

org/objectweb/asm/ClassReader#274

bootstrapMethodOffsets = null;

org/objectweb/asm/ClassReader#2456

case Opcodes.INVOKEDYNAMIC:
{
   return;
}


改了源码后,就可以正常对非法字节码进行分析了。目前来看没有什么大问题,可以正常分析,但不确定这样的修改是否会存在一些隐患和BUG。总之目前能继续了


分析字节码

分析字节码并不需要太深入做,因为大部分可能出现的内存马都是Runtime.exec或冰蝎反射调ClassLoader.defineClass实现的,针对于这两种情况做分析,足以应对绝大多数情况

以下代码是读取dump的字节码并针对两种情况对所有方法分析

List<Result> results = new ArrayList<>();
int api = Opcodes.ASM9;
int parsingOptions = ClassReader.SKIP_DEBUG | ClassReader.SKIP_FRAMES;
for (String fileName : files) {
   byte[] bytes = Files.readAllBytes(Paths.get(fileName));
   if (bytes.length == 0) {
       continue;
  }
   ClassReader cr;
   ClassVisitor cv;
   try {
       // runtime exec analysis
       cr = new ClassReader(bytes);
       cv = new ShellClassVisitor(api, results);
       cr.accept(cv, parsingOptions);
       // classloader defineClass analysis
       cr = new ClassReader(bytes);
       cv = new DefineClassVisitor(api, results);
       cr.accept(cv, parsingOptions);
  } catch (Exception ignored) {
  }
}
for (Result r : results) {
   logger.info(r.getKey() + " -> " + r.getTypeWord());
}

对于Runtime.exec型的分析最为简单,仅判断已dump的字节码中所有方法中是否存在该方法的调用即可(理论上会存在误报,但黑名单类不可能存在该方法,关键字类本身就是可疑的,所以这样做并无不妥)

@Override
public void visitMethodInsn(int opcode, String owner, String name, String descriptor, boolean isInterface) {
   boolean runtimeCondition = owner.equals("java/lang/Runtime") &&
       name.equals("exec") &&
       descriptor.equals("(Ljava/lang/String;)Ljava/lang/Process;");
   if (runtimeCondition) {
       Result result = new Result();
       result.setKey(this.owner);
       result.setType(Result.RUNTIME_EXEC_TIME);
       results.add(result);
  }
   super.visitMethodInsn(opcode, owner, name, descriptor, isInterface);
}

但这种情况不适用于冰蝎反射调ClassLoader.defineClass

代码不长,但对应的字节码较复杂

Method m = ClassLoader.class.getDeclaredMethod("defineClass",
                                              String.class, ByteBuffer.class, ProtectionDomain.class);
m.invoke(null);

对应字节码

LDC Ljava/lang/ClassLoader;.class // 重点关注
LDC "defineClass" // 重点关注
ICONST_3
ANEWARRAY java/lang/Class
DUP
ICONST_0
LDC Ljava/lang/String;.class
AASTORE
DUP
ICONST_1
LDC Ljava/nio/ByteBuffer;.class
AASTORE
DUP
ICONST_2
LDC Ljava/security/ProtectionDomain;.class
AASTORE
INVOKEVIRTUAL java/lang/Class.getDeclaredMethod (Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method; // 重点关注
ASTORE 1
L1
LINENUMBER 11 L1
ALOAD 1
ACONST_NULL
ICONST_0
ANEWARRAY java/lang/Object
INVOKEVIRTUAL java/lang/reflect/Method.invoke (Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; // 重点关注
POP

这种操作需要多个步骤,并不是简单的一个INVOKE那么简单,不特殊处理的话,由于反射和ClassLoader相关操作都算是比较常见的,有一定的误报可能

于是继续掏出栈帧分析大法,具体不再介绍,之前文章 已有详细解释

根据字节码,在defineClassLjava/lang/ClassLoader;通过LDC指令入栈之前,应该认为这是恶意操作,模拟JVM指令执行后应该在栈顶设置污点

@Override
public void visitLdcInsn(Object value) {
   if (value instanceof String) {
       if (value.equals("defineClass")) {
           super.visitLdcInsn(value);
           this.operandStack.set(0, "LDC_STRING");
           return;
      }
  } else {
       if (value.equals(Type.getType("Ljava/lang/ClassLoader;"))) {
           super.visitLdcInsn(value);
           this.operandStack.set(0, "LDC_CL");
           return;
      }
  }
   super.visitLdcInsn(value);
}

后续主要是对于两个INVOKE进行分析

  • 如果getDeclaredMethod传入的是上文LDC处设置的污点,认为方法返回值也是污点,给栈顶的返回值设置REFLECTION_METHOD标志
  • 如果Method.invoke方法中的Method被标记了REFLECTION_METHOD则可以确定这是内存马
  • 开头一部分代码主要是根据方法参数的实际情况对参数在操作数栈中的索引位置进行确定,是一种动态和自动的确认方式,而不是直接根据经验或者调试写死索引,算是优雅写法
public void visitMethodInsn(int opcode, String owner, String name, String descriptor, boolean isInterface) {
   Type[] argTypes = Type.getArgumentTypes(descriptor);
   if (opcode != Opcodes.INVOKESTATIC) {
       Type[] extendedArgTypes = new Type[argTypes.length + 1];
       System.arraycopy(argTypes, 0, extendedArgTypes, 1, argTypes.length);
       extendedArgTypes[0] = Type.getObjectType(owner);
       argTypes = extendedArgTypes;
  }
   boolean reflectionMethod = owner.equals("java/lang/Class") &&
       opcode == Opcodes.INVOKEVIRTUAL && name.equals("getDeclaredMethod");
   boolean methodInvoke = owner.equals("java/lang/reflect/Method") &&
       opcode == Opcodes.INVOKEVIRTUAL && name.equals("invoke");
   if (reflectionMethod) {
       int targetIndex = 0;
       for (int i = 0; i < argTypes.length; i++) {
           if (argTypes[i].getClassName().equals("java.lang.String")) {
               targetIndex = i;
               break;
          }
      }
       if (operandStack.get(argTypes.length - targetIndex - 1).contains("LDC_STRING")) {
           super.visitMethodInsn(opcode, owner, name, descriptor, isInterface);
           operandStack.set(TOP, "REFLECTION_METHOD");
           return;
      }
  }
   if (methodInvoke) {
       int targetIndex = 0;
       for (int i = 0; i < argTypes.length; i++) {
           if (argTypes[i].getClassName().equals("java.lang.reflect.Method")) {
               targetIndex = i;
               break;
          }
      }
       if (operandStack.get(argTypes.length - targetIndex - 1).contains("REFLECTION_METHOD")) {
           super.visitMethodInsn(opcode, owner, name, descriptor, isInterface);
           Result result = new Result();
           result.setKey(owner);
           result.setType(Result.CLASSLOADER_DEFINE);
           results.add(result);
           return;
      }
  }
   super.visitMethodInsn(opcode, owner, name, descriptor, isInterface);
}


相关文章
|
6天前
|
Web App开发 监控 JavaScript
监控和分析 JavaScript 内存使用情况
【10月更文挑战第30天】通过使用上述的浏览器开发者工具、性能分析工具和内存泄漏检测工具,可以有效地监控和分析JavaScript内存使用情况,及时发现和解决内存泄漏、过度内存消耗等问题,从而提高JavaScript应用程序的性能和稳定性。在实际开发中,可以根据具体的需求和场景选择合适的工具和方法来进行内存监控和分析。
|
30天前
|
编译器 C语言
动态内存分配与管理详解(附加笔试题分析)(上)
动态内存分配与管理详解(附加笔试题分析)
47 1
|
2月前
|
程序员 编译器 C++
【C++核心】C++内存分区模型分析
这篇文章详细解释了C++程序执行时内存的四个区域:代码区、全局区、栈区和堆区,以及如何在这些区域中分配和释放内存。
50 2
|
1天前
|
开发框架 监控 .NET
【Azure App Service】部署在App Service上的.NET应用内存消耗不能超过2GB的情况分析
x64 dotnet runtime is not installed on the app service by default. Since we had the app service running in x64, it was proxying the request to a 32 bit dotnet process which was throwing an OutOfMemoryException with requests >100MB. It worked on the IaaS servers because we had the x64 runtime install
|
11天前
|
Web App开发 JavaScript 前端开发
使用 Chrome 浏览器的内存分析工具来检测 JavaScript 中的内存泄漏
【10月更文挑战第25天】利用 Chrome 浏览器的内存分析工具,可以较为准确地检测 JavaScript 中的内存泄漏问题,并帮助我们找出潜在的泄漏点,以便采取相应的解决措施。
85 9
|
15天前
|
并行计算 算法 IDE
【灵码助力Cuda算法分析】分析共享内存的矩阵乘法优化
本文介绍了如何利用通义灵码在Visual Studio 2022中对基于CUDA的共享内存矩阵乘法优化代码进行深入分析。文章从整体程序结构入手,逐步深入到线程调度、矩阵分块、循环展开等关键细节,最后通过带入具体值的方式进一步解析复杂循环逻辑,展示了通义灵码在辅助理解和优化CUDA编程中的强大功能。
|
30天前
|
程序员 编译器 C语言
动态内存分配与管理详解(附加笔试题分析)(下)
动态内存分配与管理详解(附加笔试题分析)(下)
45 2
|
1月前
|
SQL 分布式计算 Hadoop
Hadoop-19 Flume Agent批量采集数据到HDFS集群 监听Hive的日志 操作则把记录写入到HDFS 方便后续分析
Hadoop-19 Flume Agent批量采集数据到HDFS集群 监听Hive的日志 操作则把记录写入到HDFS 方便后续分析
42 2
|
2月前
|
算法 程序员 Python
程序员必看!Python复杂度分析全攻略,让你的算法设计既快又省内存!
在编程领域,Python以简洁的语法和强大的库支持成为众多程序员的首选语言。然而,性能优化仍是挑战。本文将带你深入了解Python算法的复杂度分析,从时间与空间复杂度入手,分享四大最佳实践:选择合适算法、优化实现、利用Python特性减少空间消耗及定期评估调整,助你写出高效且节省内存的代码,轻松应对各种编程挑战。
39 1
|
1月前
|
SQL 安全 算法
ChatGPT高效提问—prompt实践(漏洞风险分析-重构建议-识别内存泄漏)
ChatGPT高效提问—prompt实践(漏洞风险分析-重构建议-识别内存泄漏)
下一篇
无影云桌面