Burpsuite::Parser Example Script

October 12, 2009

For those know don’t already know… Portswigger released XML support for Burpsuite last week! Once I heard about this, I started working on a Perl XML parsing module. After the long weekend I have a version that is ready to be considered alpha quality. I plan to release the beta version on October 15th at during my presentation at OWASP NYC. Here is an example script demonstrating how easy it is to use Burpsuite::Parser:
#!/usr/bin/perl -w
use strict;
use Burpsuite::Parser;
my $bparser = new Burpsuite::Parser;
my $file;
if ( $ARGV[0] ) {
    $file = $ARGV[0];
else {
    print "usage: $0 [file.xml]\n";
my $parser = $bparser->parse_file("$file");
foreach my $h ( $parser->get_all_issues() ) {
    print "Type: " . $h->type . "\n";
    print "Serial: " . $h->serial_number . "\n";
    print "Severity: " . $h->severity . "\n";
    print "Host: " . $h->host . "\n";
    print "Name: " . $h->name . "\n";
    print "Location: " . $h->location . "\n";
    print "Path: " . $h->path . "\n";
    print "Issue Background: " . $h->issue_background . "\n";
    print "Remediation Background: " . $h->remediation_background . "\n";
    print "Issue Detail: " . $h->issue_detail . "\n";

DM me on twitter(jabra), if you would like to help test the module.


Client-Side Certs – Oh my!

October 12, 2009

One of the techniques demonstrated during the BlackHat/DefCon talk I gave with RSnake was utilizing client-side certificates. Client-side certificates allow for a client to gain a certain amount of trust for the server in which they are connecting. They are used by companies that don’t want to worry about using tokens, so instead they use client-side certificates. Client-side certificates are also used by several sslvpn devices.

To demonstrate client-side certificates, I first needed to create a few certificates so the client could connect to the server.

Using openssl, I created the certificate:
openssl req \
-x509 -nodes -days 365 \
-newkey rsa:1024 -keyout mycert.pem -out mycert.pem

Next, I needed to setup the server to use the certificate. I started thinking about he easiest way to accomplish this goal. It occurred to me that instead of using Apache, I should use the built-in webserver in openssl. This made setup easier, since I replaced Apache with a single command

Here is an example:
openssl s_server -accept 443 -cert mycert.pem -www -verify 10

Finally, I setup a client and verified that the browser contained a client-side certificate for ANOTHER server. Therefore, there is no trust relationship between the public key within the client’s browser and the openssl server. The key is the browser, will ask to send the public key everytime! The only thing an attacker needs to do, is to be listening on the wire and intercept the public key.

Now you may ask, “who cares about the information in a public key?” Well, client-side certificates can contain the following information:

  • Email Address (perhaps a valid username)
  • Hostname and maybe OS of the server
  • Date the Certificate was Issued
  • Date the Certificate Expires

Sometimes, the email address being used contains the user’s name. For example, many organizations standardize on a common email schema to construct email addresses. For example, they may use some variation of the first and last name of the employee.


  • [firstname].[lastname]@domain.com
  • [firstname]-[lastname]@domain.com
  • [firstname]_lastname]@domain.com

If this is the case, an attacker can extract this information and now the attacker knows the user’s full name. For the purposes of achieving remote access, it is only a piece of the puzzle.
The next piece of information was the date the certificate expires. Since we know of a valid email, it is possible this is also a valid username for a network based attacks. Putting both the username and dates together means that the attacker has a greater likelihood for performing a successful attack.

OWASP NYC – Raising the bar on Pentesting!

October 11, 2009

I will be giving a talk at OWASP NYC/NJ this coming Thursday(October 15, 2009). The talk is heavily focused on improving the penetration testing process. It is important for the tools that are used during a penetration assessment to communicate because it will allow for the assessment to streamline much of the tasks that have been manual in the past. The goal of this presentation is to discuss the need for communication between security tools and to demonstrate several examples in which integration can provide the ability to reduce the amount of time spent manually correlating information. This will improve the penetration testing process! If you were to perform an assessment manually (ie without any tools communicating) and compare the results to an assessment in-which all the tools were communicating, the results would clearly demonstrate that communication between tools leads to a better assessment. Therefore, all security assessments need to move in this direction.

For this presentation, I will be demonstrating several modules that I have been working on to provide communication abilities to many of the most popular security testing tools for pentesting and web application security assessments. This presentation will be filled with tons of new tools and modules that I will be releasing for the first time. Many of these tools will make pentesting easier and help to automate much of the tedious tasks of security testing.

I look forward to hanging out with people after the talk and getting their feedback on ways to improve the functionality that I have built.