There are plenty of cheatsheets and documentation for oracle SQL Injections. There have also been countless presentations and research on the subject, however the material is very sparse, mostly out of date and totally non exhaustive.
As a penetration tester I have to deal daily with Oracle DBMS, both via SQL Injections, direct connecctions or access to the hosting machine.
## Basic Information
Most of the times Oracle RDMS run on linux, specifically RedHat or Oracle Linux. The most version I found in the wild were 9 which is extremely old, 10, 11 as most common and 12 in the best cases.
Oracle has an official client called `sqlplus`. Sometimes it is extremely useful to have `sqlplus` and the import and export utilities ready in standalone packages. Please see the #Downloads sections for that.
This file support failover, load balancing and many more options, for further information refer to https://docs.oracle.com/cd/B28359_01/network.111/b28317/tnsnames.htm#NETRF007
Information specified in this file are extremely useful in order to know the database in use and their specifics. All information in the connect string is required to connect to an Oracle instance.
Oracle uses a proprietary format both for storing the actual data on the disk and for export/import process. While it is technically possible to dump a table trough sqlplus it is often very CPU consuming and not very efficient for large tables. In this case Oracle provides two different set of utilities:
* imp/exp
* impdp/expdp
Both require special privileges: this means that even if you have select privileges on a table that doesn't mean you have the privilege to bulk export it. Please refer to https://docs.oracle.com/database/121/SUTIL/GUID-8B6975D3-3BEC-4584-B416-280125EEC57E.htm
To begin with Oracle has plenty of system tables and views to keep track of its properties. Some of them have either `all`, `dba` or `user` prefix. What does it mean?
From https://sqljana.wordpress.com/2016/12/21/oracle-data-dictionary-views-user-vs-all-vs-dba-views-100-level-basics/
> USER* Views
> USER_*: Views that start with USER_ list only the objects owned by the currently logged in user
> ALL* Views
> ALL_*: Views that start with ALL_ list only the objects the currently logged in user has permissions to access
> DBA* Views
> DBA_*: Views that start with DBA_ list all objects unless restricted by the WHERE clause
Oracle default databases to exclude to get cleaner results for custom tables/columns/procedures (from https://github.com/sqlmapproject/sqlmap/blob/master/lib/core/settings.py):
SELECT OWNER, OBJECT_NAME, OBJECT_TYPE FROM ALL_OBJECTS WHERE OBJECT_TYPE IN ('PROCEDURE', 'FUNCTION', 'PACKAGE', 'PACKAGE BODY');
```
List user procedures:
```
SELECT OBJECT_NAME, OBJECT_TYPE FROM ALL_OBJECTS WHERE OBJECT_TYPE IN ('PROCEDURE', 'FUNCTION', 'PACKAGE', 'PACKAGE BODY');
```
Get all non system procedures:
```
SELECT OWNER, OBJECT_NAME, OBJECT_TYPE FROM ALL_OBJECTS WHERE OBJECT_TYPE IN ('PROCEDURE', 'FUNCTION', 'PACKAGE', 'PACKAGE BODY') AND WHERE OWNER NOT IN ('ANONYMOUS', 'APEX_030200', 'APEX_PUBLIC_USER', 'APPQOSSYS', 'BI', 'CTXSYS', 'DBSNMP', 'DIP', 'EXFSYS', 'FLOWS_%', 'FLOWS_FILES', 'HR', 'IX', 'LBACSYS', 'MDDATA', 'MDSYS', 'MGMT_VIEW', 'OC', 'OE', 'OLAPSYS', 'ORACLE_OCM', 'ORDDATA', 'ORDPLUGINS', 'ORDSYS', 'OUTLN', 'OWBSYS', 'PM', 'SCOTT', 'SH', 'SI_INFORMTN_SCHEMA', 'SPATIAL_CSW_ADMIN_USR', 'SPATIAL_WFS_ADMIN_USR', 'SYS', 'SYSMAN', 'SYSTEM', 'WKPROXY', 'WKSYS', 'WK_TEST', 'WMSYS', 'XDB', 'XS$NULL')
```
Get the source code of an object:
```
SELECT TEXT FROM ALL_SOURCE WHERE NAME = 'MY_PROCEDURE' ORDER BY LINE;
```
Somatimes a source code might be obfuscated with a method that Oracle calls 'wrapping'. This is the case of most default procedures. THis format is easily reversible:
Linked instances are used very often. They're very useful to an attacker because they extend the attack surface and may even allow to jump to different network.
Basic Syntax:
```
SELECT USER FOM DUAL@MY_LINKED_DB;
```
Password are stored cleartext or a in a reversible format:
It is important to note that the whole recon process might be done in every linked databases. The user in the linked database might have higher privileges, a different Oracle version and different procedures and packages. It might be possibile to gain RCE in a linked database and not in the one used as entry point.
Queries to linked database may also be nested which means that it is possible to run queries on a database linked to a database linked to the main instance thus making a 'jump' to a third database.
While the following syntax will not work:
```
SELECT USER FROM DUAL@DB1@DB2; error
```
It is possible to create a view or a synomin to overcome the syntax problem as described here https://stackoverflow.com/questions/2094843/possible-to-link-to-another-database-link
```
DB1:
CREATE SYNONYM X FOR MyTable@sqlServerDB
DB2:
(assumes db link to DB1 connects as owner of synonym)