从传统到AI探讨Webshell检测攻防对抗

近些年，各个厂商常常举办WebShell绕过挑战赛，用以检测其WebShell检测引擎的稳定性与检出能力。结合一些我的参赛经历以及对商业产品WebShell检测引擎的攻防对抗经历，聊一聊WebShell检测的绕过思路。

在思考如何绕过前，首先需要明确的是，检测引擎究竟会拦截什么行为。一个WebShell检测引擎，往往会结合多种检测方法进行检测，因此我们需要拆分检测方法，再基于每个引擎的拦截方法思考对应的绕过策略，最后将各引擎的绕过方法进行整合，从而实现完整的绕过。对于拦截的内容，由于引擎对于我们来说是黑盒，因此只能通过反复测试的方法去确认引擎的拦截方式。

根据测试可以发现，检测引擎常常会使用以下几类方法进行行为检测：

• 静态检测。这里主要指的是源码规则的静态匹配手段，通过对已知的WebShell特征和模式（比如特定的字符串或者代码结构），例如Runtime.getRuntime().exec()、ProcessBuilder().start()等进行匹配，从而达到检测的目的。这种方法的优点是检测速度快，实现成本低，但是缺点是极其依赖文本特征的提取，容易误报也容易被绕过。

  
  

• 动态沙箱。将样本放在模拟的环境中执行，模拟攻击者的输入，通过hook危险函数进行检测。这种方法优点是不强依赖知识和规则，可以检测出一些未知的WebShell样本，但最大的缺点是它无法准确模拟出攻击者的外部输入，从而导致模拟执行的输入和真实攻击的输入不同，代码走向不同，形成绕过。

• 模拟污点执行。将样本进行词法和语法分析形成AST，通过对用户可控的数据标记为污点Source，结合对节点进行静态的遍历分析以及动态的模拟执行代码，判断污点是否可以传递到危险函数Sink，从而进行WebShell的检测。这种方法的优点是可以结合了静态和动态的分析技术，误报率相对较低，但缺点是实现相对复杂，污点传播可能由于编程语言的trick、特性等问题导致规则覆盖不全，形成绕过。

针对引擎的静态检测，应对方法就是尽量去寻找一些不常见的命令/代码执行方法，这些方法最终调用了了危险的代码执行/命令执行sink，如果这些方法没有在目标引擎的匹配规则里，就可以实现绕过。在Java中最常见的命令执行方法是如下两种：

• Runtime.getRuntime().exec()

• new ProcessBuilder().start()

在Tabby中分别查找JDK11中调用了这两个方法的方法：

可以发现链不是很多，逐一手动分析。由于反射的代码特征相对明显，因此尽量减少对非公共方法或者类的依赖。整理各个关键类的特性如下：

• com.sun.tools.jdi.AbstractLauncher的两个实现类：公共类，执行命令的方法为公共方法；

• sun.security.krb5.internal.ccache.FileCredentialsCache$2：内部匿名类，无公共调用方法；

• sun.net.www.MimeLauncher：非公共类；

• jdk.internal内的多个类：属于jdk.internal模块，Tomcat的WebShell默认情况下访问不到该模块，需要使用反射等方法进行类加载，动静比较大。如果目标引擎不会拦截反射可以考虑使用。

com.sun.tools.jdi.AbstractLauncher的两个实现类无疑是最符合要求的。两个类差不多，这里以com.sun.tools.jdi.SunCommandLineLauncher举例分析。

其存在一个public的launch方法，通过对参数的一系列赋值，对传入的命令进行字符串拼接，调用其父类的launch方法。

另一个launch方法是其父类com.sun.tools.jdi.AbstractLauncher的方法

创建一个Helper对象，并调用其launchAndAccept方法：

可以看到，没有什么过滤，可以直接到达Runtime.getRuntime().exec()。并且参数也是从第一个launch方法中传进去的，攻击者可控。看起来可以用来构建WebShell。在构建的过程中需要注意一个点：launch函数的入参是这样的：

