On August 22 a new vulnerability in the Apache Struts framework was announced. It allows unauthenticated attackers to perform Remote Code Execution (RCE) on vulnerable hosts.

As security researcher Man Yue Mo explained, the vulnerability has similarities with previous Apache Struts vulnerabilities. The Cloudflare WAF already mitigated these so adjusting our rules to handle the new vulnerability was simple. Within hours of the disclosure we deployed a mitigation with no customer action required.

OGNL, again

Apache Struts RCE payloads often come in the form of Object-Graph Navigation Library (OGNL) expressions. OGNL is a language for interacting with the properties and functions of Java classes and Apache Struts supports it in many contexts.

For example, the snippet below uses OGNL to dynamically insert the value "5" into a webpage by calling a function.

<s:property value="%{getSum(2,3)}" />

OGNL expressions can also be used for more general code execution:

${
    #_memberAccess["allowStaticMethodAccess"]=true,
    @java.lang.Runtime@getRuntime().exec('calc')
}

Which means if you can find a way to make Apache Struts execute a user supplied OGNL expression, you've found an RCE vulnerability. Security researchers have found a significant number of vulnerabilities where this was the root cause.

What’s different this time?

The major difference between the various OGNL related Struts vulnerabilities is where the payload can be supplied.

For example S2-003, S2-005 and S2-009 allowed OGNL expressions to be included in HTTP Parameters. In S2-045, expressions could be supplied via the ‘Content-Type’ header.  And S2-048 worked by inserting OGNL expressions anywhere they might be used incorrectly with the ActionMessage class (most likely via an HTTP parameter).

With S2-057, the payload is supplied via an action’s “namespace”. Semmel do a great job of explaining the exact conditions for this in their disclosure post.

An example is to omit the "namespace" parameter from the  redirectAction result type.

<package name="public" extends="struts-default">
    <action name="login" class="...">
        <!-- Redirect to another namespace -->
        <result type="redirectAction">
            <param name="actionName">dashboard</param>
            <!-- namespace is omitted -->
            <!--<param name="namespace">/secure</param>-->
        </result>
    </action>
</package>

The documentation describes this parameter as optional. If you don't include an explicit "namespace" then the client can supply it in the URI.

vulnerablesite.com/struts2-blank/my-current-name-space/HelloWorld.action

If the client inserts an OGNL expression instead, it will be executed.

vulnerablesite.com/struts2-blank/${#_memberAccess["allowStaticMethodAccess"]=true,@java.lang.Runtime@getRuntime().exec('calc')}/HelloWorld.action

Cloudflare’s got your covered

Cloudflare has rules to protect against this particular vulnerability, and many other Struts vulnerabilities. These have been configured as Block by default, so no customer action is needed, assuming the Cloudflare Specials rule set is enabled in your WAF configuration.

For customers on our Pro, Business and Enterprise plans, you can do this by going to the “Firewall” tab:

Clicking “Web Application Firewall” and setting the toggle to “On”:

Then finally ensuring the “Cloudflare Specials” rule set is set to “On” as well:

Where possible, we signature OGNL expressions in general, because of how dangerous it is for a server to trust any user-supplied OGNL. This allows the WAF to protect you without detailed knowledge of how specific exploits might work.

Additionally, for this and other Struts vulnerabilities, we produce rules that target specific locations where payloads can be supplied in (e.g. URI, parameters, etc). By focusing on specific payload vectors these rules can be much stricter in the range of inputs allowed, without the risk of increased false positives.

What we've seen in the last 24h

Since the disclosure, we've seen a fairly constant rate of attacks targeting S2-057 vulnerability:

About half of these are coming from known vulnerability scanners, however our research has shown that the vast majority of payloads are only probing, rather than attempting to execute malicious actions. The most common tactics for that are using the OGNL expression print extra strings in the server response, or append extra headers.

Aside from that, our Research team have also seen attempts to run various commands:

• Ipconfig.exe

• dir

• 'cat /etc/passwd'

• /sbin/ifconfig

• net users

• file /etc/passwd

• Whoami

• id

• Ping and nslookup commands to contact external servers

If you have any further questions about how our WAF works, or whether you have the right protections in place, please don’t hesitate to reach out to our Support teams.