Research on the security of ognl and El expressions and memory horse

First, we study the security of expression engine , Mainly through comparison st2 Of ognl Expression injection and el Expression injection , Let's take a look at the present java Some situations of safety .

 

1）ognl expression

ognl The expression injection vulnerability mainly lies in st2 On this development framework , Let's first look at the official vulnerability address

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

remove dos Loophole 、jackson and xstream Loophole 、xss Loophole , The rest is ognl expression rce 了

Then we can read the following article carefully , Security giants have analyzed one by one ognl The mechanism of the vulnerability , Gives a complete summary .

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

 

2）el expression

el Expressions are divided into ：SimpleEvaluationContext and StandardEvaluationContext, among SimpleEvaluationContext By default, it's safe

2.1） The following link is CVE-2022-22947 Spring Cloud Gateway Fix for expression injection

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

 

2.2） The following link is CVE-2022-22963 Spring Cloud Function Fix for expression injection

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

Through the above two examples, we can cure , Where business permits, use SimpleEvaluationContext instead of StandardEvaluationContext perform el expression

 

2.3） The link below shows ,CVE-2022-22980 spring-data-mongodb Instead of simply using SimpleEvaluationContext

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

 

3） Through the above content, we can get a concept , Expression injection is actually much like script injection . In order to increase business efficiency and flexibility, the system can execute any dynamic expression submitted externally , But directly execute external expressions that are not filtered or not strictly filtered , It will lead to safety risks . But when we search for the right el When filtering data of expressions , It is found that we can only search some usage information , Can't find knowledge about security filtering . So we can only summarize by ourselves ：

By analyzing the expressions injected into the memory horse , Filtering single quotation marks is a better filtering logic at present

meanwhile spring-data-mongodb The patch of is also implemented in this way

 

4） To sum up further , The injection of memory horse can depend on ：

4.1.1）jndi Inject , In the high version java Remote is not allowed by default in jndi Inject

4.1.2）el expression 、ognl expression

4.1.3）webshell

4.1.4）agent Inject

webshell and agent Involving hard disk writing , This is related to host security products , In this article, we will not analyze . The rest is to focus on the expression engine .

So let's discuss this step , The best way is to use rasp Technical monitoring el Expression and ognl The execution content of the expression , Once the expression length exceeds the threshold, such as 100, be rasp The current expression should be reported and performed once jvm Safety analysis of the whole process .

 

4.2） The scope of security analysis should include common memory horse related classes

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

（ Refer to this article ：https://mp.weixin.qq.com/s/HODFJF3NJmsDW2Lcd-ebIg）

4.2.2） The above classes should use hsdb Technology for analysis , prevent agent The injected bytecode is not captured

Refer to this article ：https://my.oschina.net/9199771/blog/5529686

 

4.3） The security analysis should judge whether the common memory horse related classes are abnormal

The system should cache the information of all memory horse related classes after startup , stay jvm During the security analysis of the whole process, the information is used to judge whether the memory horse related classes meet the following conditions ：

4.3.1） Related classes exist in memory but not in hard disk

4.3.2） The system adds related classes that do not exist after startup

4.3.3） The bytecode of related classes is inconsistent with that after startup

4.3.4）ast Analyze classes with exceptions

 

5） adopt source->sink The theory of , We should monitor the behavior function triggered by external input , Yes jvm Targeted verification of integrity , Timely conduct safety audit on the memory horse . If we look at the memory horse problem more extensively 、 Compare upload and write jsp、jspx Of webshell act , We can draw a conclusion ：

5.1） Hard disk webshell and agent The horse destroyed the hard disk data 、 Tampered with the application logic , It destroys the logical integrity of the original application （ It is recommended to use tamper proof products for security protection ）

5.2） Memory horse destroys the logical integrity of application memory （ It is suggested to pass rasp Product protection ）

 

Finally, thank dada for its technical support

 

Prohibited reproduced