Add Oracle DB Priv Esc via function-based index #8803
Conversation
Adds a Metasploit module for escalating an Oracle DB user to DBA through abusing index privileges to create a function-based index that runs with the privileges of the table owner, instead of the user who created the index. This module was tested on Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64 bit Production. A user can query for their privileges with the following: SELECT * FROM session_privs The user will need to disconnect and reconnect after running the exploit to access their new privileges.
moshekaplan
changed the title
| end | ||
|
|
||
| def run | ||
| return if not check_dependencies |
There was a problem hiding this comment.
Generally prefer C-style operators. return if !check_dependencies or return unless check_dependencies.
| 'Description' => %q{ | ||
| This module will escalate an Oracle DB user to DBA by creating a function-based index on a table owned by a more-privileged user. Credits to David Litchfield for publishing the technique. | ||
| }, | ||
| 'Author' => [ 'Moshe Kaplan' ], |
There was a problem hiding this comment.
Can list David Litchfield here with comment describing contribution.
|
Next time, please create a topic branch to work from. Doing stuff from |
|
Thanks for your PR, @moshekaplan. Would you mind adding a markdown file of documentation? Something like this. Thanks! |
|
Per IRC discussion, verifier of this PR should please fill out the missing bits in the documentation markdown. TIA! |
|
I grabbed the vulnerable SW, can verify this week. |
|
I was trying this out and bumped into an interesting run: It appears that the prepare_exec() method in lib/msf/core/exploit/oracle.rb is, in this code path, catching the OCIError exception and printing it out, but then returning to the calling code. So modules like this one have no chance to catch this exception, themselves, and appropriately react. Certainly this isn't the only Oracle-related module subject to this behavior, I'm just mentioning it here in case there's thoughts/guidance others with better knowledge of the system might offer (before I go make any changes to framework's Oracle prepare_exec() method). :) |
|
Just for posterity, I did get a success path working with this module, but didn't see that it worked due to my n00b-ness with OracleDB. I'll finish validating this week. |
|
Hey @moshekaplan, my apologies for the delay. I spent some time this weekend standing up a clean setup and trying to repo the expected module behavior, but I just can't seem to get it to work. Lemme run the details by you in case you see something I'm doing in error. I'm using a Windows 8.1 x64 VM target running the following Oracle version: After a clean install of the Oracle DB, I used the It appears the But I noticed that this expected execution via Per the Litchfield's writeup, I tried creating a new table (with SYSTEM as the owner) and granting PUBLIC permission to create an index. But I get an error (which I haven't dug into yet): If you see anything in the above (or note a difference in your setup), I'm all ears. I'll circle back to digging more on this later this week, for sure. |
|
It is required that code in your fork be merged from a unique branch in your repository to master in Rapid7's. Please create a new branch in your fork of framework and resubmit this from that branch. This helps protect the process, ensure users are aware of commits on the branch being considered for merge, allows for a location for more commits to be offered without mingling with other contributor changes and allows contributors to make progress while a PR is still being reviewed. Closing based on the this requirement, please do resubmit from a unique branch. |
Adds a Metasploit module for escalating an Oracle DB user to DBA
through abusing index privileges to create a function-based index
that runs with the privileges of the table owner, instead of the
user who created the index.
This module was tested on Oracle Database 11g Express Edition
Release 11.2.0.2.0 - 64 bit Production.
A user can query for their privileges with the following:
SELECT * FROM session_privs
The user will need to disconnect and reconnect after running
the exploit to access their new privileges.
Verification
List the steps needed to make sure this thing works
sqlplus SCOTT/TIGER@192.168.3.100:1521/XEXDBSELECT * FROM session_privsmsfconsoleuse auxiliary/admin/oracle/oracle_index_privescexploitsqlplus SCOTT/TIGER@192.168.3.100:1521/XEXDBSELECT * FROM session_privs