The Web Exploitation Framework (wXf) Project

Local web security expert and blogger Ken “@cktricky” Johnson put together this nice little article for us. You may remember Ken from one of our first NovaInfosec D-List posts a few weeks back. In that interview he mentioned the Web Exploitation Framework (wXf) project he’s been working on. Now he’s back for an in-depth look into this project and a major milestone they’ve just reached. And without further ado, here’s Ken…

(Note: As part of a campaign to bring forward some of our older posts that we feel still benefit the community, we’ve added this article to our Best Of category that will periodically get tweeted out. Please mention it to me on Twitter or contact us if there are any other posts you feel we should include in this category. This post was previously categorized under Infosec Blogs/Podcasts. -@grecs)

#####

In January of 2010, Seth Law and I had a conversation about using tools for our everyday testing and exploitation. Which tools we prefer, those we do not and those that are no longer maintained. We discovered we both had the same problems with our tool-set, or maintaining it rather. These problems included locating, using, setting the environment for and also, leveraging software that is no longer supported.

In addition to these challenges, we weren’t seeing a ton of real world compromises as a result of using the tools available via existing application security frameworks. Not to detract from their developers’ efforts. These are folks that dedicate their time to providing free code and this is greatly appreciated by the security community.

So we began creating a new project, a framework, called the Web Exploitation Framework or wXf. The first thing we had to do was create an interface in which a user could interact with. To do so, we modeled wXfconsole after Metasploit’s msfconsole. Much of the core commands remain the same, e.g., use, show, help, set, exit.

Next, we needed a very flexible HTTP library. We chose a popular library amongst both Rubyists and web pen-testers called Mechanize. The idea was to keep the version of Mechanize standard across all distributions of the framework. The best way to do this was include the Gem inside of the framework. Additionally, we are working on including other Web 2.0 specific libraries into the framework. A good example of this is the Savon Gem. This Gem has been included into the framework and like Mechanize, Savon has an assist module which lessen the amount of coding a module developer must perform when interacting with this library.

Also, we needed to cover some of the basics of an exploitation framework. Among these conventions is the need to be extensible. If folks are going to contribute, how so? The solution was to follow two general guidelines:

1. Use something fast and lightweight for simple request/response sequences. We chose SQLite3.
2. Ensure folks who are used to contributing to pen-test frameworks won’t have to re-learn module development. Again, we chose to model a portion of the framework after MSF. Module development between the two is extremely similar.

While extensibility is the principle factor in creating any framework, for a webapp exploitation framework there are other fundamentals we have to cover. Traditional exploits like Remote File Inclusion (RFI), Directory Traversal and SQL Injection (SQLi) have to work and must be included. Currently, we support PHP RFI exploitation but are working on this for other languages. Once we’ve supported some of the primary languages and this is stable, we will add a large list of popular and well-known RFI exploits. SQLi–based exploitation is an on-going child process and has yet to be released into the beta version of wXf.

To further assist the users, we’ve created various methods for logging traffic. For example, wXf has a logger devoted to exporting into an xml format created specifically for the Dradis Framework. In the latest release of Dradis, a wXf upload plugin has been included so that you can import xml files created by wXf. This works well for viewing large numbers of requests and responses and analyzing the particulars.

A lot of time has been spent addressing various bugs, the core components, UI style, and features. Frankly we’ve re-written the framework several times over until we were comfortable with releasing. For now, from a user perspective, wXf probably wouldn’t be something you would use everyday. In 2010 we were focused on getting the framework foundation laid out. Now we are focusing on improving on what it can do. Seth and I expect 2011 will be a huge leap forward in terms of features and modules.

As mentioned, we are working on the features that are unique to wXf. Some of these features are in development. Others are mainly results of brainstorming sessions and purely theoretical. Until we know for sure that these features are going to be released into production code, we’ve chosen not to discuss them. This is in an effort not to disappoint the user(s).

Generally speaking though, in terms of features, we will focus on other aspects beyond just exploitation. Examples include tools for app security testing as well as a graphical interface to tie all of this together. We believe some things are best left to a GUI environment. Furthermore, appsec testing can be rather difficult for a user with a console-style interface so it is a high priority to build a wXf GUI.

Lastly, documentation, documentation, documentation! We’ve moved the wXf code onto GitHub. GH provides an excellent wiki editing interface and we are continually updating or adding pages to that wiki. We encourage those folks who would like to contribute in the form of documentation or code to contact us. Specifically, the wiki is extremely important and needs writer contributions.

wXf core developers can be contacted mainly through @wXframework on Twitter. Also important to note, when production ready code or wiki updates have been pushed, we send out these notifications via Twitter. In the future, we will set up an IRC channel and when we do we will post this information via @wXframework.

We’d like to thank the following individuals for contributing thus far, Chris “@carnal0wnage” Gates, Rob “@mubix” Fuller, Chris “@ChrisJohnRiley” Riley, Jeff “@Infosec208” Murri and @l4mers3c.

No related posts.

Tags: cktricky, tool, wxf