Thanks, that's what I was thinking as well...off to patch all the things...sigh
|
JeffPatton 2 Posts |
Quote |
Apr 16th 2015 5 years ago |
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. |
Jaybone 27 Posts |
Quote |
Apr 16th 2015 5 years ago |
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 |
Erik van Straten 126 Posts |
Quote |
Apr 16th 2015 5 years ago |
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 |
Erik van Straten 126 Posts |
Quote |
Apr 16th 2015 5 years ago |
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(); |
GregorySuvalian 9 Posts |
Quote |
Apr 16th 2015 5 years ago |
Information disclosure PoC doesn't need > 4GB file : https://twitter.com/julianor/status/588471579186700288
|
GregorySuvalian 2 Posts |
Quote |
Apr 16th 2015 5 years ago |
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. |
GregorySuvalian 9 Posts |
Quote |
Apr 16th 2015 5 years ago |
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)
|
GregorySuvalian 2 Posts |
Quote |
Apr 16th 2015 5 years ago |
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 |
ColumPaget 2 Posts |
Quote |
Apr 16th 2015 5 years ago |
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". |
whurlitzer 13 Posts |
Quote |
Apr 16th 2015 5 years ago |
> 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. |
whurlitzer 13 Posts |
Quote |
Apr 16th 2015 5 years ago |
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 |
GregorySuvalian 9 Posts |
Quote |
Apr 16th 2015 5 years ago |
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. |
mcsatordor 2 Posts |
Quote |
Apr 16th 2015 5 years ago |
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. |
mcsatordor 1 Posts |
Quote |
Apr 16th 2015 5 years ago |
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? It's not going to be affected since kernel does not cache any resources served with authentication. |
GregorySuvalian 9 Posts |
Quote |
Apr 16th 2015 5 years ago |
Quick and dirty HTTP.sys scanner written in python.
https://github.com/JeremyNGalloway/http.sys |
GregorySuvalian 1 Posts |
Quote |
Apr 16th 2015 5 years ago |
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 |
GregorySuvalian 9 Posts |
Quote |
Apr 16th 2015 5 years ago |
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 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! |
mcsatordor 2 Posts |
Quote |
Apr 16th 2015 5 years ago |
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." |
JoeGasper 1 Posts |
Quote |
Apr 17th 2015 5 years ago |
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
|
JoeGasper 12 Posts |
Quote |
Apr 17th 2015 5 years ago |
Sign Up for Free or Log In to start participating in the conversation!