Running Dradis in Apache on Ubuntu

Ever been running Dradis and noticed dreadful, unworkable performance problems?  I have, and to fix these I have often resorted to running Dradis on Apache, which seems to get things working nicely once more.  The problem with doing this however, is that I cant find an online guide that actually works for getting this setup.

The existing ones get you partway there, but still result in a broken install.  Since I have had to configure Dradis to run under Apache no less than 3 times in the last few months, getting frustrated each time when I tried to remember what I needed to do next, I figured I would document the steps I take to get Dradis running on Apache under Ubuntu.  This guide takes the steps documented in those guides linked above, and adds the additional steps I used to get things working properly.  I am using Ubuntu 10.04 in this example, but these general steps should work for most Ubuntu versions.

Install Dradis

First off, grab the latest version of Dradis from here.  For me the latest release at the time of writing was 2.7, and I downloaded it and uncompressed it like so:
stephen@lion:~/Downloads$ wget http://downloads.sourceforge.net/dradis/dradis-v2.7.0.tar.bz2
stephen@lion:~/Downloads$ tar xvjf dradis-v2.7.0.tar.bz2

Then I moved it to my choice of install directory, under /opt/.  You can put yours elsewhere if you wish - under /var is also a popular choice.  Just remember you will need to change some paths in the later steps if you choose a different location.
stephen@lion:~/Downloads$ sudo mv dradis-2.7/ /opt/dradis/

Then you will need to install a whole bunch of dependencies using apt.  Heres the command to use.
stephen@lion:~/Downloads$ sudo apt-get install ruby irb rdoc ruby1.8-dev libopenssl-ruby rubygems libsqlite3-0 libsqlite3-dev apache2 rake libcurl4-openssl-dev libssl-dev apache2-prefork-dev libapr1-dev libaprutil1-dev libxml2 libxml2-dev libxslt build-essential

Now we install the bundler gem.
stephen@lion:~/Downloads$ sudo gem install bundler

If, when running this command, you get a response like the following:
bundler requires RubyGems version >= 1.3.6

You may need to update your version of rubygems.  You can do this by visiting the rubygems download page and finding the latest version number to download.  For me it was 1.7.2.  Download and install like so:
stephen@lion:~/Downloads$ wget http://production.cf.rubygems.org/rubygems/rubygems-1.7.2.tgz
stephen@lion:~/Downloads$ tar xvzf rubygems-1.7.2.tgz
stephen@lion:~/Downloads$ cd rubygems-1.7.2/
stephen@lion:~/Downloads/rubygems-1.7.2$ sudo ruby setup.rb

And repeat the bundler install:
stephen@lion:~/Downloads$ sudo gem install bundler

Now install some other gems:
stephen@lion:~/Downloads$ sudo gem install sqlite3-ruby
stephen@lion:~/Downloads$ sudo gem install passenger

Now we will change to our dradis server directory and install a few more gems. Ensure that you perform the 'bundle install' command from the dradis server directory otherwise it wont work correctly.
stephen@lion:~/Downloads$ cd /opt/dradis/server
stephen@lion:/opt/dradis/server$ sudo bundle install
stephen@lion:/opt/dradis/server$ cd ..

Run the verify script from the Dradis home directory to see if any other dependencies are missing.  If this tells you something else needs to be installed, please do so before continuing...
stephen@lion:/opt/dradis$ sudo ./verify.sh

Now we reset the Dradis database using the reset.sh script in the Dradis home directory, and change ownership on the directory and files so Apache will be able to work with Dradis.  If you reset the database again in future (when you want to start a new project for example), be aware that you might need to change the ownerships once more.
stephen@lion:/opt/dradis$ sudo ./reset.sh
stephen@lion:/opt/dradis$ sudo chown -R www-data:www-data *

Configuring Apache

Now lets configure Apache to work with Dradis. First, we will run the passenger module installation program.
stephen@lion:~/Downloads$ sudo passenger-install-apache2-module

At the end of the install process you will be told to add some lines to your apache configuration file.  Take note of these lines.  for me, they were:
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-3.0.7/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-3.0.7
PassengerRuby /usr/bin/ruby1.8

We will now take these lines and place them into the following files.

The file /etc/apache2/mods-available/passenger.load should contain the LoadModule line provided by the passenger installer routine, to have contents like the following:
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-3.0.7/ext/apache2/mod_passenger.so

