XSSF: Expanding the Attack Surface of XSS

…as if we need another example of why XSS is dangerous…
If you’re not using the XSS Framework (XSSF), then you should be.
XSSF is written by Ludovic Courgnaud (CONIX Security) and is described as “a security tool designed to turn the XSS vulnerability exploitation task into a much easier work. The XSSF project aims to demonstrate the real dangers of XSS vulnerabilities, vulgarizing their exploitation.” Immediately, you should be thinking BeEF. XSSF is similar to BeEF in how it injects itself into the victim web browser and creates a communication channel to the attacker, but it has some distinct advantages. The largest of these advantages being that it is built on top of the Metasploit Framework (MSF). While BeEF requires the complete development of custom exploits or the addition of a BeEF <-> MSF interface (note the recent addition of MSF browser_autopwn to BeEF), XSSF is designed to use existing MSF browser exploits and modules natively. This is scalable, convenient, and as a result, XSSF inherits a large community of developers. XSSF is written in Ruby and is quite stable. I have been playing with it and using it on assessments and have yet to encounter a crash or bug. It just works. In fact, I’ve tried some stuff that I fully expected to break the framework, yet worked perfectly. Like BeEF, XSSF comes prepackaged with built-in auxiliary modules which are tailored specifically for leveraging browser-side functionality. Some of these are POCs still in development, but the POCs work, and with some slight tweaking, can become real world usable modules.
The only issue I’ve encountered with XSSF to date is the fact that XSSF is not a part of the MSF svn trunk. Because of this, if you svn checkout XSSF on top of MSF, as the instructions say, you will break the ability to update either framework. I submitted the issue to Ludovic, and his recommendation was to maintain the integrity of the MSF svn system by using the svn export command for the XSSF trunk which will update all XSSF core files and leave out the svn files. This could possibly leave artifacts if XSSF files are removed from the trunk at a later date, but until MSF includes XSSF in their official trunk, this is what we’re left with. A small sacrifice for such great benefits.
Okay, that’s a brief overview of XSSF. Now on to what motivated me to write this blog post.
This afternoon I was demoing XSSF for some of my students. I was loading up existing MSF modules such as the signed java applet browser exploit and popping meterpreter shells on fully patched Windows 7 boxes with fully patched browsers. While this was making the desired impact, I wanted to show the students how I could further leverage XSSF to expand the attack surface. I came up with the following scenario.
The scenario:
An attacker is external to a corporate network via a standard security stack (firewall, IDS, border router, etc.). Within the corporate network are employees which have outbound access to the internet. Also within the corporate network is an intranet web server that is only available to internal network users. NOT public facing. The objective of the attacker is shell access to the intranet web server.

The attack:
Through open source research and social engineering, the attacker is able to figure out that the organization is running a web app on their intranet web server that is vulnerable to remote command execution. Here is what the attack looks like.

Step one, hook an internal victim browser via XSS.

Step two, use xssf_tunnel or other module (visited_pages) to see that the user has access to the internal web server. Also, during this step, the attacker notes the ip or hostname of the internal web server and application.
Step three, the attacker starts a listener to accept inbound connections on his attack machine and uses the xssf_csrf module to send a remote command execution payload to the vulnerable web app. The RCE payload will call back to the attacker’s machine using a technique such as those found here.

Step four, the attacker receives the connection from the intranet web server and pilfers target data. At this point, the browser hook is no longer needed. If the victim kills the XSSF session by closing their browser, it does not effect the rest of the attack. The attacker is connected directly to the web server.

The conclusion is two-fold, XSSF kicks ass and XSS will still eat your lunch. Patch your boxes, actively monitor your systems, and educate your users.