This isn’t the first time I’ve had to do this, but I recently had to quickly spin up an Amazon EC2 instance to run the Metasploit Framework online, and thought I should capture the high level process flow somewhere. And so this gist was created on github.

I found that if you need it quickly, aren’t expecting on requiring it for very long and don’t mind spending a little bit more (I’m still talking about that Metasploit instance .. sickos), then running up one of Amazon’s “Basic 64-bit Amazon Linux AMI” on an “High-CPU Extra Large (c1.xlarge, 7GB)” instance is perfect, especially if you need to install ruby 1.9.2 instead of using the AMI’s default ruby 1.8.

The gist does the following:

sudo yum install make gcc openssl-devel svn git

Install the necessary packages to build software, including OpenSSL requirements. Also install git (for getting RVM, more below) and svn (for getting MSF .. although they have moved to github, so this will likely change soon)

bash < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)
exit

Install RVM, the Ruby Version Manager, this is a simplified method to install multiple ruby versions. The bash script above is ripped directly from the RVM page here. This helps us run up ruby 1.9.2, which seems to work brilliantly with the Metasploit Framework, at least as of the current version. We exit, and then you ssh back into your instance so that RVM gets setup in your bash profile.

rvm pkg install openssl

Use RVM to install the OpenSSL package, this is used for the RVM process when we install Ruby 1.9.2.

rvm install 1.9.2 --with-openssl-dir=$rvm_path/usr

Use RVM to install Ruby version 1.9.2, and set it to use the RVM install OpenSSL, per the above command. This is the longest part of the process, and this is where we really benefit from using that High CPU instance ;)

svn co https://www.metasploit.com/svn/framework3/trunk/
cd trunk

Checkout the latest version of the Metasploit Framework into the “trunk” folder and change into there.

rvm use 1.9.2

Tell RVM that we want to use that installed version of Ruby 1.9.2.

rvmsudo ruby -v

Check that we’re running Ruby 1.9.2. Rvmsudo is used to emulate running the commands through sudo, but in the context of rvm. We want to check that Ruby 1.9.2 runs under rvmsudo because we may want Metasploit to listen on low ports, such as TCP/80.

rvmsudo ruby ./msfconsole

Lets start up Metasploit, as Root, using Ruby 1.9.2. Obviously, if you’re concerned about running Metasploit as root feel free to start Metasploit as a regular user with “ruby ./msfconsole”.

And there you go. A quick, blow away Amazon Linux powered Metasploit Framework instance.

One of the biggest issues I had with BeEF when I started contributing to the project was the administrative interface. Primarily this was due to being absolutely spoilt by Metasploit’s “msfconsole” interface, it just felt so natural to run everything from the command line, it made it trivial to ssh into EC2 instances running MSF, or even just locally, it didn’t matter, the “show” command making it so easy to iterate through a fairly complex hierarchy of information.

So I took some time out to try and figure out how we could implement another UI for BeEF, and naturally I started to look into how MSF did it, and then I came across their fantastic Rex Library, now packaged as a gem for easy distribution and installation over here: https://github.com/hammackj/rex. (Cheers @hammackj). Now, at this point the console interface for BeEF is still non-trunk material, and it’s more of a remote-control interface, i.e. talking via the admin JSON interface that exists within the “Admin” BeEF extension.

It was through this process that I really came to appreciate the awesome work the Metasploit team had done in the construction of Rex, I mean immediately just by performing a quick “# gem install librex” and then including a “require ‘rex’” into your code you have access to an incredibly powerful console based interface with tab completion, multiple level stacks (think beef > zombie > command), a job management system, and this is just the stuff the BeEF console’s using. Lets not forget logging, encoding, sockets and much much more.

If you’re building any security tools in ruby, nay, any tool in ruby that requires this sort of interface (and lets not forget how extensive msf is, so sure you can use Rex to drive a web-ui, console, cli, whatever) I think you’d have a hard time trying to find anything as effective and full-featured as Rex. In addition you’ll find that new features come out quite consistently too, like their JS obfuscator.

