Live data from Hacker News

Remote Kernel Code Execution Via HTTP Request In IIS On Windows

ma.ttias.be

81–90 of 201 posts

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

#81
post #68

Earlier quoted context omitted.

I have tried this with kernel caching enabled. (kernel caching IS enabled by default from what I can see). Still unable to reproduce using curl.

Even if you have Kernel Caching enabled (as it is by default) if you haven't created any rule for it you're safe. I created a rule to cache all .png files and I changed the curl request to request a .png image on the server. I got a BSOD!

Do you remember what the fault being reported on the BSOD was?

(If you could take a screenshot/snapshot that'd be great.)

I'm really curious to see what bugcheck is being hit.

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

#82
post #37
post #25

Earlier quoted context omitted.

I actually don't because I have no clue how Windows Server works. So this attack hits the kernel and the context is low level, right?

Not sure if I am not clear enough but yes, it 'hits the kernel and the context is low level'. As low as it can get on Windows.

[deleted]

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

#83
post #65
post #11

Earlier quoted context omitted.

It would allow the same privileges as the user which is running IIS, usually a "system" account - which equals Administrative privileges.

SYSTEM account is far more powerful than Administrator, especially after Win2008

This page makes it sound easy to go from the one to the other:

http://blogs.technet.com/b/askds/archive/2008/10/22/getting-...

(not as easy as earlier versions, but still)

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

#84
post #48

Earlier quoted context omitted.

If you don't have the kernel caching enabled, does this vulnerability still work?

According to microsoft's bulletin disabling kernel caching will avoid the vulnerability. * I should cite this : https://technet.microsoft.com/library/security/ms15-034 See section Vulnerability Information > Workarounds

Microsoft states that this MAY help.

I don't have a MS server with IIS installed, but I would be very interested if the exploit check from the OP would be negative with kernel caching disabled. Anyone care to test this?

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

#85
post #7

>A remote code execution vulnerability exists in the HTTP protocol stack [...] could execute arbitrary code in the context of the System account. SYSTEM is higher than admin. Using IIS on windows is like running a webserver as root on linux.

Lets not play the "my team is better than your team" hysterics, especially when we all had to do emergency patching for shellshock, heartbleed, samba, drupal, etc in the past couple months. Hell, sambra runs as root and that doesn't seem to outrage anyone.

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

#86
post #68

Earlier quoted context omitted.

I have tried this with kernel caching enabled. (kernel caching IS enabled by default from what I can see). Still unable to reproduce using curl.

Even if you have Kernel Caching enabled (as it is by default) if you haven't created any rule for it you're safe. I created a rule to cache all .png files and I changed the curl request to request a .png image on the server. I got a BSOD!

I second that.. If you could provide a screenshot and Curl example it would be great.

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

#87
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…

I can confirm what Khao is saying from my own testing.

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

#88
post #80
post #68

Earlier quoted context omitted.

Even if you have Kernel Caching enabled (as it is by default) if you haven't created any rule for it you're safe. I created a rule to cache all .png files and I changed the curl request to request a .png image on the server. I got a BSOD!

Can you please provide example of CURL syntax you used to produce this please?

Specifically after enabling Output Caching for all .png files I send this :

curl -v http://example.com/image.png -H "Range: bytes=18-18446744073709551615"

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

#89
post #18

Earlier quoted context omitted.

> webserver component running inside the kernel (yea right, great idea!) Actually an idea shared among many OS, including GNU/Linux. http://en.wikipedia.org/wiki/In-kernel_web_server

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.

I fully agree that the idea doesn't make sense, specially when coupled with memory unsafe languages.

Just wanted to make the point it isn't a Windows specific idea.

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

#90
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…

I can confirm what Khao is saying from my own testing.

Do you happen to have a screenshot of the BSOD, or could test it a second time to take a screenshot? I don't really have a free test server that I can crash anymore since I tested this morning when not a lot of people were at the office yet.
Post reply on HN