IIS Exploit can reboot your Windows Server; install patch KB3042553 ASAP
This week Microsoft release a patch for Windows 7/Windows Server 2008 R2 and up that fixed a critical remote execution bug, see MS15-034 and CVE-2015-1635 for more info. Unfortunately the patch was reversed engineered and now an exploit is available. This was detected and described by ISC SANS. They added Denial of Service (DoS) as possible impact, next to Remote Code Execution.
As it turns out, the DoS in question actually causes a Blue Screen of Death (BSoD, also known as bugcheck) on affected servers. And disturbingly it's very easy to do. It makes no difference if the server is using HTTP or HTTPS. To check whether your servers are affected you can use wget or cURL. An example is show below for both HTTP (from ISC SANS) and HTTPS:
HTTP curl -v http://server.contoso.com/iisstart.htm -H "Host: test" -H "Range: bytes=0-18446744073709551615"
HTTPS curl -k -v https://server.contoso.com/iisstart.htm -H "Host: test" -H "Range: bytes=0-18446744073709551615"
If you are affected, you will see an "HTTP 416 The requested rance is not satisfiable" error:
The response "HTTP 416 The requested rance is not satisfiable" means the server is affected.
Do note that in this case iisstart.htm is used as a static file, but any other static file is valid so removing this file doesn't help you much. For those who are worried AutoDiscover might be a target (as the request is most of the time https://autodiscover.contoso.com/AutoDiscover/AutoDiscover.xml), that URL requires authentication and that seems to prevent the issue:
Autodiscover requires authentication, which seems to block this specific issue.
Changing the range from 0-18446744073709551615 to 20-18446744073709551615 will reboot the server.
Disclaimer: Use at your own risk, be careful when you do this. Do not perform this on production servers and only in lab environments.
I haven't been able to reproduce this on Exchange servers, but I did perform this on a server with IIS without SSL. Perhaps my cURL syntax isn't completely correct in order to let it crash, but enough to check vulnerability. See this YouTube video demonstrating a server BSOD:
Unfortunately IIS filtering doesn't help you here and having your servers behind a load balancer (or firewall) won't help you either. I'm obviously thinking about Exchange that is frequently published via a load balancer and not a Reverse Proxy (with ISP). Multiple servers behind a load balancer are not a solution, an attacker can issue the command easily multiple times. So, if your load balancers redirects traffic to another server, that one can be affected as well. As most Exchange servers are multi-role and part of a Database Availability Group (DAG), you can see how this could affect more than just client access availability. Or if you have Exchange Edge Transport servers, that would impact you mailflow.
What can you do?
- Best solution is to install Microsoft patch KB3042553 on (at least) all internet facing servers that are affected.
- That can take a while if you have a lot of servers and downtime is expected.
- Filter out malicious header requests in your reverse proxy, load balancers or other (IPS) solution.
- Disable IIS kernel caching.
- This can cause performance issues and a short downtime is expected.
- It doesn't seem to work on objects that require authentication.
- Not possible to hide everything behind authentication, for instance the Exchange OWA Form Based Authentication logon screen requires no credentials to load. And it's always possible somebody knows valid credentials they could use.
You can download cURL for Windows here.
Thank you to Raymond Comvalius, SanderV and others providing me with information regarding this specific issue.