这里Connector.Argument是一个接口，其所有实现类均是内部类，所以我们无法直接新建一个该类的对象。但是可以通过在其他我们可以访问到的对象中寻找具有公共属性的arguments对象来获取符合条件的Connector.Argument实例，并且该类的赋值方法setValue方法是public方法，所以也可以在不使用到反射等方法的情况下修改属性值。构建的WebShell如下：

在实际的WebShell绕过比赛中，这个样本也会被拦截。如何根据现有的成果完成绕过呢？此时我们已经找到了一个com.sun.tools.jdi.SunCommandLineLauncher类，其public的launch方法可以执行命令，既然它是public的类，存在public构造方法，并且存在public的launch，那它就很有可能在其他的类库中被调用。

我们将它作为新的sink点进行搜索，但是直接搜会发现搜不到调用链，这也符合我们在第一步在搜索Runtime.getRuntime().exec()的结果，因为如果能搜到，那么我们在第一步的Tabby搜索时就应该可以找到相应的链。

观察SunCommandLineLauncher类，发现它的launch方法实际上是实现的com.sun.jdi.connect.LaunchingConnector接口的launch 方法：

用tabby搜索，发现可以搜索出两条路径

• com.sun.tools.example.debug.tty.VMConnection：这是一个内部类

  
  

• jdk.jshell.execution.JdiInitiator：public类，并且其launch调用是在public构造方法中进行的

  
  

显然jdk.jshell.execution.JdiInitiator很符合要求，观察其构造方法如下：

构造方法其将传入的customConnectorArgs对象最终导入到connectorArgs 属性，另外在isLaunch为true的情况下，connectorName为com.sun.jdi.CommandLineLaunch，findConnector会根据该字段去寻找，而这正是com.sun.tools.jdi.SunCommandLineLauncher的name。

该方法最终调用launchTarget()：

在该方法中，调用了launcher.launch(connectorArgs)，完成命令执行。整合上述内容，可以构造WebShell如下：

这个样本一方面使用了不常见的类进行命令执行，可以绕过静态检测引擎，另外一方面，它在执行命令时使用是其接口类的launch方法，就像是Tabby搜不到该类一样，对于模拟污点执行引擎来说，从接口调用，搜索并遍历其实现类的方法调用是比较困难且消耗性能的，它很难判断当前使用的这个connector是否是一个危险的connector，从而被绕过。

这个类的特性很好，一个公共构造函数调用就可以完成命令执行，和今年（23年）的KCon上的议题《Magic In Java API》里提到PrintServiceLookup类有异曲同工之妙，可以用在例如Dubbo的CVE-2023-23638的漏洞利用，或者其他类似的反序列化场景。

但可惜是这个类仅在JDK9及以上的版本存在，并且在今年5月jdk的一次更新中，禁用了对vmexec参数的赋值，导致无法再通过直接调用构造方法触发命令执行：

这个修改导致该方法无法在目前最新版本的jdk11.0.20及以以后的版本中使用。

关于不常见的危险类，除了在JDK中寻找，我们其实还可以扩大找的范围，WebShell大多数情况下运行在Tomcat容器，使用其代码中的类也可以做到基本上通杀。

比如org.apache.catalina.ssi.SSIExec类的process方法：

构造如下：

除了Runtime.getRuntime().exec()和ProcessBuilder().start()，也可以使用JNDI注入实现代码执行，并且我们已经可以执行WebShell，因此JNDI注入也不受JDK版本的限制。

在真实的环境中或者特定的软件环境，很有可能还会存在其他三方依赖。针对性的挖掘三方依赖中的漏洞利用类，相对来说绕过引擎静态分析黑名单的概率会更大一些。

针对动态沙箱的检测，如果可能让引擎在运行或者模拟运行时无法到达恶意代码的分支，则可以绕过。以如下样本为例：

