justinclarke.com

I have started contributing to the Oedipus Web App Vulnerability Scanner project on Rubyforge. The project is progressing pretty fast - there is a GUI in CVS, and a lot of functionality going into the project in the near future.

I am working on less common HTTP methods, and plugins testing permissions on directories for stuff like HTTP PUT and WebDAV. You don't find them often, but when they are there they can be devastating from a defacement point of view. More details coming soon ...

I just committed some changes to the Oedipus CVS that perform basic testing at the directory level for the presence of the TRACE method (see here why this is bad), and also for the presence of PUT and DELETE methods. PUT and DELETE are associated with incorrect permissions and/or configuration of a web server, are thankfully not that common, and are certainly showstoppers when they are present. For example, don't configure your IIS webserver to support both WebDAV and have the write permissions if you don't want people uploading pages via PUT and deleting pages using DELETE.

Make sure you are running Ruby 1.8.4 or later, otherwise not all of the HTTP methods are supported, and none of the WebDAV stuff I'm working on at the moment will work either...

Just committed to the CVS was an operating system command injection plugin for Oedipus. This will check for basic instances of chaining commands using a vertical bar (largely Unix), semicolon (Unix), and double ampersands (Windows). It should hopefully pick up instances where unvalidated input is used in a command executed on the underlying operating system. The attempted "exploit" is to generate a time delay we can measure at the scanner level to determine whether the OS level command worked or not.

This is the first in a series of short demonstrations of how to use the Oedipus Web Scanner available from http://oedipus.rubyforge.org. In this lesson, we will look at how to generate a log file to feed into Oedipus for analysis of web requests and responses, and as a basis for dynamic web testing. In this lesson, we are going to use the Burp Suite (specifically the proxy functionality) freely available from Portswigger (note, you will need Java installed for Burp to work), and Firefox to explore the functionality of a sample application, and record a "burp" logfile. The demonstration is done in Linux, however you can record a log file on any platform supporting Java (i.e. like OS X, and Windows with the Sun Java Runtime).

• By default, the Burp proxy will be configured to intercept HTTP requests after they leave the browser. In this configuration we would have to continually click the "Forward" button in order for the requests to be sent to the webserver. We will therefore turn "Intercept Off" in Burp so this doesn't happen. Requests will be passed on by Burp without interruption in this configuration
• We will go to the "Comms" tab in Burp. One of the things we can do on this tab is configure Burp to log all of the requests and responses passing between the browser and webserver. Here we need to select the text file to log these to (in this case "log.txt")
• Burp is now configured to capture and log all HTTP requests and responses that pass through it, however we will need to configure our browser to use Burp as a proxy server. Burp runs on the local IP address (127.0.0.1) on port 8080 by default (although that can be changed if needed). We configure Firefox to use Burp as the proxy from the Edit -> Preferences -> General -> Connection Settings menu path in Firefox (note this option may be somewhere slightly different for other operating systems such as OS X)
• We are now ready to record a log of browsing through the website we are looking to test. In the example movie I am testing a sample web application . I will click through all of the functionality within the application, filling in each form with valid information, and clicking each link that is within the application. It is very important at this stage to ensure that all of the functionality within the application is logged, so we need to make sure our walkthrough includes all of the links, forms, and functionality within the application. This includes any functionality that requires authentication (i.e. functionality that can only be accessed after login). Also, we need to make sure that all of the data we pass into the application is valid at this point, so no testing for issues at this stage!

And we're done for this part. Next installment - we use the log file we just recorded through the Oedipus Analyzer.

This is the second in a series of short demonstrations of how to use the Oedipus Web Scanner available from http://oedipus.rubyforge.org. You can find the first installment, Generating a log file using Burp, here.

In this lesson, we will look at how to run the Oedipus Analyzer from the command line, to review the log file that we previously recorded using the Burp proxy.

The analyzer can take a variety of input files, including proxy logs from the Burp and Paros proxies, as well as various types of Unix and Windows file listings (for specific types of testing on file present on the web server - more on this in the next installment).

The process we go through in running the Analyzer on the log file we have previously recorded is as follows:

• The Oedipus Analyzer takes the following command line options:
  • The -e option prints an example command line for reference
  • The -n option prints out notes on the file listing formats supported by the Oedipus Analyzer
  • The -f option is the log file (or file listing file) to be used for analysis
  • The -t option is to supply the type of file (burp, paros, Unix file listing, or Windows file listing types 1 or 2)
• As well as the file to be analyzed, and the type of file, we need to supply the hostname of the server to be analyzed. This will ensure that we only review and test URLs related to that server when we perform dynamic web scanning testing, and also that we don't erroneously include pages loaded from other sites in our reporting.
• The Oedipus Analyzer creates a unique output directory each time it is run. It generates an analysis report called oedipus-analyze.xml and an input file called input.oedipus

And we're done for this part. Next installment - we use the input.oedipus file to run the Oedipus Scanner to test for web application vulnerabilities on the live website

This is the third (and final for now) in a series of short demonstrations of how to use the Oedipus Web Scanner available from http://oedipus.rubyforge.org. You can find the first installment, Generating a log file using Burp, here, and the second installment, Running the Oedipus Analyzer from the Command Line, here.

In this lesson, we will look at how to run the Oedipus Scanner from the command line in order to perform dynamic web application testing using the input file generated by Oedipus Analyzer in Lesson 2.

