Oracle Command Execution – From SYS to shell!

As it has come up a few times in my personal engagements, I figured it was time to do a writeup on Oracle command execution.

While it is not as easy as MYSQL to go from root/sys/dba to a full shell, it is still doable in an Oracle environment.

I’ll go over three different paths to a shell on Oracle this week, with indepth examples for two of them.

First off, for all of these examples, we’ll need a SYS level account as we will be creating and modifying stored procedures, directories, and jobs.

Oracle Raptor

Similar to the MYSQL Raptor UDF exploit, Marco Ivaldi has also created an exploitation suite for Oracle (written in Java).

To verify that we will be able to execute this suite, we will need to verify that Java is installed on the Oracle system.

If Java is installed, then we are able to download and execute the suite. Alternatively, we can download it from Exploit DB.

Once the script is run, we can verify that it was installed by looking for the 3 new stored procedures: JAVACMD, JAVAREADFILE, and JAVAWRITEFILE.

With the procedures created, we can go over the example provided to create a script that outputs ls -l three times to the temp directory.

If we have access to the actual system, then we can indeed verify that this script was created, and contains the proper commands.

With the test script created, we can then execute it using javacmd.

On the system side, we can verify execution by checking the /tmp directory for our three test files.

If everything is working as expected, then we can create a full request (including execution) for the whoami command.

With everything properly in place, it is time to get a reverse shell from the system. As usual, pentestmonkey is a great resource for reverse shell one-liners.

With the script running, our listener catches a connect-back, and we’ve got a shell on the box!

attacker@attackbox:~$ sudo nc -lvvp 443
Listening on any address 443 (https)
Connection from 10.135.19.98:9880
bash: no job control in this shell
bash: uname: No such file or directory
bash: [: =: unary operator expected
bash: ls: No such file or directory
The Oracle base remains unchanged with value /u01/oracle
[oracle@testbox dbs]$ 

Oracle Directory Traversal Vulnerability

While I do not have an in-depth example for this as it is only valid for Oracle 9i and 10g, it is still worth touching on as a path to exploitation.

CVE-2004-1364 specifies the directory traversal vulnerability inside of extproc that leads to the execution.

On those systems, we are able to download the command execution exploit to take advantage of this.

dbms_scheduler Jobs for /bin/sh

On systems without Java or the directory traversal vulnerability, we are still able to obtain command execution using a scheduled stored procedure that executes /bin/sh.

First up, we will need to download and execute the appropriate stored procedure.

To verify that it ran properly, we just need to check for the newly created SYSTEM_RUN stored procedure.

For this script to run properly (without modifications), we will need to have a directory named TMP that maps to /tmp on the system.

With everything in place, we are able to run a uname to verify command execution.

If that works, then we can attempt to execute a reverse shell using the stored proc.

With the job run, our listener catches the connect, and we again have shell access to the Oracle server.

attacker@attackbox:~$ sudo nc -lvvp 443
Listening on any address 443 (https)
Connection from 10.135.19.98:9928
bash: no job control in this shell
[oracle@testbox /]$ 

Note that in some cases, the scheduled job may fail, and will need to be cleaned up.

If the job has failed, you can verify this by the ‘TEST’ job still existing in the job list.

In this case, you will just need to drop the job and re-exec your commands.

While Oracle is definitely a different beast than MYSQL, it is still more than possible to escalate from DBA level access to a shell on the system itself. From there, privilege escalation is up to you.