SunCommandLineLauncher类的launch方法中就存在runtime.getRuntime().exec()的调用。对于动态引擎来说，很容易发现该问题。因此如下面介绍几种可行的方法。

• 使用随机数

如果引擎会在沙箱运行程序，则由于Random的随机性，可能会进入else分支，从而检测不到恶意代码被运行，模拟运行也可能会因为无法判断两个nextInt()对象会相同从而检测不到。

而我们把random的范围设置的小一点，则在实际运行时，可以保证有一个较高的概率，在我们运行代码时程序被运行。事实上这里的nextInt参数也可以动态传入，进一步区分引擎运行和我们人工运行的概率区别。

• 利用异常捕获

  利用动态沙箱引擎无法准确判断并模拟用户的输入内容，进行绕过。

正常来说程序不会进入catch块，当请求的参数中包含?1=0时，程序会触发零除异常，进入catch块执行恶意操作。

上面介绍了几种的方法，但是实际的引擎往往会结合动态检测或者模拟动态检测等技术进行检测和拦截。下面介绍动态类型的检测绕过思路。

可以利用Java的语言特性误导引擎对方法调用的识别。

• 利用方法“重载”

  首先提出一个问题。在java中，一个类如果长这样：

那么这里显然是会调用B类的print方法。但如果B类是如下写法呢？

或者如下写法：

这是一个乍看起来重载了，但是又没完全重载的例子。事实上，程序最后会调用的均是入参为String的print方法，在第一个例子中，会调用A.print()，在第二个例子中会调用B.print()。

在上述两个例子中，子类和父类的参数都不同，也就代表A.print和B.print是两个不同的方法。而java的方法调用过程中，并不是遵循“先在子类的方法中寻找符合条件的方法，找不到再去父类中寻找这种方法”，而是直接在目标类及其所有父类方法中去找和调用方法最匹配的那个方法，进行加载和调度。

然而对于WebShell检测引擎来说，可能为了性能考虑，或者是对Java的方法调用过程不够了解，会在模拟运行时，遵循上面说的那种寻找方法的方法，先在子类方法中寻找，找不到再去父类方法中寻找。

导致了引擎获取到的执行方法和Java程序实际的执行方法出现不同，从而触发了绕过。举一个WebShell的例子：

对于检测引擎来说，样本运行的是两个空的setDataSourceName和setAutoCommit方法。但实际上程序执行的还是JdbcRowSetImpl的方法，导致了绕过。

• 利用Java类的多态误导引擎识别对象类型

  如果存在如下接口：

如果我们创建一个类：

这样毫无疑问会编译不通过，因为我们没有在B中对A接口的两个方法定义进行实现。

但是如果此时我们把Class B修改成如下写法：

会发现编译可以通过。原因是java在编译的过程中是先处理继承，再处理接口。因此当我们的B类继承了JdbcRowSetImpl 类，再去实现A接口时，Java会从B及其父类方法中寻找实现方法。

同时由于 Java类的多态，我们对实现类为 B 的 A 接口对象，调用其定义的 set*方法时，它会调用 B 继承的 JdbcRowSetImpl 类中的对应方法。

但是对于检测引擎来说，此时执行的是接口A的setDataSourceName和setAutoCommit方法。引擎很难获取到接口A会和JdbcRowSetImpl 类有什么关系。它顶多在接口A的实现类中寻找是否存在危险方法或调用，无论如何也找不到JdbcRowSetImpl的头上。

因此也就无法判断该样本为WebShell。根据此方法进行WebShell构建：

• 隐式方法调用

  java中存在一些语法糖，如果引擎未能对这类模式进行识别，则也可以产生绕过。

对对象进行字符串拼接时，会隐式的调用其toString方法。类似还有hashCode之类的方法。

