Several detection rules (SNORT, F5, …) are being published these days to detect exploitation of vulnerability MS15-034.

If you are making or modifying such detection rules, I want to share some observations with you.

MS15-034 can be exploited with a GET request with a specially crafted Range header.

Here is the example we’ll use: Range: bytes=2-18446744073709551615

Referring to RFC 2616 section 14.35.1, you can see that this is not the only way to specify a range. Here is the BNF:

ranges-specifier = byte-ranges-specifier
byte-ranges-specifier = bytes-unit “=” byte-range-set
byte-range-set  = 1#( byte-range-spec | suffix-byte-range-spec )
byte-range-spec = first-byte-pos “-” [last-byte-pos]
first-byte-pos  = 1*DIGIT
last-byte-pos   = 1*DIGIT

suffix-byte-range-spec = “-” suffix-length
suffix-length = 1*DIGIT

First of all, whitespace is allowed. So Range: bytes = 2 – 18446744073709551615 is valid (and also caused a BSOD on my test machine).

Second, numbers can have leading zeroes. So Range: bytes=2-018446744073709551615 is valid (and also caused a BSOD on my test machine).

Third, multiple ranges are allowed. So Range: bytes=2-3,4-18446744073709551615 is valid (this did not cause a BSOD on my test machine).

If you are using rules that don’t detect these cases properly, then attackers can easily evade detection. One space character could be all it takes to evade detection. If the rule looks for string “-18446744073709551615″, then using string “- 18446744073709551615″ in the attack (extra space character added) will evade detection.