• The Oedipus Scanner takes the following command line options:
  • As for the Oedipus Analyzer, the -e option prints an example command line for reference, and the -n option prints out notes on the default options and behaviour of the tool
  • The -v option enables verbose output
  • The -f option is the Oedipus input file. This is the input.oedipus file generated previously by the Oedipus Anayzer, or is a file in the same format generated by another tool such as IEnterceptor
  • The -w option specifies what plugins will be executed for the scan. By default the type of scan is "basic", which runs the Directory Listing, SQL Injection and Cross Site Scripting (HTML Injection) plugins. The "moderate" setting enables the basic plugins and adds the File Extension (looking for backup files), File Download (for detecting file download issues) and File Rooter (for forceful browsing/finding files) plugins. The "all" setting will run all of the plugins in the plugin directory, and is recommended for thoroughness. If you specify a particular plugin (by name, usually the plugin file name in ./scanner/plugins without the trailing ".rb"), only that plugin will be used for testing
  • The -p option specifies which port the target system should be tested on. This is for when the web application is not on port 80 for HTTP, or port 443 for HTTPS.
  • The -c option is for supplying Oedipus with a cookie or cookies that will be needed to access the pages of the application. This should be obtained each time the Oedipus Scanner is run in order to ensure that the application is tested properly. This is demonstrated in the flash movie for this lesson (see above) where Burp Proxy is used to obtain the cookie after we have authenticated to the application
  • The -q option specifies a variable that will be added to the application's URL. This is commonly used for where an application uses a variable on the querystring for maintaining session instead of using a cookie. Note that if you don't want Oedipus to fuzz this variable, add the variable to the list of ignored variables with the -i option (see below)
  • The -i option allows us to specify variables that Oedipus will not fuzz during testing (i.e. that will be ignored)
  • The -y option allows us to specify an HTTP proxy that will be used by Oedipus for issuing requests to the target host
  • The -b and -r options allow us to specify Basic Authentication credentials for the web server and proxy server respectively for when this is required
  • And finally, the -x option allows us to specify an SSL client certificate (in PEM format) to be used by Oedipus when issuing requests to the application
• The Oedipus Scanner will generate two report files that can be opened in a Web browser. oedipus-scanner-stats.xml has statistics and overall information about the run of the tool, whereas oedipus-scanner.xml contains the details from the scanner plugins
• Where a plugin reported an issue that can be reproduced with a GET or POST to the application, the report will contain a clickable link and an input box for customising the testing value. This will cause a separate browser to pop up, hopefully demonstrating the issue

And we're done with our quick tour of the Oedipus Scanner. Enjoy!

We've just added support for supplying an arbitrary user supplied header to Oedipus using the -d option. At some point we will probably expand this to allow a user to specify more than one.

At the same time I added in support for custom User Agents (through a -u option), to allow the user to easilly select which browser to tell the web application that Oedipus is. By default, Oedipus will masquerade as Internet Explorer 6 on Windows XP, but this can be changed to IE 7, Firefox 1.0, Firefox 1.5, Mozilla, or the user's custom user agent.

Presently, this is available in CVS only. Look for the relase coming up soon!

The Oedipus Web Application Scanner project (that I have been writing plugins for) has just released it's first public beta release - version 1.8.1. Oedipus is a penetration testing focused tool, designed for penetration testers and for technical security or web development folks to test their applications for web application security issues. It deviates from many of the commercial tools in that:

• Oedipus does not claim to be a one stop testing tool that will find every type of hole in your applications. It is, however, pretty good at finding the low hanging fruit so you can spend your time finding the really nasty problems manually
• Oedipus has some exploitation functionality built in, especially for SQL injection at this point, for generating working exploits for web application vulnerabilities. After all, the best way to show the business impact of an issue is to show it is exploitable
• It's free, open source, and pretty easy to extend through the use of it's plugin architecture

From the blurb - "Oedipus is an open source web application security analysis and testing suite written in Ruby by Pentration Testers for Penetration Testers. It is capable of parsing different types of log files off-line and identifying security vulnerabilities. Using the analyzed information, Oedipus can dynamically test web sites for application and web server vulnerabilities"

Downloads have been temporarily removed from the Oedipus site while we review a situation that has arisen.

From the Oedipus site:
"Fellow security professionals. It has recently been brought to our attention of a certain misunderstanding between an ex-employer and the Oedipus Project. Until the matter has been resolved, we have decided it best to take down the latest release of the Oedipus suite. We apologize to our users for any inconvenience and hope to have this misunderstanding resolved in the near future.
Kind regards,
Oedipus Team"

Quick note because some of you may be interested - 800m800m has started a development blog over on the Oedipus site. You can find it here. The first entry has some detail about the (hopefully) forthcoming Oedipus GUI, which is still under development (currently alpha status).

I received my very first email recently asking what happened to the Oedipus Web Scanner (800m800m gets heaps I hear). For those who did not know, Oedipus is now a dead project. For reasons we are not going to go into, the site has been taken down and will not be reappearing...

So, as 800m800m so aptly answered on the Oedipus site, he has moved on to other things, will not be speaking at Blackhat, and cannot give you a login to some s3kr3t 37337 CVS/SVN server since there isn't one.

This isn't to say this is the last you'll hear from 800m800m though, I'm sure he'll come out with something cool in future now he has the coding bug...