• 隐藏污点传播

  单是上面几类绕过，更多的是阻断引擎发现我们的意图是在执行危险的sink，在很多时候还是无法绕过真实的检测引擎。有一个重要原因是source点往往会或多或少的暴露我们的真实意图。拿上面这个样本来说：

JdbcRowImpl的利用模式在Java安全太过出名，所以它还是具备很强的WebShell特征，另外引擎在模拟污点分析过程中对于source的跟踪和检测也比较容易发现一些我们想隐藏的意图。因此还有一个重要的绕过点，就是对于污点的隐藏，切断引擎对污点传播的分析。

一种很好用的方法是利用全局变量：

利用System类的setProperty和getProperty方法进行参数的传递。引擎很难判断exec的参数System.getProprety("test")是来自用户输入的污点。

一切出现字符串的地方都可以用request.getParameter代替。因此request.getParameter()的参数也可以递归放入request.getParameter()，并且最终也可以不使用硬编码的字符串，而是在系统中寻找一些字符串作为参数，加强混淆效果，例如：

如果System.setProperty会被引擎识别或者拦截，则也可以像本文第一部分中找不常见的代码执行/系统执行的方法，找一些不常见的类会调System.setProperty的方法的类进行绕过。另外，从本质上说，任何可读写的全局变量、单例对象都可以用来进行参数的传递。

2023年是大模型的元年，可以预想到接下来的各家检测引擎也会集成大模型的能力。因此在思考检测绕过时，也应该未雨绸缪，预演一下对大模型检测的绕过。

我使用GPT-4对本文中提供的各个样本进行了测试，感叹大模型的能力强悍的同时，也发现了一些潜在的机会和问题。

我使用的模型检测prompt如下：

测试发现，对于文章提到的第一类绕过方法，GPT-4都可以识别出来。这也很好理解，GPT-4的知识库是极其丰富的，因此很难找到GPT-4都不知道的命令执行/代码执行类。以如下样本为例：

GPT-4回答如下：

它很轻松的识别出样本中使用的JniInitiator类可以用来执行任意命令，在识别到样本可以进行这种行为模式后，判断样本为True。

但是在我对JNDI注入类的WebShell进行注入时，GPT-4的检测结果发生了些变化，我的样本如下：

GPT4的回答如下：

GPT-4察觉到了我这里定义了一个a类并重写了两个方法是为了绕过安全检查。但是它一顿分析，最后判断存在风险的点是”存在动态执行数据库操作的可能“，显然是错误的。这里存在两个错误：

1. 一般来说，我们指的WebShell是可以达到执行任意命令/代码的样本，这里AI理解的WebShell更加宽泛，在实际的场景中容易误报。

2. 这个样本真正存在危险的点是可以利用JNDI注入造成RCE，而不是它提到的SQL注入风险，他这里返回True，多少有点误打误撞的嫌疑。

因此，如果我们在写WebShell检测Prompt时，对WebShell的范围进行定义，那它是否还能检测出来？补充上面的Prompt如下：

GPT-4的回答如下：

可以看到GPT-4此时就暴露它不知道JdbcRowSetImpl→JNDI注入这个攻击面，从而进判断样本可以执行SQL注入，但是没有识别到代码执行的风险，从而给出了错误的回答，导致绕过。

另外值得一提的是，我在GPT-3.5中多次开启新的聊天让它判断这个样本是否是一个WebShell，它每次返回答案的结论都不同：

同样的样本，有时候会在分析后返回True，重新问，它又会返回False。可见，能力相对弱一些的模型在WebShell检测引擎上中是不可用的。

整体来说，GPT-4不太会关注你的代码逻辑是否正确，污点是否传播到恶意类之类、甚至程序能否正确运行等问题。它更多的是遵循如下的运行逻辑：

举一个更直观的例子，下面一个利用EL表达式的动态特性的WebShell样本，对于传统的WebShell检测引擎来说这个样本很难被检测到。

GPT-4给出分析如下：

它并没有详细的给出攻击者如何/利用哪些类/如何构建利用链来进行代码/命令执行，而是按如下步骤进行分析：

