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

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

Thanks, that's what I was thinking as well...off to patch all the things...sigh

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

Once the patch is installed, you'll get a 400 instead of a 416.

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

Check the first lines that start with the less-than symbol that is followed by:

HTTP/1.1 416 Requested Range Not Satisfiable

NOTE: as Robert Graham points out in http://blog.erratasec.com/2015/04/masscanning-for-ms15-034.html , this check is not guaranteed to work, as IIS servers may return all kinds of other codes even if vulnerable.

Possibly pointing to a known static resource on the server may provide more reliable results, as in:

curl -v -r 0-18446744073709551615 http://www.example.com/Welcome.png

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

Check the first lines that start with the less-than symbol that is followed by:

HTTP/1.1 416 Requested Range Not Satisfiable

NOTE: as Robert Graham points out in http://blog.erratasec.com/2015/04/masscanning-for-ms15-034.html , this check is not guaranteed to work, as IIS servers may return all kinds of other codes even if vulnerable.

Possibly pointing to a known static resource on the server may provide more reliable results, as in:

curl -v -r 0-18446744073709551615 http://www.example.com/Welcome.png

Here is exploit code in powershell

$httprequest=[system.Net.HTTPWEbRequest]::Create("http://www.yourcompany.com/favicon.ico")
[System.Net.WebHeaderCollection].GetMethod("AddWithoutValidate",36).Invoke( $httprequest.Headers, @("Range", "bytes=18-18446744073709551615"))
$response = $httprequest.GetResponse();

Information disclosure PoC doesn't need > 4GB file : https://twitter.com/julianor/status/588471579186700288

Quoting Anonymous:Information disclosure PoC doesn't need > 4GB file : https://twitter.com/julianor/status/588471579186700288

What does it disclose? What is cached is static files and those are already in public to look at contents.

Attacker can get 1) content from files he doesn't even know the name or folder or he doesn't have permission to access. 2) Kernel memory addresses to make remote code execution easier (no bruteforce, no reboot, protection bypass)

Would be nice if, when the threat level went yellow or red, we could use the api to get a summary reason why.

thanks,

Colum

The 0xffffffffffffffff value presumably needed to exploit this bug is, as some have pointed out here, NOT the biggest "int64", but it IS the biggest "uint64." In int64-land, 0xffffffffffffffff is actually -1.

And this may well be the mechanics of the bug: a signed/unsigned mismatch in the code parsing the end byte value of the Range header, combined with insufficient sanity checking, would cause the HTTP kernel driver (I'm asuming that's what http.sys really is, not a mere "HTTP library") to run off the end of a kernel heap segment when trying to satisfy the request, potentially panicking the system (and at the very least throwing a paging-related exception).

This would be a true "bozo bug," seemingly unworthy of being found in a Windows Server kernel-mode driver. But in my experience NOBODY uses unsigned ints when they should, so this sort of "bozo bug" happens a lot. If this is indeed what happened, somebody at MS needs to eat some crow for it.

I don't run any Windows boxen so I can't test this myself; but it seems to me that you might still be able to create a PoC GET using powershell, by making the end-byte arg "[long] -1". Or, if powershell actually supports all the datatypes (as it should, though I wouldn't bet on it), you might be able to use something like "[unsigned long] 18446744073709551615".

> What does it disclose?

My guess is that it could disclose EVERYTHING in the segment of kernel heap following the end of the data it's supposedly limited to. This might include a lot of things that aren't cached data. It might also include cached protected data (stuff the server wouldn't otherwise give you without authentication). In this sense it would be a lot like Heartbleed, but including a DoS as the cherry on top.

Issue is that HTTPWebRequest class Method AddRange() does not allow anything about Int64 (long), so [ulong] will fail. You need to use private method I mentioned couple of posts above to successfully exploit via powershell.

https://msdn.microsoft.com/en-us/library/system.net.httpwebrequest_methods(v=vs.110).aspx

I have a stupid question: does this bug only affect sites with Anonymous Authentication enabled? Alternatively, does authentication not ameliorate this vulnerability one bit?

Thank you.

I found that my W2K12R2 server "wasn't vulnerable" but, I think that was because OWA was installed. I set up another site on a different port on the same server, tried the POC code and "boom" - blue screen. Having authentication turned on also seems to having some mitigating effect.

Note that I'm intentionally being a bit non-committal here - I didn't try too hard to get the IIS on OWA to crash so maybe something else could be tweaked to make it crash. Also, the authentication issue is something that "seemed" to hold true. BTW, my OWA is in a separate directory and the default page does show the iis-85.png file without authentication.

Quoting mcsatordor:I have a stupid question: does this bug only affect sites with Anonymous Authentication enabled? Alternatively, does authentication not ameliorate this vulnerability one bit?

Thank you.

It's not going to be affected since kernel does not cache any resources served with authentication.

Quick and dirty HTTP.sys scanner written in python.
https://github.com/JeremyNGalloway/http.sys

You can see if anything cached in kernel in IIS via command "netsh http show cachestate"

PS C:\Windows\system32> netsh http show cachestate

Snapshot of HTTP response cache:
--------------------------------

URL: http://www.company.com:80/schema/advertise.xs
Status code: 200
HTTP verb: GET
Cache policy type: User invalidates
Creation time: 2015.3.16:14.36.9:0
Request queue name: www.company.com
Content type: text/xml
Content encoding: (null)
Headers length: 197
Content length: 5061
Hit count: 5
Force disconnect after serving: FALSE

Quoting GregorySuvalian:

Quoting mcsatordor:I have a stupid question: does this bug only affect sites with Anonymous Authentication enabled? Alternatively, does authentication not ameliorate this vulnerability one bit?

Thank you.

It's not going to be affected since kernel does not cache any resources served with authentication.

Thank you GregorySuvalian. Since I'm somewhat of a Windows security n00b, I'd like to make sure I understand your answer by restating it back to you; if you could confirm that I understand you correctly, then I would be most obliged.

If I understand you correctly, then if I disable anonymous authentication on a site and use (for example) ASP.NET authentication, then an HTTP request to that site will not get cached by HTTP.SYS, and so the "Range:" header is essentially harmless.

Correct?

Thanks again!

https://twitter.com/Lee_Holmes/status/588464652708806656

"MS015-034 vulnerability requires that services use Kernel Mode Caching in http.sys. WinRM and PowerShell Remoting do not."

My Windows 2012 IIS server hard-crashed and rebooted with a simple python script. I blogged about it. Scary! http://neonprimetime.blogspot.com/2015/04/crash-13-of-internet-with-ms15-034.html