When come across this issues, the interesting part that catch my attention is the Indirect process. To me, i love the creativitiy! Let dive in with some basic understanding about Oracle.
What is Trigger in Oracle and how it works?
A trigger is a named PL/SQL unit that is stored in the database and executed (fired) in response to a specified event that occurs in the database.
It can be fired at exactly one of the following timing points:
--Before the triggering statement executes
--After the triggering statement executes
--Before each row that the triggering statement affects
--After each row that the triggering statement affects
The interesting trigger is the type with 'Before the triggering statement executes'. The Trigger will be executed even the triggering statemet failed. For example, a trigger has setup to be fired when 'drop table' command has executed. If restricted user try to launch the 'drop table' command and he will end up with insufficient privilege or acces denied. But the Trigger will be fired since it a "before" trigger. Such a unique feature has creatively exploited, and the exploitation turned into Indirect privilege escalation or so called 2-stages attack.
How Oracle Indirect privilege escalation works?
Let start to look at how 2-stages attack works. The real example happened in the case CVE-2009-0981 Oracle 10g MDSYS.SDO_TOPO_DROP_FTBL SQL Injection vulnerability.
Finding the culprit
1. Indentify who is the DBA, and the table owned by the him which granted the PUBLIC permission to insert into. Eg, SYSTEM.OL$ table, SYSTEM.DEF$_TEMP$LOB
2. Identify the user who posses the "CREATE ANY TRIGGER" privilege, for example MDSYS, this means MDSYS allows to create a trigger in any schema, expect to the objects that belongs to SYS.
3. Find any vulnerable trigger under the user, so we can inject code into it, for example MDSYS.SDO_TOPO_DROP_FTBL trigger which fired with "DROP TABLE" command. The trigger is vulnerable to code injection
4. Inject crafted code into the vulnerable trigger, and execute it. For example, "DROP TABLE and 1=(scot.z)"
5. The crafted code (scot.z) will create our Trigger under SYSTEM schema, for example, our Trigger is the "before" trigger for the INSERT INTO TABLE statement. The trigger has crafted to execute with "AUTHID CURRENT_USER", that means it follows the table's owner role, which is DBA
6. Execute the command that need to fire the Trigger, for example "insert into system.DEF$_TEMP$LOB..."
7. Our trigger fired and the DBA role obtained!
Again, this attack not working with Oracle XE, as the difference between standard edition and XE.
It is good to study the msf code and clear several doubts in my head about the working mechanism