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
- Discover the version of Oracle Running
- Find out what the SID of the database is
- Get valid credentials to the database
- Escalate those credentials to DBA level access
- Leverage Oracles functionality to get access to the underlying operating system
- ...
- 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
