Apache Struts Double OGNL Evaluation (S2-061 / CVE-2020-17530)
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. 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. 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. Figure 3: Struts application modified to use an anchor tag instead of a form tag 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 beingdouble evaluated. 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. Figure 6: Exploit attempt blocked by signature id 200004224
