So last Tuesday Microsoft announced MS15-034, a critical security bug in the HTTP.sys kernel driver impacting pretty much all versions of Windows; This meant anything using this driver instantly become vulnerable, including IIS 🙁

Whilst the article specified that this issue could allow an attacker to execute arbitrary code on a remote server, as of writing this no Proof of Concept exists. That said we do know how to bring a server to its knees by overflowing an Interger when sending a large Range HTTP header whilst making a request to an IIS web-server, generally resulting in a complete system lockup or blue-screen (bad!)

So for those of you who cannot patch immediately for what ever reason, but happen to have F5 LTM infrastructure, good news – you could potentially use the following to mitigate the onslaught of bots already scanning for this vulnerability / script kiddies attempting to break websites for the lulz.

To demonstrate the issue:

I wanted to see how hard it was to execute this vulnerability. I installed a fresh version of Windows Server 2012 Standard in a VM and proceed to add the IIS role.

The bug is exploitable if Output Caching  (Kernel Cache) is enabled on IIS (Which is by default).
Output caching makes web pages tremendously responsive during the round-trip to the server. When a user requests a particular page, the web server returns it to the client browser and stores a copy of that processed web page in the memory on the web server and returns it to the client in subsequent requests for that same content, which eliminates the need to reprocess that page in the future.

If we fire up WGET/Curl (prob could be done in Powershell using Invoke-Webrequest too if you wanted) and request the image that shows up on IIS8’s ‘Welcome’ page with a HTTP Range header with a large value we will recieve a blue-screen (took me 3 tries to get the result with Curl)

i.e.

wget --header="Range: bytes=18-18446744073709551615" http://192.168.1.129/iis-85.png

or

curl -v 192.168.1.129/iis-85.png -H "Range: bytes=18-18446744073709551615"

To mitigate the Vuln:

To Mitigate the vulnerability go ahead and add the below iRule to your F5 device and add it near the top of your list of rules on Virtual Servers that are balancing Windows Server web-servers.(This requires a HTTP profile enabled for the virtual server as we’re at layer7):

##############################################
# Patrick S - 16/04/15
# This iRule will drop the "RANGE" header if it contains a LONG range value to
# mitigate the effects of https://technet.microsoft.com/library/security/MS15-034
##############################################
when HTTP_REQUEST {

set vip [IP::local_addr]:[TCP::local_port]

if { ([HTTP::header exists "Range"]) } {
# If the range Matches REGEX log the result, return a 400 (patched) and then drop the socket.
    if { ([HTTP::header exists "Range"]) and ([HTTP::header "Range"] matches_regex {bytes\s*=.*([0-9]){10,}.*})} {
        log local0. "Potential MS15-034 Exploitation Attempt to [HTTP::host] in uri [HTTP::uri] from [IP::client_addr] on VIP $vip"
        HTTP::respond 400
        drop
        }
    }
}

Note the Regular expression in the above on Line 12. This is based off an iRule written by the community for the F5 ASM. It will prevent someone sending in range requests longer than 10 bytes in length. and can be tested by one of the best online REGEX testers on the net: (https://regex101.com)

The above REGEX also supports other (less-known) supported scenarios mentioned here:

1. Range requests with white-space (i.e. Range: bytes = 2 – 18446744073709551615)
2. Range requests with leading-zeros (i.e. Range: bytes=2-018446744073709551615)
3. Range requests that contain Multiple range requests (i.e. Range: bytes=2-3,4-18446744073709551615)

Good luck, let me know if you have any questions… and…

Patch now!!!

The above should only be a stop-gap, patch this problem as soon as possible, or you’re gonna have a bad day!

Download Patches: https://technet.microsoft.com/en-us/library/security/ms15-034.aspx
Further Reading on KB3042553: https://support.microsoft.com/en-us/kb/3042553
Potential Work-around (if you dont care about performance): https://technet.microsoft.com/en-us/library/security/ms15-034.aspx#ID0EHIAC

-Patrick