The file /etc/apache2/mods-available/passenger.conf contains the PassengerRoot and PassengerRuby lines from the passenger installer routine, and contains them within an IfModule directive, like so.
<ifmodule mod_passenger.c>
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-3.0.7
PassengerRuby /usr/bin/ruby1.8
</ifmodule>


Now we will setup a site file named /etc/apache2/sites-available/dradis.  This will run Dradis on port 3004, place the following into the file.
<virtualhost _default_:3004>
SSLEngine on
SSLCertificateFile /opt/dradis/server/config/ssl/server.crt
SSLCertificateKeyFile /opt/dradis/server/config/ssl/server.key.insecure

SSLProtocol all -SSLv2
ServerName dradis
DocumentRoot /opt/dradis/server/public
</virtualhost>

We will also need to edit the Apache ports file /etc/apache2/ports.conf, to configure Apache to listen on port 3004.  Add the following line to the end of the file.
Listen 3004

Now we enable the dradis site and a few needed modules:
stephen@lion:~/Downloads$ sudo a2ensite dradis
stephen@lion:~/Downloads$ sudo a2enmod passenger
stephen@lion:~/Downloads$ sudo a2enmod rewrite
stephen@lion:~/Downloads$ sudo a2enmod ssl

And we start (or restart if already running) Apache to apply the configuration.
stephen@lion:~/Downloads$ sudo /etc/init.d/apache2 start

Now hit https://127.0.0.1:3004/ in your browser, ignore the certificate errors, and enjoy browsing Dradis at a reasonable pace once more!

High Level Windows Shellcode Development Methods

Heres a super quick entry covering some high level methods you can use when developing Windows shellcode.

The methods are:
  • Using the memory editing features of a debugger
  • Using a c compiler
  • Using an assembler

Using a debugger

Writing shellcode using the code editing features of a debugger like OllyDbg is best suited to really simple (approximately <20 byte) shellcode, or for making small edits to already written code while you are actually testing it.  This method is also great when you want to enter the instruction using an opcode instead of the assembly equivalent, which you may want to do when writing shellcode to work around bad character limitations.

The exploit writers debugger guide I wrote a while ago covers how to write and perform small edits to shellcode using the memory editing features in OllyDbg, and this should also work for Immunity Debugger.  The links are available from here:

Exploit writers debugging tutorial

Using a c compiler

Writing shellcode using a c compiler is a good method for writing more detailed code.  Using Didier Stevens' method, you can also debug your code inside the Visual Studio IDE.  I haven't had the opportunity to use this method myself as yet, but testing this out has been on my ever expanding "To Try" list ever since I first read about it, so I thought I'd link to it here.

The links are available from Didier's blog, here:

http://blog.didierstevens.com/2010/05/04/writing-win32-shellcode-with-a-c-compiler/

Using an assembler

Writing shellcode using an assembler is a fairly obvious method, and was the one I used to develop my Download and Execute Script shellcode.

As an example of how this is done, heres some assembly code I pieced together for another Vulnserver related article I recently wrote (hopefully I'll be posting links to it here any day now).  This code is actually based on code from a SecurityForest article that is now offline, and I think they in turn got it from some older Phrack article...
[BITS 32]

; Shellcode to redirect execution back 768 bytes from instruction following CALL

global _start

jmp short jmpspot   
callspot:        ; The CALL lands here, stack now has address of next instruction
pop ecx            ; pops address of next instruction into ECX
dec ch            ; decrement CH register by 1 = ECX - 256
dec ch
dec ch
jmp ecx            ; jmp to ECX
jmpspot:
call callspot

Save this as shellcode.asm, then assemble to binary form into file shellcode.bin using nasm as follows:

stephen@lion:~$ nasm -f bin shellcode.asm -o shellcode.bin

We can then print this out in Hex format, ready for pasting into an exploit, using command line perl-fu

stephen@lion:~$ cat shellcode.bin | perl -e 'while (read STDIN, $d, 1) {print "\\x" . sprintf( "%02x", ord($d));}; print "\n"'
\x59\xfe\xcd\xfe\xcd\xfe\xcd\xff\xe1\xe8\xf2\xff\xff\xff

Or we can get it printed out in slightly neater manner with a character count at the end using my very simple convertsc2h.pl script.

stephen@lion:~$ convertsc2h.pl shellcode.bin
Shellcode:
\x59\xfe\xcd\xfe\xcd\xfe\xcd\xff\xe1\xe8\xf2\xff\xff\xff

Length:14