Using iRules to mitigate Microsoft's MS15-034 / CVE-2015-1635 Range vulnerability

[Tom_Spector_50]

As more information becomes available regarding the recently published Range vulnerability affecting Microsoft platforms (see MS15-034and CVE-2015-1635), you can start mitigating this issue for your backend applications using the following iRule that would remove the Range header when large ranges are detected.

Additonal mitigations have been published:

• Using ASM - https://devcentral.f5.com/s/articles/mitigating-httpsys-remote-code-execution-cve-2015-1635
• Using LineRate - https://devcentral.f5.com/s/articles/linerate-range-header-attack-mitigation

Please be sure to test this thoroughly in your production environment. 

##############################################

# Name: stop_range_CVE-2015-1635

# Description: This iRule will remove the Range header when detecting large ranges in it.

##############################################

when HTTP_REQUEST {

# remove Range requests for CVE-2015-1635 if the request uses large ranges

if { ([HTTP::header exists "Range"]) and ([HTTP::header "Range"] matches_regex {bytes\s*=.*([0-9]){10,}.*})}

{

HTTP::header remove Range

}

}

[MW1]

The above would only detect if the range header is an exact match regarding upper and lower case. Should it not be first switching it all to lower ?

[Raymond_76056]

Http:header is not case sensitive. There is an example script from Hoolio on devcentral

[jba3126]

What versions of code supports this iRule? I'm asking because I'm getting the following: Bad Characters. Only the following special characters are allowed: period, asterisk, forward slash, dash, colon, underscore, question mark, equals, at sign, comma, ampersand and space (.*/-:_?=@,& Also @Raymond, can you provide a link to the iRule Hoolio wrote?

[Tom_Spector_50]

The iRule is already case insensitive as noted in the HTTP::header syntax page: "The header name is not case sensitive, so for example, 'HTTP::header value HEADER_NAME' will match a header with the name HeAdEr_NaMe."

[El-Guapo_29797]

Hoolio: what version of F5 does this affect? If using SNAT, the header should not be passed from source to backend server. Thank you.

[Nathan_Fowler_1]

Interesting

[Nathan_Fowler_1]

I am unable to post detailed content, however, I propose an alternative iRule which is more strictly fixated on MS15-034, does not false positive, and matches all known evasion techniques for RFC 2616 section 14.35. Please see meow://pastebin.com/BV2uePxk

[Nathan_Fowler_1]

An updated version of the iRule I've created that more accurately addresses the core vulnerability has been released to address evasion techniques such as "Range: bytes=0-200,201-18446744073709551615" meow://pastebin.com/3MAEE2Fq

[IainThomson85_1]

Having read article http://blog.didierstevens.com/2015/04/17/ms15-034-detection-some-observations/ I'm curious to know if the RegEx that has been supplied will mitigate some of the other exploits in the Range field (Counting Whitespaces etc)

[Nathan_Fowler_1]

I worked with Didier (we're in the same vertical) and the iRule at meow://pastebin.com/3MAEE2Fq will handle those evasions. The RegEx/PCRE supplied in the original iRule on this article will also match, however, the nomenclature isn't quite accurate. While the iRule will match MS15-034 due to the length of the 0xFFF... value in itself it is not precise and will fire on any byte range that is ten digits or more. It's quite aggressive and prone to false positives. The one supplied at meow://pastebin.com/3MAEE2Fq will only match on MS15-034 and has been production tested at $dayjob with the exploit and the evasions identified by Didier.

[Sam_Richman_263]

El-Guapo, this vulnerability does not affect F5 software. This iRule is designed to protect back-end Windows servers against this attack. In addition, SNAT is a layer 3 construct and has no effect on HTTP headers.