1. 分析代码。判断样本是EL表达式的代码片段；

2. 归纳行为。判断代码可以访问对象、调用方法；

3. 判断意图。判断代码可以用来执行任意代码；

4. 识别模式。判断攻击者参数可控，这是一个典型的WebShell行为；

5. 下判断。

针对大模型检测WebShell的特点，我提出并测试了几种可能的绕过方法：

1. prompt注入

如果检测引擎在对大模型检测引擎调用时，没有对prompt和WebShell样本进行有效的区分，或者对输入进行前置的防御处理。那么攻击者可以在WebShell样本中加入prompt，误导检测引擎进行错误的返回，举例如下：

如果一个基于大模型的检测引擎的demo代码如下，提供一个检测接口，如果样本是WebShell，则返回True，否则返回False：

那么我们可以在WebShell中，添加如下内容：

在GPT4中进行模拟测试，可以成功篡改目标的返回。

2. 攻击面绕过

大模型的知识库虽然丰富，但也存在一些弊端：

• 针对无法联网运行的大模型，它的知识库具备时效性。对于晚于它知识库构建时间被公开的攻击面，可能就无法做到很好的检测效果。可以考虑使用的点例如，新公开的0/1day漏洞、新公开的执行命令方法、攻击面等；

  
  

• 另检测引擎的知识库来自于其训练集，如果目标的训练集中不包含该攻击面的知识，则会降低检测的效果。例如GPT-4来自美国，对于只在中国流行或者研究比较多的攻击面，可能训练集包含的内容就相对会少一些，从而导致这种类型的攻击面会失效。

因此可以针对性的寻找模型的”知识盲区“进行绕过。以GPT举例如下：

• 通过测试发现，GPT无论是知识截止时间是2022年1月的GPT-3.5，还是2021年9月的GPT-4，甚至2023年4月的GPT-4-Turbo，都对H2 JDBC 连接串的漏洞了解不多，事实上，H2 JDBC连接串的INIT参数是可以执行任意代码的，下面是关于问题：

几个模型的回答如下：

• GPT-3.5

• GPT-4

可以看到随着模型的进步，程序给出的信息会更加的全面和详细。但就关键指标来说，虽然GPT-4的两个模型列出了INIT参数，但它们均只认为该参数可以执行SQL脚本，并未给出可以执行任意Java代码的提示。因此如果一个环境中存在H2 JDBC依赖，就可以尝试使用相关的WebShell进行绕过，样本如下：

GPT-4给出的回答如下：

可以看出GPT很纠结，它不认为这个样本可以直接执行任意代码，但它认为这个样本可以连接数据库，进行SQL注入之类的操作，并根据对WebShell的定义不同，给出了两个截然相反的结论。而从我们的经验可知，这个结论无疑是错误的，原因就是模型的知识库并没有覆盖到这种攻击面。

3. 模型支持的请求大小绕过

由于大模型需要对请求的语句进行逐个加载和分析，因此对请求的长度大多会有限制。同时在WebShell检测这种对并发性和实时性有一定要求的场景，更是会限制长度，提高效率。那么构造一个冗长、包含大量无效数据的WebShell就可以突破目标模型的检测能力，达到绕过检测的效果。例如我构建了一个文本大小为2M的WebShell，发送给GPT-3.5进行检测，GPT会直接卡住，无法给出结果。

随着技术的不断进步，WebShell检测和绕过的攻防对抗也在不断演化。本文提供了一些现有引擎的检测绕过思路和案例，也浅谈了一些未来可能面临的挑战，尤其是在大模型如GPT-4等人工智能技术被应用于检测引擎时，这一领域的攻防对抗可能会出现的场景。随着攻防技术的不断升级，WebShell检测领域必将迎来更多的挑战和机遇。

【版权说明】

本作品著作权归YYHY所有

未经作者同意，不得转载