cancel
Showing results for 
Search instead for 
Did you mean: 
Gal_Goldshtein
F5 Employee
F5 Employee

Today a new security bulletin was published by Apache Struts identified by S2-061 and CVE-2020-17530.

 

This vulnerability is very similar to a one that we already discussed in a previous post, and also the same conditions must be met for a Struts application to be vulnerable.

This new advisory was published because it was discovered that certain Struts tags which are rendered on the server side will still perform double OGNL evaluation despite of the previous fixes that attempted to prevent such condition.

In order to find those tags we set up our Struts application to use an unpatched version of the Struts library, and we created a Struts server-side form tag that both applies forced OGNL evaluation (uses the %{} syntax) on the “id” attribute value and also allows the attribute value to be user controlled.

0151T000003q3j3QAA.png

Figure 1: Struts form tag set to perform forced OGNL evaluation with user-controlled input

When we send a request that contains an OGNL expression in the “id” parameter we can see that our OGNL expression was not evaluated by the server which means double OGNL evaluation did not happen in this case, as expected.

0151T000003q3j8QAA.png

 

Figure 2: OGNL expression was not evaluated in the form tag id attribute value

However, if we change our application to use an anchor tag instead of a form tag, we can see that on the same request that we previously sent was now evaluated, which means double OGNL evaluation occurred.

0151T000003q3jDQAQ.PNG

Figure 3: Struts application modified to use an anchor tag instead of a form tag
 

0151T000003q3jIQAQ.png

Figure 4: user specified OGNL expression was evaluated in the application anchor tag id attribute value

In the fixing commit we can see that the calls to the “findString “and “findValue” methods that triggered one of the cycles of the OGNL expression evaluation were removed thus preventing our OGNL expression from being double evaluated.

0151T000003q3jNQAQ.png

Figure 5: “findString” method call was removed

Mitigation with Advanced WAF

Advanced WAF customers under any supported version are already protected against this vulnerability as exploitation attempts of this vulnerability are detected by existing Java code injection signatures.

0151T000003q3jSQAQ.png

Figure 6: Exploit attempt blocked by signature id 200004224

Version history
Last update:
‎08-Dec-2020 17:37
Updated by:
Contributors