Generate the certificate using OpenSSL:-

$ openssl genrsa 1024 > foo.key
$ openssl req -new -x509 -nodes -sha1 -days 7300 -key foo.key > foo.crt
$ openssl pkcs12 -export -out foo.p12 -in foo.crt -inkey foo.key -name "your name"

You will need the .p12 file (contains key and certificate) to configure Burp. And the .crt file to add it to the Java keystore used by the client. Checkout Burp’s help page for instructions on how to get the first done.

Create a Java keystore, import the certificate

Straightforward enough (just remember the password you entered):

keytool.exe -import -file foo.crt -keystore usefulfor.jks -alias burpcert

Run the application and point it to your keystore

java \
  -Djavax.net.ssl.trustStore=usefulfor.jks \
  -Djavax.net.ssl.trustStorePassword=password \
  -Djavax.net.debug=all  \
  com.usefulfor.Demo

Other interesting properties that you may need in order to further tweak the SSL configuration are javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword.

Tools are provided to create your own certificates and also to use the certificates you have created in SSL communications. The information in this article should be valuable in understanding the certificate format and useful if you need to work with certificate parsing, SSL implementations or fuzzing of the related technologies.

Update (2009-04-09): Checkout the new import/export plugin generators at dradis community forums.

In this post I’ll be looking at what an extension is, how it fits into the dradis framework and how to write your own extensions.

You are welcome to jump ahead to the How do I write my own extension? if that is the only part that you are interested in.

It is not the final solution, and it is not integrated with the web interface, but hopefully it will give you an idea of how easy is to get your own exporting modules for dradis.

• Make one of the components compulsory to install.
• We will look at a way to write our script in such a way that it can be reused for future releases of MyApplication.
• A few extra tips and tricks.

• Ruby (the target machine that our application is installed on requires Ruby)
• MyGem (our application is dependent on this fictitious gem)
• MyApplication (this is our application to be installed)

In this part we will look at how we will let the installer take care of the Ruby and MyGem components.

The old site consisted of 20 static pages or so, which was nice and easy but a real pain to maintain or restructure. So we thought that letting Rails do the heavy lifting for us would be a good idea, but we did not want to set up a Rail environment in the server…

What we finally did is use Rails as a tool to create a static site that we could .tar.gz and upload to the server. As a starting point we used a post in www.chuckvose.com and this is how we completed it to fit our needs.

Follow up (2009-03-23): do not miss how to integrate your rails-static site with Rake and Subversion in the second article of this series: Use Rails to Create a Static Site: Rake and Subversion.

I am using HM NIS editor and IDE for NSIS to make the task a little easier. To get out of the blocks a little quicker I used the HM NIS wizard to create a simple framework from where I will progress.

We have been working as hard as one can work: over 487 commits since then (check the stats), we went to DEFCON 16 where a pre-release of the new dradis v2.0 was showcased… But finally we are here, there is a new release ready for you to try and get addicted to!

Lots of new features: new web interface (+10 neatness, +20 usability), new internal architecture (+30 flexibility), new built-in modules (+10 usefulness)…

I was invited to present my ‘Behind Enemy lines’ research, which mainly focused on different attack techniques that are currently affecting a large number of administrative web interfaces.

The slides of this presentation can be found here: [1]

More information about this research can be found in the following white paper: [3] [4]

The information is split into three files:

• rules file: Contains the rules, each one takes about 72 lines (rules have many properties, each property is written in a separate line). Rules match source hosts with destination hosts and services, no surprise there, but the value of any of this three key fields can be an alias.
• hosts file: in this file the aliases for host groups are defined.
• services file: service groups are defined here.

So the challenge here is: how do we merge this three files into something meaningful?

I know that purists can do this with a bash one-liner that uses grep, awk and sed, but ruby is my weapon of choice, so I created the lucent_metaparser.rb script. It basically takes the three files and applies some regular expressions to extract the information and store it into data structures and then outputs the rules in format that is easy to go through. Here is an example:-

1047: (CH43) 10.0.1.12 ---(both)--- RF400 [permit https - change 43] - enabled | pass
CH43: tcp/443/* ()
10.0.1.12
RF400: 192.168.1.140-192.168.1.145;192.252.1.155;192.252.1.120;
1048: (tcp/80) RF132 ---(both)--- PK012 [web traffic to the dmz - change 74] - enabled | pass
tcp/80
RF132: 172.0.1.38-172.0.1.226 (external reverse proxies)
PK012: 10.15.2.1;10.15.2.2; (internal servers)

I know that it is not perfect and there is room for improvement, but the idea is that the script can be used as a starting point for the review process, and hopefully this will save us some time in the future

This is the first of a series of posts with small tips and tricks of ExtJS that will also address its integration with Ruby on Rails.

In this release we are going to create a ComboBox that loads its items from a remote location (potentially a rails REST endpoint).

Last week I attended DEFCON 16 in Las Vegas. I went last year as well, so I knew to expect the huge throngs of people, the strange mix of young, old, and crazy-haired and all the usual antics that happens when you gather around 7 thousand hackers in one place.

There’s a lot to do at DEFCON besides attending presentations, but this year I was there for business not just pleasure, so I went on a presentation-attending marathon. I must admit that this year there were less “wow” moments as far as the talks were concerned, but there were still some decent talks ands of course lots of opportunities to catch up with friends and acquaintances from around the world.

Here’s a list and some comments of the talks I attended:

An attacker could set up a fake AP with a malicious payload in the Service Set Identifier (SSID). The malicious SSID would be displayed in the ‘Neighbour’s Access Points Table’ page of the administrative interface and would be executed when an administrator scanned for APs.

it was found that a large number of these administrative web applications did not properly sanitise parameters that were passed to them from the DHCP server and therefore an attacker. In particular, a specially crafted DHCPREQUEST message containing malicious JavaScript or HTML code in the DHCP Options Hostname field could be sent to the DHCP server; the malicious code would then be displayed in the DHCP active leases page of the vulnerable administrative application and would be executed when an administrator visited the page.