If it bleeds...we can kill it!

[MitchHanks]

UPDATE: The functionality from the custom Lua parser described below is now available within the standard HTTP_lua parser provided from RSA Live.  If you are using this parser in your environment, the custom version attached here (including the app rule) is unnecessary.

Many of you may already be aware of a recent vulnerability known as "Options Bleed".  This vulnerability affects Apache web servers and allows access to the contents of memory via the HTTP Options request method.  This HTTP method is supposed to return the available methods (i.e. GET, POST, PUT, etc) to the browser.  For mis-configured web hosts with this un-patched vulnerability, some of the contents of memory are returned along with the available methods.

See the following post for a good write-up on the details of Options Bleed:

Apache “Optionsbleed” vulnerability – what you need to know – Naked Security 

Attached you will find a custom Lua parser and accompanying Application Rule to detect when this vulnerability is exploited.  The parser detects the response string provided by web server given an OPTIONS request method.  It then will identify whether or not the response is valid.  If not, it will register the following meta key/value:

analysis.service = 'garbled http options allow string'

In addition, I have provided an application rule which will tie in the presence of this garbled string with some other information about the session:

App rule name: 'optoins bleed exploit'

App rule logic:  (analysis.session='garbled http options allow string' && service = 80 && action = 'options')

Alert on:  ioc

NOTE: This is custom content created by RSA Professional Services.  It is not officially supported by the RSA Content Team, so please use at your own risk.

options_bleed_apprule.nwr.zip

options_bleed.lua.zip

[JimWard]

Mitchell Hanks‌ Thanks for your contribution and collaboration to get this into RSA Live. 

The following content is available on RSA Live.

Parser:  HTTP_lua

Meta:  Service Analysis (analysis.service) = http invalid allow methods

Description:  The meta will be registered when "allow" and "access-control-allow-methods" headers contain characters other than letters, commas, asterisk, and spaces.

[CHADHEILIG]

If the functionality of the options_bleed.lua parser has been included in the HTTP_lua we don't need the options_bleed.parser. But the options_bleed_apprule triggered on analysis.session='garbled http options allow string' && service = 80 && action = 'options'.

I'm guessing I need to modify the rule to now trigger on analysis.session='http invalid allow methods'. And does the service and action meta still exist in the parsed values?

Alert still on 'ioc'?

Thanks.

[JimWard]

You don't need the app rule either. Just the HTTP_lua parser and pivot on

Meta:  Service Analysis (analysis.service) = http invalid allow methods

[CHADHEILIG]

That gives a lot of information to pivot on if you are in Investigation. But if we want to create an app rule, or esa rule to trigger on this traffic just the analysis.service meta doesn't have any use. Is there any additional specific meta that is triggered within the parser if a pcap of CVE-2017-9798 is pushed through?

[WilliamMotley1]

The capability as implemented in HTTP_lua is different than as implemented in the parser attached to the original post.  The parser in the original post matched many sessions, and the app rule was necessary to filter those down.

As implemented in HTTP_lua, the detection is significantly more specific.  It looks for HTTP "allow:" and "access-control-allow-methods" headers for the following conditions:

  leading comma    ,GET

  paired comma    GET,,POST

  non-alphanumeric(*, -, and spaces excepted)    GET,?

  doesn't contain at least one alphanumeric     ,   ,

  repetition    GET,POST,GET

If seen, then analysis.service meta "http invalid allow methods" is registered.

Of course that may or not indicate an attempt to specifically exploit the options bleed vulnerability.  Nor, if it was, that the attempt was successful.  Neither did the original parser / rule combination.  It simply means what it says, that invalid allow headers were seen - for whatever reason.

You could, if you wanted, filter that down to only those sessions in which the OPTIONS request method was used.  However you may miss some visibility since that request method may not be the only for which a server may include the header.  An invalid allow header may not be the result of an attempt to exploit the options bleed vulnerability via an options request, but it may still be interesting.

[CHADHEILIG]

I have some traffic being triggered on analysis.service = 'http invalid allow methods', but the 'access-control-allow-methods' are the following: Access-Control-Allow-Methods: * and nothing with an http response of Allow:
And then I have traffic being triggered with Allow: GET,HEAD,POST,OPTIONS,,HEAD and no Access-Control-Allow-Methods: in the http response.

The traffic with the Allow: GET,HEAD,POST,OPTIONS,,HEAD is from a pcap to trigger the CVE.

I'm guessing the Allow: GET,HEAD,POST,OPTIONS,,HEAD triggers the (doesn't contain at least one alphanumeric , ,) in the parser?

[WilliamMotley1]

"GET,HEAD,POST,OPTIONS,,HEAD"  would trigger due to the double comma between OPTIONS and HEAD.

A lone asterisk ("*") will trigger due to lack of an alphanumeric.  An exception should probably be carved out for that.

[WilliamMotley1]

To close the loop:  the latest version of HTTP_lua will not alert for a lone asterisk ("*").