Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Clear all filters
Answers

How to fix apache struts2 s2-045 vulnerable with f5 irule ?

How to fix apache struts2 s2-045 vulnerable with f5 irule ?

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hi Robinchien,

you need to either create a whitelist containing your allowed Content-Type request-header values (most secure but sligthly difficult approach) or black-list certain characters (e.g. @, ., ,, #, ( or )) and attack-patterns (e.g. ognl, memberaccess, getruntime, exec), which will unlikely used by your application but required to pulloff the s2-045 remote execution (less secure but easy to implement).

Whitelist approach:

when HTTP_REQUEST {
    switch -exact -- [string tolower [HTTP::header value "Content-Type"]] {
        "" - 
        "multipart/form-data" -
        "text/xml; charset=utf-8" - 
        "application/x-www-form-urlencoded" {
            # Allow request with empty or white listed "Content-Type" headers
        }
        default {
            # Reject request with unknown "Content-Type" headers
            reject
        }
    }
}

Blacklist approach:

when HTTP_REQUEST {
    switch -glob -- [string tolower [HTTP::header value "Content-Type"]] {
        "*@*" - 
        "*#*" - 
        "*.*" - 
        "*,*" - 
        "*(*" - 
        "*)*" - 
        "*ognl*" - 
        "*memberaccess*" -
        "*getruntime*" - 
        "*exec*" {
            # Reject requests with suspicious "Content-Type" headers
            reject
        }
        default {
            # Allow request with unsuspicious "Content-Type" headers
        }  
    }
}

Cheers, Kai

0
Comments on this Answer
Comment made 09-Mar-2017 by Kai Wilke 7377

Hi John,

I don't have comprehensive details of the entire attack vectors. I've assembled the iRule based on the google translated website of the security researchers and two exploit scripts. My goals was to make the iRule as generic and globaly as possible while trying to NOT break any legitimate traffic.

Your first iRule is indeed a very strict and secure Whitelist approach, which allows just a few Content-Type headers values to pass on a POST request. But this iRule will most likely also catch legitimate traffic, since the allowed Content-Type values are just a few (e.g. JSON, XML, different charset options are missing). So if I where you, I would add a warning message to your codeshare contribution, that the iRule MAY need further adjustments before going into production.

Cheers, Kai

0
Comment made 09-Mar-2017 by Todd 0

FWIW, the vulnerability can be executed via GET requests, as I've seen in the Qualys report on it. I've confirmed this on some systems under my control.

0
Comment made 09-Mar-2017 by John Alam

Thanks Kai.

I agree with you. Hopefully the irule is simple enough so people can make adjustements to fit their applications.

I combined yours and mine in the codeshare post. Using the switch statement it is easier to add more items to the whitelist.

According to Todd, the attach can be executed via a GET. Therefore, the "if" statement matching the POST should be removed.

0
Comment made 10-Mar-2017 by Kai Wilke 7377

Hi John,

you may change the previous [HTTP::method] eq POST to become a [HTTP::header value "Content-Type"] ne "". This change will make sure that rather complex whitelist/blacklist parsings will only be executed if a [HTTP::header value "Content-Type"] is found. This should boost the performance of regular GET request a little.

In addition it may be wise to apply the blacklist/whitelist by using [HTTP::header values "Content-Type"] (values instead of value), to make sure that multiple "Content-Type" instances cant bypass the patter (I duno if this is an actual attack vector, but better to be prepared).

Cheers, Kai

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

The Vulnerability has to do with File upload so, no use checking every single request.

This is why my iRule on codeshare inspects the Content-Type for POST requests only.

Here.

    when HTTP_REQUEST {
      if { [HTTP::method] equals "POST" } {

            if { not ( [HTTP::header Content-Type] equals "multipart/form-data" or [HTTP::header Content-Type] equals "application/x-www-form-urlencoded" or [HTTP::header Content-Type] equals "text/plain" ) } {
                reject
                log local0. "Rejecting a POST request with Content-type [HTTP::header Content-Type]  to  [HTTP::uri]  from  [IP::client_addr]"
            }
      }
}  

One could restrict this further by matching against the URL(s) which present the upload form:

when HTTP_REQUEST {
      if { [HTTP::uri] equals "<enter upload uri here>" } {

            if { not ( [HTTP::header Content-Type] equals "multipart/form-data" or [HTTP::header Content-Type] equals "application/x-www-form-urlencoded" or [HTTP::header Content-Type] equals "text/plain" ) } {
                reject
                log local0. "Rejecting a POST request with Content-type [HTTP::header Content-Type]  to  [HTTP::uri]  from  [IP::client_addr]"
            }
      }
}
0
Comments on this Answer
Comment made 31-Mar-2017 by Kai Wilke 7377

This answer shouldn't be marked as answer. Its breaking applications and also not covering all attack vectors.

Cheers, Kai

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER