Many web applications will attempt sanitize user input to avoid cross-site scripting. A very common example of this is in message boards where users are allowed to use a subset of HTML, but the administrators would still like to prevent malicious <script> tags. In many cases, it is possible to use the application's own sanitation routines against itself to inject an attack.

A recombination attack is able to subvert such sanitation by breaking up the attack string with content we know will be stripped. For example, if an attacker wishes to inject the classic <script>alert('xss')</script> attack but all <script> tags are blocked, they could attempt the following:

<scr<script>ipt>alert(0)</scr<script>ipt>

In the example above, the sanitation routine would identify the full <script> tags and strip them from the content. Assuming the application does not perform a secondary run of the routine, the end result is the desired code being injected into the site.

There are several ways to mitigate such attacks.

1. Sanitize all input by converting all greater-than and less-than signs into their respective HTML entity codes. This won't work if you need to allow users to submit a subset of raw HTML, so...
2. Avoid letting users submit HTML. Use another type of markup such as BBCode to allow users indirectly produce HTML formated messages.
3. If you absolutely must allow HTML, perform multiple sanitation runs. If you only run it a set number of times (x), then an attacker only needs to perform x+1 recombination attacks, therefore keep sanitizing until the input comes out clean. Since this may lead to a potential DoS depending on how expensive the sanitation routine is, you may want to simply abort the message if it comes up dirty.

I'd like to thank David King for adding me as a maintainer for the NessusLibs project on RubyForge. David hasn't had much of a chance to work on the project, so its remained stagnant for the past few years. I've got a few patches I'll be adding to the code base this weekend to clean up a few things. Additionally, I've been working on a greenfield implementation of the Nessus Transfer Protocol client which I will kick off as a version 2 of NessusLibs?.

Thanks to the suggestion from Paul of PaulDotCom, I've gone ahead and updated the screenshot Meterpreter script to ScreenCap, which does pretty much the same thing, except with a video of the remote console. This is just a proof of concept, and does not do the key-stroke capture that was part of the suggestion. Much like screenshot, ScreenCap will create files based on the Unix epoch date of when the script is run. The captured video will be zipped and dropped off in the logs directory for MSF. All remote files should be cleaned up. I've found the videos to compress very well.

I've split some of the basic functions off in to a library I'm currently calling MS(f)hell (Meterpreter Scripting HELper Library). The name will likely change in the future. I've got some real basic functionality in the library: upload, download, executeRemote and zipFile. This mostly just wraps the native API, but adds built in verbosity for detailed reporting of activity. It also makes the new ScreenCap script only 15 lines or so.

In order to use ScreenCap, you need to have the open-source command line driven screen capture program camstudio-cl. Place the camstudio-cl.exe binary in your Metasploit data directory. You also require both screencap.rb and msfhell.rb in your Meterpreter scripts directory. Amazingly, camstudio-cl is actually smaller than the stock boxcutter executable used in screenshot.

Where I'd like to go with MS(f)hell is to have it provide some automatic clean up. By keeping track of created files, it could perform some post-exploit maintenance to make sure the system is restored to its original condition. I'd also like to add more VBS functions for performing activities that are monotonous on the command line. I don't want to have any real complex functionality in the library, just basic reusable components for other scripts.

screencap

MSFhell

I was happy with my screenshot script, but a disappointed in the size of boxcutter. Nothing against the little app, it does a good job for what its meant to do. I just needed to strip it down a bit.

The basic functionality that I require is to save a screenshot to a named file, so I removed all the code for option handling, copy to clipboard, and manual selection of snapshot area. I also removed all of the Windows form code and calls. The original version would pop up a window for a split second, but that was just too long for me. Finally, I stripped out all the console interaction code, including error messages. BCLite will exit with either a 0 (worked) or a 1 (failed).

I'll be creating a Trac instance to manage a SVN repository for code on this site in the near future. In the mean time, you can get BCLite directly.

BClite

I worked on a new Meterpreter script that has a couple interesting features. The main purpose of the script is to take a screenshot of the target. This is handled by uploading and executing boxcutter, a GPL'd command line screenshot utility. The script will then automatically generate a VBscript for building a Zip file and adding the screenshot to it. This was necessary because the uncompressed screenshots can take a while to transfer.

I used Darkoperator's memdump script as the starting point for screenshot. I adjusted the name of the created files so they are the datestamp when the script was run rather than a random integer. This gives a bit more information and makes the results sortable. I also added the Zip routine.

Pretty basic stuff, but it has a nice result.

screenshot

I will be leading a SANS Mentor program for SEC 560: Network Penetration Testing and Ethical Hacking, beginning October 6, 2009. The program consists of self-study and ten 2-hour weekly sessions. Taking the week of Thanksgiving off, the sessions will finish up on December 15.

The 560 course provides a lot of hands on activities that cover the whole penetration testing process. We'll cover some of the business aspects in regards to defining project scope, legal and operational restraints, and tester-client interactions. Much of the material involves the technical aspects of penetration testing. Reconnaissance, scanning and exploitation are covered in addition to wireless testing and a large section on password attacks. The full last day of the conference version of 560 included a competitive capture-the-flag competition. I'm not sure just how this will be handled in the mentor version, but I hope to provide a comparable event.

I originally took 560 at SANS Toronto 2008. Dave Shackleford taught that class, and my goal is to channel at least a bit of the energy and excitement that he brought to the presentation. If you ever get the chance to take a class with Dave, jump at the opportunity. He is a fun guy who will keep you motivated through the long days.

The sessions will be held at my employer's training facilities in Brookfield, Wisconsin. The office is about 15 minutes out of Milwaukee and 45 minutes from Madison. I'd like to encourage anyone from the Southeast Wisconsin interested in participating in this course to check out the SANS Mentor website and contact my office at (262) 373.7100.

I had the privilege to give a guest presentation to Mark's class last evening. A great group of students who were very engaging and managed to stay interested though the dry parts of my PowerPoint! Thanks for the pizza and great conversation. Sorry about the technical hiccups with the Capture the Flag network, I'll make sure to improve on its functionality and add a lot more objectives in the future.

If anyone wants them, I've uploaded (most of) the slides from my presentation. You'll find them attached to this post.

ethackal is a new site focused on ethical hacking, penetration testing, and security research. ethackal is run by John Miller, an information security professional who works daily with penetration testing and vulnerability assessments. I will be carving ethackal into my personal niche in the Internet, posting my comments on the latest infosec news and articles on topics I find interesting enough to write about.

While I do intend to be the primary commentator and author of this site, I leave open the possibility of inviting others to submit articles and news postings. It is far too early in the life of ethackal to tell just what will happen. If you would like to help out with generating content for this site, please use the contact form to get in touch.

The name ethackal is a portmanteau of 'ethical' and 'hack', and pronounced 'ethical'. Some people shy away from the terms 'hack' and 'hacker' due to the stigma placed on them in the past decades. I have long associated hackers not with criminal activity, but with a curious nature and desire to understand and manipulate complex systems. This is the type of hacking referred to in ethackal. Criminals use many different means of plying their trade, sometimes involving technical exploits. It is not the methods they use that make criminals criminal, but their motives and the results of their actions. Ethical hacking is the legitimate use of these technologies and skills to perform legal and constructive assessments of security implementations.