整体介绍

共四个jsp webshell 当时用来参加青藤webshell bypass 活动。主要思路是在静态中寻找动态特性：jdk内置javascript引擎，class字节码加载

0.jsp webshell裸奔

最直接的写法直接over。另外发现本机PC windows defender也有把0.jsp查杀了。

1.jsp 借助JavaScript引擎开始第一次动态化

jdk内置javascript引擎，其中从jdk1.6默认实现是：Rhino jdk，jdk 1.8之后是：nashorn。1.jsp有对jdk不同版本做了适配。

2.jsp 基于动态化后的变形

1.jsp中只是使用了js引擎，但是还没充分发挥动态脚本混淆和变形的能力，2.jsp尝试做简单的替换变形。我们知道xss的防护对正则检测的挑战是很大的，个人的感受是xss经常伴随着html和JavaScript的混合，并且JavaScript的变化多端容易混淆带来的进一步的检测难度，这里我们实现了类似的思路：java 与JavaScript的混合，JavaScript的动态多变能力依然可以发力,所以无论是正则还是静态语法分析的检测方式应该都会带来一些障碍。

3.jsp 字节码动态加载

3.jsp 是基于defineClass0 加载字节码来bypass。当时的思路也是想历次的入侵黑客喜欢用base64做些绕过，java可以动态加载字节码，字节码十六进制传递很难被正则waf抓住。后面在研究 ”冰蟹“ 的时候看到也用了defineclass方式。

内置JavaScript引擎带来的脆弱

JEP提案，开发者 与安全三者的感想

jdk中是否要内置JavaScript引擎值得商榷，的确java开发者有比较强的 动态脚本 的需求，比如我自己做些规则引擎，配置系统的时候常用到这样的特性。这样的需求groovy是个很好的榜样，由第三方jar包提供。现实情况下内置的javascript引擎性可能不满足应用需求，比如jdk从1.8将实现换成nashorn，到了jdk15提案中又有人提议替换掉nashorn。还有在自己研究百度openrasp的时候，可以看到最早期版本java对应的规则引擎是由jdk内置提供的，而到最后还是因为性能问题切换到V8引擎。

solr配置脚本RCE

另记一次solr CVE-2019-0193 远程代码执行漏洞，记得当初这个0day爆出的时候乙方的poc文章对payload打了马赛克，结合官方文档已经猜到是javascript动态配置引起，立马验证确实如此。此处有“default”，脆弱性立马显现。

一句话javascript引擎哪家强有由用户自己决定吧

对比其他webshell工具

在写完上面的几个jsp的webshell的时候，和部门做渗透同事交流他提到过一个“冰蟹”。以前对webshell工具的理解上更多的关注自动化，方便，比如“中国菜刀”。但是“冰蟹”不同，他借用了协议交互会话的逻辑去增强bypass能力，开阔了思路值得借鉴。

RASP能做些什么？

以百度rasp为例，针对冰蟹，javascript动态脚本的webshell如何去匹配呢？

我们可以看到rasp会hook住java stacks信息，然后去和已知的黑名单库去匹配，比如上面提到的 javascript引擎手法（关键字nashorn），冰蟹（关键字behinder）。不得不说rasp这种以调用栈作为上下文检测的更加精准，但是软件的生命周期是迭代的，对抗的手法也是升级的。

比如javascript引擎随着jdk版本的迭代而变化，策略脚本中缺失了jdk 1.8 之前Rhino方式 。对于冰蟹关键字”behinder“匹配能够防住工具小子，尽管冰蟹作者没有公布源码，但是拟向这类工具更改包名都不是难事，从而逃脱rasp的检查。