By separating the remote control library from the Rex console driver UI, I was then also able to drop the exact same remote control library into the recently announced MSF BeEF Plugin (early version available here).

You can see the console in action here (the current version in the trunk has been updated though, so it’s a lot neater than this):

And the MSF BeEF Plugin here:

or “Leveraging the Cloud to Pwn your Mum”. .. (Cheers to @irldexter for the name idea)

I was fortunate to get a DM the other day from @Kimono asking if I’d want to do a lightening talk at the Perth CloudCamp today. I immediately got excited about the opportunity to talk about something that I’ve certainly been experimenting with over the past few months, and it’s pretty trivial stuff if you think about it, and fairly common if you’re keeping abreast of current trends in web pen testing. Why run your applications locally, over your local connection, if you can run it from the Internet.

This is certainly an idea we’ve been playing with at BeEF (BeEF-cloud – pre-canned AMI images for Amazon’s EC2), and something that Dinis Cruz just talked about if you’re interested in running up O2 in Amazon. And why stop there? There’s great benefits from running your SET and Metasploit from Amazon’s environment too!

Having only 10 minutes was fairly limiting, and not really knowing the audience didn’t help, but I aimed to try and provide a really high level overview of the OWASP Testing Guide and how tools traditionally designed to run locally can leverage Amazon’s EC2 environment quite well too.

You can see the slidedeck here (I would recommend opening up the “Show Speaker Notes”): https://docs.google.com/present/view?id=ddwsqr7c_63c3phb7gn

Oh, and PS: I’m not strictly tied to the term “Cloud”, but I do really enjoy Amazon’s AWS and EC2 services :)

*Phew*, burpdot is now up to version 0.5. I can’t really explain the relief I feel at getting this version out. Ever since David planted the idea of visualising Burp log files showing how URLs refer to one another he was always going on about “Hey, jQuery is easy right? Sure! You can build up a web interface right? That’ll only take you a couple of days?”. Well according to the network graph I’ve been making tiny commits to the work in progress branch for the past 2 months, only now have I merged it back in and voila.

The existing command line functionality should be exactly the same, but, if you set up your environment according to the documented dependancies then you should be able to simply run “./burpweb.rb” and open up http://localhost:8015.

Less words, more shows:

Burpdot is now up to version 0.4, it’s starting to shape up into something a little bigger than first imagined, which I guess is the way with these things. But first lets cover the simple stuff, as of 0.4, burpdot now has a new mode to output into a SQLite database file. At the moment, there’s not much point in this functionality, but new versions will use it – but lets leave that for another post. Example:

# ./burpdot.rb -i burp.log -m sqlite -o burp.db

Excitement!

Okay, not really. Anyway, before getting onto the depth option I’ll have to admit, I don’t really know much about using Graphviz. So, after a little reading I figured out a couple of over-rides that really help with burpdot (via Afterglow) generated graphs, the normalize option, the splines option, and using vpsc for overlay prevention instead of ortho. You can see these generated below.

The concept of depth is really simple, set to 1 and burpdot only extracts the domain portion of the URI, set to 2, and you get the domain and the path, set to 3 you get the domain, path and query string. By default depth is set to 2, so you get graphs as generated in previous versions. Examples:

# ./burpdot.rb -i burp.log -m csv -d 1 | ./afterglow.pl -t -c burp.properties | neato -v -Tpng -Gnormalize=true -Gsplines=true -Goverlap=vpsc -o burp-depth-1.png

# ./burpdot.rb -i burp.log -m csv -d 2 | ./afterglow.pl -t -c burp.properties | neato -v -Tpng -Gnormalize=true -Gsplines=true -Goverlap=vpsc -o burp-depth-2.png

# ./burpdot.rb -i burp.log -m csv -d 3 | ./afterglow.pl -t -c burp.properties | neato -v -Tpng -Gnormalize=true -Gsplines=true -Goverlap=vpsc -o burp-depth-3.png