Ognl和EL表达式以及内存马的安全研究

首先研究表达式引擎的安全问题，主要通过对比st2的ognl表达式注入和el表达式注入，我们来看看目前java安全的一些情况。

 

1）ognl表达式

ognl表达式注入漏洞主要出在st2这个开发框架上，我们先看看官方的漏洞地址

https://cwiki.apache.org/confluence/display/WW/Security+Bulletins

除去dos漏洞、jackson和xstream漏洞、xss漏洞，剩下的都是ognl表达式rce了

那我们可以仔细读读下面这篇文章，已经有安全巨头逐个分析ognl漏洞的机理了，给出了完整的总结。

https://www.anquanke.com/post/id/169735

 

2）el表达式

el表达式分为：SimpleEvaluationContext 和 StandardEvaluationContext，其中SimpleEvaluationContext默认情况下是安全的

2.1）下面这个链接是CVE-2022-22947 Spring Cloud Gateway 表达式注入的修复补丁

https://github.com/spring-cloud/spring-cloud-gateway/commit/337cef276bfd8c59fb421bfe7377a9e19c68fe1e

 

2.2）下面这个链接是CVE-2022-22963 Spring Cloud Function 表达式注入的修复补丁

https://github.com/spring-cloud/spring-cloud-function/commit/0e89ee27b2e76138c16bcba6f4bca906c4f3744f

通过上面两个例子我们可得治，在业务允许的情况下应使用SimpleEvaluationContext 而不是 StandardEvaluationContext执行el表达式

 

2.3）而下面的链接可以看出，CVE-2022-22980 spring-data-mongodb 的修复方案则使用了过滤内容的方式而不是简单的使用SimpleEvaluationContext

https://github.com/spring-projects/spring-data-mongodb/commit/30a417d810c43dd097e117beb24ca49074c5b04d

 

3）通过以上内容我们可以得到一个概念，表达式注入其实很像脚本注入。系统为了增加业务效率和灵活性时可以执行外部提交的任意动态表达式，但是直接执行没有过滤或者过滤不严格的外部表达式，则会导致安全风险。可是当我们去搜索对el表达式的过滤资料时，发现我们只能搜索到一些使用信息，找不到安全过滤方面的知识。所以我们只能自己总结啦：

通过对内存马注入的各个表达式进行分析，过滤单引号是目前较好的过滤逻辑

同时spring-data-mongodb 的补丁也是如此执行的

 

4）进一步总结下，内存马的注入可以依赖：

4.1.1）jndi注入，在高版本java中已经默认不允许远程jndi注入

4.1.2）el表达式、ognl表达式

4.1.3）webshell

4.1.4）agent注入

webshell和agent涉及到硬盘写入，这个和主机安全产品有关联，本文我们就不分析了。剩下来则还是要关注表达式引擎。

所以讨论到这一步，最好的办法就是利用rasp技术监控el表达式和ognl表达式的执行内容，一旦表达式长度超过了阈值比如100，则rasp应将当前表达式进行上报并进行一次jvm全进程的安全分析。

 

4.2）安全分析的范围应包括常见的内存马相关类

4.2.1）Servlet，Filter，Listener，Tomcat Value Pipe，Spring Controller，Spring Interceptor

（参考本文：https://mp.weixin.qq.com/s/HODFJF3NJmsDW2Lcd-ebIg）

4.2.2）以上这些类应使用hsdb技术进行分析，防止agent注入的字节码没有被捕获

参考本文：https://my.oschina.net/9199771/blog/5529686

 

4.3）安全分析应判断常见的内存马相关类是否异常

系统在启动完毕后应缓存所有内存马相关类的信息，在jvm全进程的安全分析时依据该信息执行判断内存马相关类是否满足以下条件：

4.3.1）相关类在内存中存在而硬盘中不存在

4.3.2）系统新增了启动完毕后不存在的相关类

4.3.3）相关类的字节码与启动完毕后不一致

4.3.4）ast分析存在异常的类

 

5）通过source->sink的理论，我们应监控外部输入所触发的行为函数，对jvm完整性进行有针对性的校验，及时对内存马进行安全审计。如果我们更扩展的审视内存马问题、对比上传写入jsp、jspx的webshell的行为，我们可以得出一个推论：

5.1）硬盘webshell和agent马破坏了硬盘数据、篡改了应用逻辑，破坏了原始应用的逻辑完整性（建议通过防篡改产品进行安全防护）

5.2）内存马破坏了应用内存中的逻辑完整性 （建议通过具有相关能力的rasp产品进行防护）

 

最后感谢达达的技术支持

 

禁止转载